www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D Web Services Application Potential?

reply "Brandon Ragland" <brags callmemaybe.com> writes:
Hi All,

Not entirely certain if there is a decent D web applications 
server implementation as of yet, but if there is a project going 
on, I'd love to have a gander.

On the off-chance there isn't one, who would be interested in 
going at it, call it, a 'group' project.

I've been yearning for a D web app server for a while, as most of 
my day to day work is done on Java EE containers (think 
Glassfish, Weblogic, etc. Java Beans, lalala) and the insane 
system usage has bothered me from day one.

There's Wt for C++, although I don't see much coming from that, 
though the concept is grand. Rust has a few up and coming web 
server frameworks as well.

D could really excel here.

-Thoughts? Am I crazy (probably)?
Jul 25 2015
next sibling parent reply "sigod" <sigod.mail gmail.com> writes:
On Saturday, 25 July 2015 at 22:47:59 UTC, Brandon Ragland wrote:

 Hi All,

 Not entirely certain if there is a decent D web applications 
 server implementation as of yet, but if there is a project 
 going on, I'd love to have a gander.

 On the off-chance there isn't one, who would be interested in 
 going at it, call it, a 'group' project.

 I've been yearning for a D web app server for a while, as most 
 of my day to day work is done on Java EE containers (think 
 Glassfish, Weblogic, etc. Java Beans, lalala) and the insane 
 system usage has bothered me from day one.

 There's Wt for C++, although I don't see much coming from that, 
 though the concept is grand. Rust has a few up and coming web 
 server frameworks as well.

 D could really excel here.

 -Thoughts? Am I crazy (probably)?


Have you seen [vibe.d](http://vibed.org/)?
Jul 25 2015
parent "Brandon Ragland" <brags callmemaybe.com> writes:
On Saturday, 25 July 2015 at 23:23:36 UTC, sigod wrote:

 On Saturday, 25 July 2015 at 22:47:59 UTC, Brandon Ragland 
 wrote:

 Hi All,

 Not entirely certain if there is a decent D web applications 
 server implementation as of yet, but if there is a project 
 going on, I'd love to have a gander.

 On the off-chance there isn't one, who would be interested in 
 going at it, call it, a 'group' project.

 I've been yearning for a D web app server for a while, as most 
 of my day to day work is done on Java EE containers (think 
 Glassfish, Weblogic, etc. Java Beans, lalala) and the insane 
 system usage has bothered me from day one.

 There's Wt for C++, although I don't see much coming from 
 that, though the concept is grand. Rust has a few up and 
 coming web server frameworks as well.

 D could really excel here.

 -Thoughts? Am I crazy (probably)?


 Have you seen [vibe.d](http://vibed.org/)?


I have not seen this before, just took a look at the project and 
it seems very well placed.

I'll have to look into this more as time permits.

Appreciate being pointed towards this, very useful.
Jul 25 2015
prev sibling next sibling parent reply Etienne Cimon <etcimon gmail.com> writes:
On 2015-07-25 18:47, Brandon Ragland wrote:

 Hi All,

 Not entirely certain if there is a decent D web applications server
 implementation as of yet, but if there is a project going on, I'd love
 to have a gander.

 On the off-chance there isn't one, who would be interested in going at
 it, call it, a 'group' project.

 I've been yearning for a D web app server for a while, as most of my day
 to day work is done on Java EE containers (think Glassfish, Weblogic,
 etc. Java Beans, lalala) and the insane system usage has bothered me
 from day one.

 There's Wt for C++, although I don't see much coming from that, though
 the concept is grand. Rust has a few up and coming web server frameworks
 as well.

 D could really excel here.

 -Thoughts? Am I crazy (probably)?


Not crazy. I've been working towards exactly that as hard I could (see 
on https://github.com/etcimon/), seeing how D would be the best language 
to write any web backend with. I've since worked on writing all the 
architecture in D: a new TLS library Botan, along with libhttp2 for 
HTTP/2 support and an async event loop 
(TCP/UDP/FileSystem/FileWatcher/DNS/Timers) library.

I've written all the "glue" code to have it in the vibe.d framework and 
tested it as thoroughly as I could. I now consider it an achievement and 
use it in my web applications.

I'm currently concentrating on improving an async postgresql driver 
called DDB and adding transactions, Json, TLS, Listen/Notify, etc.

I think my next priority would be to rewrite the back-end of 
http://www.cosmocms.org with D and the vibe.web.web Web Interface, and 
Redis+Postgresql (sessions in redis). It's about 4k-5k LOC

I think a good and necessary library would be for cross-platform, async 
DNS. I've been looking at this one in particular: 
https://github.com/miekg/dns
Jul 25 2015
parent reply "Brandon Ragland" <brags callmemaybe.com> writes:
On Sunday, 26 July 2015 at 00:46:58 UTC, Etienne Cimon wrote:

 On 2015-07-25 18:47, Brandon Ragland wrote:

 Hi All,

 Not entirely certain if there is a decent D web applications 
 server
 implementation as of yet, but if there is a project going on, 
 I'd love
 to have a gander.

 On the off-chance there isn't one, who would be interested in 
 going at
 it, call it, a 'group' project.

 I've been yearning for a D web app server for a while, as most 
 of my day
 to day work is done on Java EE containers (think Glassfish, 
 Weblogic,
 etc. Java Beans, lalala) and the insane system usage has 
 bothered me
 from day one.

 There's Wt for C++, although I don't see much coming from 
 that, though
 the concept is grand. Rust has a few up and coming web server 
 frameworks
 as well.

 D could really excel here.

 -Thoughts? Am I crazy (probably)?


 Not crazy. I've been working towards exactly that as hard I 
 could (see on https://github.com/etcimon/), seeing how D would 
 be the best language to write any web backend with. I've since 
 worked on writing all the architecture in D: a new TLS library 
 Botan, along with libhttp2 for HTTP/2 support and an async 
 event loop (TCP/UDP/FileSystem/FileWatcher/DNS/Timers) library.

 I've written all the "glue" code to have it in the vibe.d 
 framework and tested it as thoroughly as I could. I now 
 consider it an achievement and use it in my web applications.

 I'm currently concentrating on improving an async postgresql 
 driver called DDB and adding transactions, Json, TLS, 
 Listen/Notify, etc.

 I think my next priority would be to rewrite the back-end of 
 http://www.cosmocms.org with D and the vibe.web.web Web 
 Interface, and Redis+Postgresql (sessions in redis). It's about 
 4k-5k LOC

 I think a good and necessary library would be for 
 cross-platform, async DNS. I've been looking at this one in 
 particular: https://github.com/miekg/dns


In relation to DDB: Have you seen: https://github.com/buggins/ddbc

It's most similar to the JDBC driver in Java. Currently supports 
MySQL, PostgreSQL and SQLite. That might be a good starting point 
to expand the SQL driver support for a web framework.

I dug around some of your repos, too early to comment but I'll 
sift through more of it as time allows, see if I can't offer 
anything towards your current goals in the near future.

I fully agree that D would be a great fit for web development.

Thanks for the reply.
Jul 25 2015
parent reply Etienne Cimon <etcimon gmail.com> writes:
On 2015-07-25 22:35, Brandon Ragland wrote:

 On Sunday, 26 July 2015 at 00:46:58 UTC, Etienne Cimon wrote:

 On 2015-07-25 18:47, Brandon Ragland wrote:

 Hi All,

 Not entirely certain if there is a decent D web applications server
 implementation as of yet, but if there is a project going on, I'd love
 to have a gander.

 On the off-chance there isn't one, who would be interested in going at
 it, call it, a 'group' project.

 I've been yearning for a D web app server for a while, as most of my day
 to day work is done on Java EE containers (think Glassfish, Weblogic,
 etc. Java Beans, lalala) and the insane system usage has bothered me
 from day one.

 There's Wt for C++, although I don't see much coming from that, though
 the concept is grand. Rust has a few up and coming web server frameworks
 as well.

 D could really excel here.

 -Thoughts? Am I crazy (probably)?


 Not crazy. I've been working towards exactly that as hard I could (see
 on https://github.com/etcimon/), seeing how D would be the best
 language to write any web backend with. I've since worked on writing
 all the architecture in D: a new TLS library Botan, along with
 libhttp2 for HTTP/2 support and an async event loop
 (TCP/UDP/FileSystem/FileWatcher/DNS/Timers) library.

 I've written all the "glue" code to have it in the vibe.d framework
 and tested it as thoroughly as I could. I now consider it an
 achievement and use it in my web applications.

 I'm currently concentrating on improving an async postgresql driver
 called DDB and adding transactions, Json, TLS, Listen/Notify, etc.

 I think my next priority would be to rewrite the back-end of
 http://www.cosmocms.org with D and the vibe.web.web Web Interface, and
 Redis+Postgresql (sessions in redis). It's about 4k-5k LOC

 I think a good and necessary library would be for cross-platform,
 async DNS. I've been looking at this one in particular:
 https://github.com/miekg/dns


 In relation to DDB: Have you seen: https://github.com/buggins/ddbc

 It's most similar to the JDBC driver in Java. Currently supports MySQL,
 PostgreSQL and SQLite. That might be a good starting point to expand the
 SQL driver support for a web framework.

 I dug around some of your repos, too early to comment but I'll sift
 through more of it as time allows, see if I can't offer anything towards
 your current goals in the near future.

 I fully agree that D would be a great fit for web development.

 Thanks for the reply.


Yes, the goal is to avoid libpq. A typical Vibe.d TCP Connection is 
based on what you know as Green Threads, it's called Tasks/Fibers in D. 
It means you have to avoid any library that uses thread-blocking I/O 
because you're using 1 thread to handle all requests.
Jul 25 2015
parent reply "Brandon Ragland" <brags callmemaybe.com> writes:
On Sunday, 26 July 2015 at 02:53:12 UTC, Etienne Cimon wrote:

 On 2015-07-25 22:35, Brandon Ragland wrote:

 On Sunday, 26 July 2015 at 00:46:58 UTC, Etienne Cimon wrote:

 [...]


 In relation to DDB: Have you seen: 
 https://github.com/buggins/ddbc

 It's most similar to the JDBC driver in Java. Currently 
 supports MySQL,
 PostgreSQL and SQLite. That might be a good starting point to 
 expand the
 SQL driver support for a web framework.

 I dug around some of your repos, too early to comment but I'll 
 sift
 through more of it as time allows, see if I can't offer 
 anything towards
 your current goals in the near future.

 I fully agree that D would be a great fit for web development.

 Thanks for the reply.


 Yes, the goal is to avoid libpq. A typical Vibe.d TCP 
 Connection is based on what you know as Green Threads, it's 
 called Tasks/Fibers in D. It means you have to avoid any 
 library that uses thread-blocking I/O because you're using 1 
 thread to handle all requests.


That would make sense then.

Was unaware vibe.d was using green threading. The JVM dropped 
green threads circa 1.2, a long time ago.

I suppose the complexity of asynchronous I/O was never 
implemented to avoid these blocking issues with fibers/tasks?
Jul 25 2015
parent "Etienne Cimon" <etcimon gmail.com> writes:
On Sunday, 26 July 2015 at 03:04:21 UTC, Brandon Ragland wrote:

 On Sunday, 26 July 2015 at 02:53:12 UTC, Etienne Cimon wrote:

 On 2015-07-25 22:35, Brandon Ragland wrote:

 On Sunday, 26 July 2015 at 00:46:58 UTC, Etienne Cimon wrote:

 [...]


 In relation to DDB: Have you seen: 
 https://github.com/buggins/ddbc

 It's most similar to the JDBC driver in Java. Currently 
 supports MySQL,
 PostgreSQL and SQLite. That might be a good starting point to 
 expand the
 SQL driver support for a web framework.

 I dug around some of your repos, too early to comment but 
 I'll sift
 through more of it as time allows, see if I can't offer 
 anything towards
 your current goals in the near future.

 I fully agree that D would be a great fit for web development.

 Thanks for the reply.


 Yes, the goal is to avoid libpq. A typical Vibe.d TCP 
 Connection is based on what you know as Green Threads, it's 
 called Tasks/Fibers in D. It means you have to avoid any 
 library that uses thread-blocking I/O because you're using 1 
 thread to handle all requests.


 That would make sense then.

 Was unaware vibe.d was using green threading. The JVM dropped 
 green threads circa 1.2, a long time ago.

 I suppose the complexity of asynchronous I/O was never 
 implemented to avoid these blocking issues with fibers/tasks?


There's a way to avoid the blocking by spawning more threads 
(through worker tasks), but it's so much more efficient to use 
native protocol implementations. After all, this is how D and 
vibe.d can get the most req/s compared to the other native 
frameworks. Somebody took the time to write a very elaborate 
standoff and it shows a pretty accurate picture of it: 
https://atilanevesoncode.wordpress.com/2013/12/05/go-vs-d-vs-erlang-vs-c-in-real-life-mqtt-broker-implementation-shootout/
Jul 25 2015
prev sibling next sibling parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 26/07/2015 10:47 a.m., Brandon Ragland wrote:

 Hi All,

 Not entirely certain if there is a decent D web applications server
 implementation as of yet, but if there is a project going on, I'd love
 to have a gander.

 On the off-chance there isn't one, who would be interested in going at
 it, call it, a 'group' project.

 I've been yearning for a D web app server for a while, as most of my day
 to day work is done on Java EE containers (think Glassfish, Weblogic,
 etc. Java Beans, lalala) and the insane system usage has bothered me
 from day one.

 There's Wt for C++, although I don't see much coming from that, though
 the concept is grand. Rust has a few up and coming web server frameworks
 as well.

 D could really excel here.

 -Thoughts? Am I crazy (probably)?


I wrote Cmsed[0], web service framework which uses Vibe.d and Dvorm 
(ORM)[1].
They are both sunsetted.

I'm currently working on a web server[2] that will ultimately replace a 
good bit of what Vibe.d is currently being used for. Which will be using 
libasync[3] (backend for vibe.d but purely in D) instead of Vibe.d.

Of course progress is slow and my current set of code is not up in the 
repository as I wrote it on stream[4]. My intention is there, is once 
std.experimental.image gets more boring again / can't do much on stream 
I'll start work on it again. Once it comparable to what I've got on 
repo, I'll update it.
In terms of what the web server will be like, Apache httpd config 
syntax[5] but a LOT more dynamic ala JSP style.

Once web server is done then I'll continue with my web service framework 
based upon Cmsed. Most of that code is ready to go. It's just things 
like reloading and templates that need rewriting.

[0] https://github.com/rikkimax/cmsed
[1] https://github.com/rikkimax/dvorm
[2] https://github.com/DNetDev/webserver
[3] https://github.com/etcimon/libasync
[4] https://www.livecoding.tv/alphaglosined/
[5] https://github.com/DNetDev/apache_httpd_format
Jul 25 2015
parent reply "Brandon Ragland" <brags callmemaybe.com> writes:
On Sunday, 26 July 2015 at 04:33:57 UTC, Rikki Cattermole wrote:

 On 26/07/2015 10:47 a.m., Brandon Ragland wrote:

 [...]


 I wrote Cmsed[0], web service framework which uses Vibe.d and 
 Dvorm (ORM)[1].
 They are both sunsetted.

 I'm currently working on a web server[2] that will ultimately 
 replace a good bit of what Vibe.d is currently being used for. 
 Which will be using libasync[3] (backend for vibe.d but purely 
 in D) instead of Vibe.d.

 Of course progress is slow and my current set of code is not up 
 in the repository as I wrote it on stream[4]. My intention is 
 there, is once std.experimental.image gets more boring again / 
 can't do much on stream I'll start work on it again. Once it 
 comparable to what I've got on repo, I'll update it.
 In terms of what the web server will be like, Apache httpd 
 config syntax[5] but a LOT more dynamic ala JSP style.

 Once web server is done then I'll continue with my web service 
 framework based upon Cmsed. Most of that code is ready to go. 
 It's just things like reloading and templates that need 
 rewriting.

 [0] https://github.com/rikkimax/cmsed
 [1] https://github.com/rikkimax/dvorm
 [2] https://github.com/DNetDev/webserver
 [3] https://github.com/etcimon/libasync
 [4] https://www.livecoding.tv/alphaglosined/
 [5] https://github.com/DNetDev/apache_httpd_format


The idea of a JSP like system would bring a lot of the Java guys 
over to D.

JSP has JSTL and EL markup on the JSP pages that work well with 
servlets and EJBs.

I've been fooling around the repos posted here and thinking about 
what it might take to get a framework on top of vibe.d to perform 
similar functions as a Java container.

I appreciate the links / responses guys. It's always worth the 
read.

-Brandon
Jul 26 2015
next sibling parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 27/07/2015 6:18 a.m., Brandon Ragland wrote:

 On Sunday, 26 July 2015 at 04:33:57 UTC, Rikki Cattermole wrote:

 On 26/07/2015 10:47 a.m., Brandon Ragland wrote:

 [...]


 I wrote Cmsed[0], web service framework which uses Vibe.d and Dvorm
 (ORM)[1].
 They are both sunsetted.

 I'm currently working on a web server[2] that will ultimately replace
 a good bit of what Vibe.d is currently being used for. Which will be
 using libasync[3] (backend for vibe.d but purely in D) instead of Vibe.d.

 Of course progress is slow and my current set of code is not up in the
 repository as I wrote it on stream[4]. My intention is there, is once
 std.experimental.image gets more boring again / can't do much on
 stream I'll start work on it again. Once it comparable to what I've
 got on repo, I'll update it.
 In terms of what the web server will be like, Apache httpd config
 syntax[5] but a LOT more dynamic ala JSP style.

 Once web server is done then I'll continue with my web service
 framework based upon Cmsed. Most of that code is ready to go. It's
 just things like reloading and templates that need rewriting.

 [0] https://github.com/rikkimax/cmsed
 [1] https://github.com/rikkimax/dvorm
 [2] https://github.com/DNetDev/webserver
 [3] https://github.com/etcimon/libasync
 [4] https://www.livecoding.tv/alphaglosined/
 [5] https://github.com/DNetDev/apache_httpd_format


 The idea of a JSP like system would bring a lot of the Java guys over to D.

 JSP has JSTL and EL markup on the JSP pages that work well with servlets
 and EJBs.

 I've been fooling around the repos posted here and thinking about what
 it might take to get a framework on top of vibe.d to perform similar
 functions as a Java container.

 I appreciate the links / responses guys. It's always worth the read.

 -Brandon


What I currently have is code templates as follows:

<?lua
	echo("<p>" .. consumeNextText() .. "</p>")
?>

Hi there, this is some text!
Woopity doo.

<?lua
	include_text("<?lua echo(\"boo\") ?>")
?>

So it would output something like:
<p>
Hi there, this is some text!
Woopity doo.
</p>boo

The languages supported would have to be known and configured at compile 
time. But theoretically other languages such as Squirrel and PHP should 
work.
D on the other hand, would be ugh hard.

I will be supporting the ability to pass in e.g. data models and even 
query them. Thanks to reflection that I've added since Cmsed.
Jul 26 2015
parent reply "Sebastiaan Koppe" <mail skoppe.eu> writes:
On Monday, 27 July 2015 at 04:11:50 UTC, Rikki Cattermole wrote:

 What I currently have is code templates as follows:

 <?lua
 	echo("<p>" .. consumeNextText() .. "</p>")
 ?>

 Hi there, this is some text!
 Woopity doo.

 <?lua
 	include_text("<?lua echo(\"boo\") ?>")
 ?>

 So it would output something like:
 <p>
 Hi there, this is some text!
 Woopity doo.
 </p>boo

 The languages supported would have to be known and configured 
 at compile time. But theoretically other languages such as 
 Squirrel and PHP should work.
 D on the other hand, would be ugh hard.

 I will be supporting the ability to pass in e.g. data models 
 and even query them. Thanks to reflection that I've added since 
 Cmsed.


I don't think it makes sense doing any page rendering in D, there 
are plenty of good tools that you don't want to compete with.

For instance, for rendering pages I would rather front the D 
backend with some (stateless) node app that fetches the data from 
the D backend and uses something like React to render 
server/client side. If the D backend could implement the upcoming 
GraphQL that would be awesome.

It has the benefit that a) the frontend-end devs still get their 
familiar language, tools and libraries; and b) that all the real 
stuff happens in D.

But I thought this was about Web Services Applications? Which I 
assume to be the outer container/process manager that allows 
services to be registered, re-loaded, routed, etc.
Jul 26 2015
next sibling parent Rikki Cattermole <alphaglosined gmail.com> writes:
On 27/07/2015 6:10 p.m., Sebastiaan Koppe wrote:

 On Monday, 27 July 2015 at 04:11:50 UTC, Rikki Cattermole wrote:

 What I currently have is code templates as follows:

 <?lua
     echo("<p>" .. consumeNextText() .. "</p>")
 ?>

 Hi there, this is some text!
 Woopity doo.

 <?lua
     include_text("<?lua echo(\"boo\") ?>")
 ?>

 So it would output something like:
 <p>
 Hi there, this is some text!
 Woopity doo.
 </p>boo

 The languages supported would have to be known and configured at
 compile time. But theoretically other languages such as Squirrel and
 PHP should work.
 D on the other hand, would be ugh hard.

 I will be supporting the ability to pass in e.g. data models and even
 query them. Thanks to reflection that I've added since Cmsed.


 I don't think it makes sense doing any page rendering in D, there are
 plenty of good tools that you don't want to compete with.

 For instance, for rendering pages I would rather front the D backend
 with some (stateless) node app that fetches the data from the D backend
 and uses something like React to render server/client side. If the D
 backend could implement the upcoming GraphQL that would be awesome.

 It has the benefit that a) the frontend-end devs still get their
 familiar language, tools and libraries; and b) that all the real stuff
 happens in D.

 But I thought this was about Web Services Applications? Which I assume
 to be the outer container/process manager that allows services to be
 registered, re-loaded, routed, etc.


Most people will want to write web applications not web services, 
although they are _almost_ one in the same thing.

So, I've got to take that into account. Although nobody will force you 
to use it.
Jul 27 2015
prev sibling next sibling parent reply "Brandon Ragland" <brags callmemaybe.com> writes:
On Monday, 27 July 2015 at 06:10:29 UTC, Sebastiaan Koppe wrote:

 On Monday, 27 July 2015 at 04:11:50 UTC, Rikki Cattermole wrote:

 What I currently have is code templates as follows:

 <?lua
 	echo("<p>" .. consumeNextText() .. "</p>")
 ?>

 Hi there, this is some text!
 Woopity doo.

 <?lua
 	include_text("<?lua echo(\"boo\") ?>")
 ?>

 So it would output something like:
 <p>
 Hi there, this is some text!
 Woopity doo.
 </p>boo

 The languages supported would have to be known and configured 
 at compile time. But theoretically other languages such as 
 Squirrel and PHP should work.
 D on the other hand, would be ugh hard.

 I will be supporting the ability to pass in e.g. data models 
 and even query them. Thanks to reflection that I've added 
 since Cmsed.


 I don't think it makes sense doing any page rendering in D, 
 there are plenty of good tools that you don't want to compete 
 with.

 For instance, for rendering pages I would rather front the D 
 backend with some (stateless) node app that fetches the data 
 from the D backend and uses something like React to render 
 server/client side. If the D backend could implement the 
 upcoming GraphQL that would be awesome.

 It has the benefit that a) the frontend-end devs still get 
 their familiar language, tools and libraries; and b) that all 
 the real stuff happens in D.

 But I thought this was about Web Services Applications? Which I 
 assume to be the outer container/process manager that allows 
 services to be registered, re-loaded, routed, etc.


The reality is D would be adapted for Web Apps in the tradition 
sense much more readily if indeed we implemented just the Web 
Services in D and left the familiar languages such as Java, PHP, 
etc. alone.

However, those languages (erhmm, especially PHP) are terribly 
slow and do not scale well. Java on the other hand may use vast 
amounts of Ram, but does actually perform fairly well, 
considering the extremely high level of abstraction, and then the 
complexity of that very same extraction with the JMS and EJBs.

A web services container in D would be the most _readily_ useful 
method of injecting performant D into the web services and web 
apps fields.

The idea that D is difficult to use as rendering language is 
certainly true, as is PHP in many respects.

A JSP style implementation without the stupid scriptlets that 
people try to inject is much better for this kind of a task.

Say we have a templated, standard, HTML / CSS / JS page. We could 
then take a tagging language such as the ones like Java's JSTL 
and Expression Language to insert information from the D based 
servlets.

Rendering a complete page inside D would be unnecessary, and a 
major source of headaches. However a D based servlet that 
consists of maybe ~50 lines total that could make callbacks to a 
database, or the web services containers to retrieve basic 
information, wouldn't be a bad idea.

Joking aside, a web services container would be best for D. And 
vibe.d seems to have a fairly good standing ground for this.

For actual web applications, and front-end development currently 
done in your more traditional languages, D could be used, in a 
style similar to Java's JSP, JSTL, and EL. Just without the 
notion of scripts in the pages themselves, as this would mean 
writing an on-the-fly interpreter, or compiling whole pages, 
which surely isn't an option for a compiled performant language; 
if we want it to be readily adapted.

Apologizes if I jumped around a lot, and misspelled. More 
difficult than I thought typing from my phone.
Jul 28 2015
next sibling parent reply "Etienne Cimon" <etcimon gmail.com> writes:
On Wednesday, 29 July 2015 at 00:12:21 UTC, Brandon Ragland wrote:

 For actual web applications, and front-end development 
 currently done in your more traditional languages, D could be 
 used, in a style similar to Java's JSP, JSTL, and EL. Just 
 without the notion of scripts in the pages themselves, as this 
 would mean writing an on-the-fly interpreter, or compiling 
 whole pages, which surely isn't an option for a compiled 
 performant language; if we want it to be readily adapted.

 Apologizes if I jumped around a lot, and misspelled. More 
 difficult than I thought typing from my phone.


Most developers nowadays are having a lot of success building web 
apps with an AngularJS MVC & Vibe.d, rather than rendering the 
page entirely from the back-end. Heck, they can even build 
android or ios native apps with this architecture (see Ionic 
framework). So I think this makes more sense than rendering pages 
in the back-end, even if most legacy web stuff did that.
Jul 28 2015
next sibling parent "Etienne Cimon" <etcimon gmail.com> writes:
On Wednesday, 29 July 2015 at 01:23:54 UTC, Etienne Cimon wrote:

 Most developers nowadays are having a lot of success building 
 web apps with an AngularJS MVC & Vibe.d, rather than rendering


Sorry, I meant with an AngularJS MVC & Web services
Jul 28 2015
prev sibling parent "Brandon Ragland" <brags callmemaybe.com> writes:
On Wednesday, 29 July 2015 at 01:23:54 UTC, Etienne Cimon wrote:

 On Wednesday, 29 July 2015 at 00:12:21 UTC, Brandon Ragland 
 wrote:

 For actual web applications, and front-end development 
 currently done in your more traditional languages, D could be 
 used, in a style similar to Java's JSP, JSTL, and EL. Just 
 without the notion of scripts in the pages themselves, as this 
 would mean writing an on-the-fly interpreter, or compiling 
 whole pages, which surely isn't an option for a compiled 
 performant language; if we want it to be readily adapted.

 Apologizes if I jumped around a lot, and misspelled. More 
 difficult than I thought typing from my phone.


 Most developers nowadays are having a lot of success building 
 web apps with an AngularJS MVC & Vibe.d, rather than rendering 
 the page entirely from the back-end. Heck, they can even build 
 android or ios native apps with this architecture (see Ionic 
 framework). So I think this makes more sense than rendering 
 pages in the back-end, even if most legacy web stuff did that.


This is so very true. Unfortunately, it also assumes some things 
which are still not true:

* Every visitor has a speedy connection
* Every visitor is on a powerful machine (so to speak)

The problem with the first is that, half the the US is still on a 
connection with speeds less than 6mbps. Downloading a whole page 
(such as your Facebook timeline feed, which can easily be 6+MiBs 
[see Akami link]) takes a full minute. That's pathetic for any 
kind of real-world business logic web app. Maybe okay for 
Facebook, but we could do better.

I can't even begin to tell you how many friends I have who are 
non-developers who complain on a daily basis that "they're phone 
has faster connection" or "Facebook loads slow" or "Gmail takes 2 
minutes to open".

The idea of pushing *everything* to the client to render (which 
often means payloads of 4+MiBs) is ridiculous and not being fair 
to over 80% of the world.

http://www.akamai.com/dl/documents/akamai_soti_q213.pdf?WT.mc_id=soti_Q213
Jul 29 2015
prev sibling parent Rikki Cattermole <alphaglosined gmail.com> writes:
On 29/07/2015 12:12 p.m., Brandon Ragland wrote:

 On Monday, 27 July 2015 at 06:10:29 UTC, Sebastiaan Koppe wrote:

 On Monday, 27 July 2015 at 04:11:50 UTC, Rikki Cattermole wrote:

 What I currently have is code templates as follows:

 <?lua
     echo("<p>" .. consumeNextText() .. "</p>")
 ?>

 Hi there, this is some text!
 Woopity doo.

 <?lua
     include_text("<?lua echo(\"boo\") ?>")
 ?>

 So it would output something like:
 <p>
 Hi there, this is some text!
 Woopity doo.
 </p>boo

 The languages supported would have to be known and configured at
 compile time. But theoretically other languages such as Squirrel and
 PHP should work.
 D on the other hand, would be ugh hard.

 I will be supporting the ability to pass in e.g. data models and even
 query them. Thanks to reflection that I've added since Cmsed.


 I don't think it makes sense doing any page rendering in D, there are
 plenty of good tools that you don't want to compete with.

 For instance, for rendering pages I would rather front the D backend
 with some (stateless) node app that fetches the data from the D
 backend and uses something like React to render server/client side. If
 the D backend could implement the upcoming GraphQL that would be awesome.

 It has the benefit that a) the frontend-end devs still get their
 familiar language, tools and libraries; and b) that all the real stuff
 happens in D.

 But I thought this was about Web Services Applications? Which I assume
 to be the outer container/process manager that allows services to be
 registered, re-loaded, routed, etc.


 The reality is D would be adapted for Web Apps in the tradition sense
 much more readily if indeed we implemented just the Web Services in D
 and left the familiar languages such as Java, PHP, etc. alone.

 However, those languages (erhmm, especially PHP) are terribly slow and
 do not scale well. Java on the other hand may use vast amounts of Ram,
 but does actually perform fairly well, considering the extremely high
 level of abstraction, and then the complexity of that very same
 extraction with the JMS and EJBs.

 A web services container in D would be the most _readily_ useful method
 of injecting performant D into the web services and web apps fields.

 The idea that D is difficult to use as rendering language is certainly
 true, as is PHP in many respects.

 A JSP style implementation without the stupid scriptlets that people try
 to inject is much better for this kind of a task.

 Say we have a templated, standard, HTML / CSS / JS page. We could then
 take a tagging language such as the ones like Java's JSTL and Expression
 Language to insert information from the D based servlets.

 Rendering a complete page inside D would be unnecessary, and a major
 source of headaches. However a D based servlet that consists of maybe
 ~50 lines total that could make callbacks to a database, or the web
 services containers to retrieve basic information, wouldn't be a bad idea.

 Joking aside, a web services container would be best for D. And vibe.d
 seems to have a fairly good standing ground for this.

 For actual web applications, and front-end development currently done in
 your more traditional languages, D could be used, in a style similar to
 Java's JSP, JSTL, and EL. Just without the notion of scripts in the
 pages themselves, as this would mean writing an on-the-fly interpreter,
 or compiling whole pages, which surely isn't an option for a compiled
 performant language; if we want it to be readily adapted.

 Apologizes if I jumped around a lot, and misspelled. More difficult than
 I thought typing from my phone.


One of the benefits for D is that we can build up e.g. RESTFUL/SOAP web 
services rather easily. We don't need to serve up generated html/css/js 
but we can serve up assets which are html/css/js that could go through a 
preprocessor and then cache the result.

Either way, I have long since felt that using D in templates is a waste 
of resources. It's doable, very. Just not really worth it.
Jul 28 2015
prev sibling parent reply "yawniek" <dlang srtnwz.com> writes:
On Monday, 27 July 2015 at 06:10:29 UTC, Sebastiaan Koppe wrote:


 For instance, for rendering pages I would rather front the D 
 backend with some (stateless) node app that fetches the data 
 from the D backend and uses something like React to render 
 server/client side. If the D backend could implement the 
 upcoming GraphQL that would be awesome.

 It has the benefit that a) the frontend-end devs still get 
 their familiar language, tools and libraries; and b) that all 
 the real stuff happens in D.


this is absolutely the way to go.

In times of reactive frameworks it makes no sense anymore to 
render html in the backend.
backends/services should concentrate on data transformations (and 
security etc).

in my opinion also the REST style apis will come to an end as we 
can easily have
stateless apis these days ( 86.62%of browsers have websockets 
already according to http://caniuse.com/#feat=websockets ).
The whole ghetto around maintaining state over http for a web 
application is nuts if you think about how native applications 
work.

so the whole discussion about servlets is a bit moot or at least 
its very backward looking.

while its probably a few years too early to see frameworks that 
_push_ webassembly to the client, we already see frameworks where 
javascript (or stuff that then compiles into it) is being pushed 
out. voltframework.com looks quite interesting.

bottom line: in my opinion it will be hard to convince java style 
web programmers to switch to d. it might be a better strategy to 
build frameworks that can be used as solid, fast and stateful 
backends for apps and especially for games.
Jul 29 2015
next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 29 July 2015 at 07:30:50 UTC, yawniek wrote:

 in my opinion also the REST style apis will come to an end as 
 we can easily have
 stateless apis these days ( 86.62%of browsers have websockets 
 already according to http://caniuse.com/#feat=websockets ).
 The whole ghetto around maintaining state over http for a web 
 application is nuts if you think about how native applications 
 work.


But REST is supposed to be stateless! You maintain state in the 
client and use the server like a database/information service. 
Most applications are better off with REST and SPDY as the main 
transport.

Websockets are of limited usefulness, and only for auxillary 
information (e.g. pushing notifications about updates). It's only 
a TCP connection where the server can initiate communication.
Jul 29 2015
parent reply "yawniek" <dlang srtnwz.com> writes:
On Wednesday, 29 July 2015 at 09:22:44 UTC, Ola Fosheim Grøstad 
wrote:

 On Wednesday, 29 July 2015 at 07:30:50 UTC, yawniek wrote:

 in my opinion also the REST style apis will come to an end as 
 we can easily have
 stateless apis these days ( 86.62%of browsers have websockets 
 already according to http://caniuse.com/#feat=websockets ).
 The whole ghetto around maintaining state over http for a web 
 application is nuts if you think about how native applications 
 work.


 But REST is supposed to be stateless! You maintain state in the 
 client and use the server like a database/information service. 
 Most applications are better off with REST and SPDY as the main 
 transport.

 Websockets are of limited usefulness, and only for auxillary 
 information (e.g. pushing notifications about updates). It's 
 only a TCP connection where the server can initiate 
 communication.


sorry typo. i meant "we now can have statefull apis".
and i disagree on the limited usefulness.

do you have REST api in native apps? i don't see much reason why 
we should not develop web applications the way we develop native 
apps.
Jul 29 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 29 July 2015 at 10:39:54 UTC, yawniek wrote:

 sorry typo. i meant "we now can have statefull apis".



Ok, then I get it. ;)


 and i disagree on the limited usefulness.

 do you have REST api in native apps? i don't see much reason 
 why we should not develop web applications the way we develop 
 native apps.


The goal should be to keep the server-side simple, robust, 
transactional and generic. Then push all the fickle 
special-casing to the client side.

Why do work on the server when you can do almost everything on 
the client, caching data in Web Storage/IndexedDB?
Jul 29 2015
next sibling parent reply "Etienne Cimon" <etcimon gmail.com> writes:
On Wednesday, 29 July 2015 at 11:06:03 UTC, Ola Fosheim Grøstad 
wrote:

 On Wednesday, 29 July 2015 at 10:39:54 UTC, yawniek wrote:

 sorry typo. i meant "we now can have statefull apis".



 Ok, then I get it. ;)


 and i disagree on the limited usefulness.

 do you have REST api in native apps? i don't see much reason 
 why we should not develop web applications the way we develop 
 native apps.


 The goal should be to keep the server-side simple, robust, 
 transactional and generic. Then push all the fickle 
 special-casing to the client side.

 Why do work on the server when you can do almost everything on 
 the client, caching data in Web Storage/IndexedDB?


There's a really minimal amount of code on web servers nowadays 
with javascript frameworks and databases doing all the work. I 
actually use the size of a vibe.d application (2mb) to my 
advantage to produce a plugin that will overload certain requests 
on the client's computer (via a windows service or launchd daemon 
and reverse proxy). This allows much more extensive use of local 
resources, which is really untapped way of developing web 
applications at the moment, it really lets your imagination fly.
Jul 29 2015
next sibling parent reply "Sebastiaan Koppe" <mail skoppe.eu> writes:
On Wednesday, 29 July 2015 at 13:22:43 UTC, Etienne Cimon wrote:

 I actually use the size of a vibe.d application (2mb) to my 
 advantage to produce a plugin that will overload certain 
 requests on the client's computer (via a windows service or 
 launchd daemon and reverse proxy). This allows much more 
 extensive use of local resources, which is really untapped way 
 of developing web applications at the moment, it really lets 
 your imagination fly.


That is very interesting. But how do you push those apps to the 
end-users without interrupting their browser experience?
Jul 29 2015
parent reply "Etienne" <etcimon gmail.com> writes:
On Wednesday, 29 July 2015 at 14:30:49 UTC, Sebastiaan Koppe 
wrote:

 On Wednesday, 29 July 2015 at 13:22:43 UTC, Etienne Cimon wrote:

 I actually use the size of a vibe.d application (2mb) to my 
 advantage to produce a plugin that will overload certain 
 requests on the client's computer (via a windows service or 
 launchd daemon and reverse proxy). This allows much more 
 extensive use of local resources, which is really untapped way 
 of developing web applications at the moment, it really lets 
 your imagination fly.


 That is very interesting. But how do you push those apps to the 
 end-users without interrupting their browser experience?


You have to make them download the app and agree to elevate. It's 
not going to be useful for content-based websites, but it 
definitely has potential in areas where a download 
would've/could've been necessary anyways e.g. music/video/image 
editing, phone calls, file sharing, productivity, games, etc.

It really depends on how appealing it makes your application. If 
your offer beats competition by far, a download won't be regarded 
as disruptive.
Jul 29 2015
parent reply "Brandon Ragland" <brags callmemaybe.com> writes:
On Wednesday, 29 July 2015 at 17:40:30 UTC, Etienne wrote:

 On Wednesday, 29 July 2015 at 14:30:49 UTC, Sebastiaan Koppe 
 wrote:

 On Wednesday, 29 July 2015 at 13:22:43 UTC, Etienne Cimon 
 wrote:

 I actually use the size of a vibe.d application (2mb) to my 
 advantage to produce a plugin that will overload certain 
 requests on the client's computer (via a windows service or 
 launchd daemon and reverse proxy). This allows much more 
 extensive use of local resources, which is really untapped 
 way of developing web applications at the moment, it really 
 lets your imagination fly.


 That is very interesting. But how do you push those apps to 
 the end-users without interrupting their browser experience?


 You have to make them download the app and agree to elevate. 
 It's not going to be useful for content-based websites, but it 
 definitely has potential in areas where a download 
 would've/could've been necessary anyways e.g. music/video/image 
 editing, phone calls, file sharing, productivity, games, etc.

 It really depends on how appealing it makes your application. 
 If your offer beats competition by far, a download won't be 
 regarded as disruptive.


I was hesitant to agree with you, as the whole point of a web app 
is to have it *mostly* in the web browser. But one thing is for 
sure a detriment to things: web apps that should have been native 
apps.

There's nothing like firing up a project management system 
online, and wondering why it's slow, unresponsive, and offers 
little *powerful* features. Open Microsoft Project as a native 
app under Windows, and boom. You're in *real* business.

For these kinds of apps, they shouldn't have ever been made "web 
apps" but the way the world works, everybody wants everything to 
be a "google search away" which is great and all, but places 
serious limitations on just exactly what can be done.

A downloaded plugin, would be a man-in-the-middle solution. Users 
get there "google search away" and developers get the necessary 
native speed, flexibility, and components necessary to perform 
better work.

The browser is a stellar user-interface engine. Certainly better 
than GTK+ or MFC by a long shot. I just don't think the browser 
is a useful *operating system* for all these "web apps" that 
should be native.
Jul 29 2015
parent reply "Etienne" <etcimon gmail.com> writes:
On Thursday, 30 July 2015 at 00:08:52 UTC, Brandon Ragland wrote:

 A downloaded plugin, would be a man-in-the-middle solution. 
 Users get there "google search away" and developers get the 
 necessary native speed, flexibility, and components necessary 
 to perform better work.

 The browser is a stellar user-interface engine. Certainly 
 better than GTK+ or MFC by a long shot. I just don't think the 
 browser is a useful *operating system* for all these "web apps" 
 that should be native.


There's been lots of improvements in the DOM, those slick CSS3 
transitions are actually hardware accelerated with OpenGL, lots 
of GUI front-ends don't event have transitions in the first 
place. I wouldn't rely on Javascript for crunching data though, 
the "slowness" you talk about? Mostly stems from that. Otherwise, 
for display, it certainly is a great tool with lots of open 
source components.

Just look at this data table with 640k rows: 


THAT is some good javascript, and it certainly beats what I've 
seen Excel do with sheets harboring 10x less data.

While some are still blaming the hammer, I blame the person 
trying to hit the nail on the head with his eyes closed.
Jul 29 2015
next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 30 July 2015 at 01:42:02 UTC, Etienne wrote:

 There's been lots of improvements in the DOM, those slick CSS3 
 transitions are actually hardware accelerated with OpenGL, lots 
 of GUI front-ends don't event have transitions in the first 
 place. I wouldn't rely on Javascript for crunching data though, 
 the "slowness" you talk about? Mostly stems from that. 
 Otherwise, for display, it certainly is a great tool with lots 
 of open source components.


In my experience performance issues are either DOM/redraw 
related, or old versions of IE. Javascript performance and 
download speed are nonissues if you do it right. Send data in a 
format that compresses well and those 2MB turn into 200K. Add 
caching and background loading... Etc...


 While some are still blaming the hammer, I blame the person 
 trying to hit the nail on the head with his eyes closed.


Yes. Unfortunately many Javascript programmers don't know how to 
do it right... Or their superiors halt development before 
performance tuning because it "works".
Jul 29 2015
parent "Brandon Ragland" <brags callmemaybe.com> writes:
On Thursday, 30 July 2015 at 02:17:34 UTC, Ola Fosheim Grøstad 
wrote:

 On Thursday, 30 July 2015 at 01:42:02 UTC, Etienne wrote:

 There's been lots of improvements in the DOM, those slick CSS3 
 transitions are actually hardware accelerated with OpenGL, 
 lots of GUI front-ends don't event have transitions in the 
 first place. I wouldn't rely on Javascript for crunching data 
 though, the "slowness" you talk about? Mostly stems from that. 
 Otherwise, for display, it certainly is a great tool with lots 
 of open source components.


 In my experience performance issues are either DOM/redraw 
 related, or old versions of IE. Javascript performance and 
 download speed are nonissues if you do it right. Send data in a 
 format that compresses well and those 2MB turn into 200K. Add 
 caching and background loading... Etc...


 While some are still blaming the hammer, I blame the person 
 trying to hit the nail on the head with his eyes closed.


 Yes. Unfortunately many Javascript programmers don't know how 
 to do it right... Or their superiors halt development before 
 performance tuning because it "works".


That's still unacceptable, and by the way, the numbers I were 
using were indeed compress (with DEFLATE) numbers from Facebook.

The average Facebook Timeline (compressed, with DEFLATE) is about 
~4MiB to download.

200KiB isn't bad, and that'll generally be loaded in a second or 
so on most American 6mbps streams (and faster for the other 50% 
with better speeds) but 4MiB compressed is a bit too much.

If you leave that same Facebook Timeline open, lazy loading kicks 
in and within 10 minutes you're total download is ~10MiB (usually 
pictures that get loaded in).
Jul 29 2015
prev sibling parent reply "Brandon Ragland" <brags callmemaybe.com> writes:
On Thursday, 30 July 2015 at 01:42:02 UTC, Etienne wrote:

 On Thursday, 30 July 2015 at 00:08:52 UTC, Brandon Ragland 
 wrote:

 A downloaded plugin, would be a man-in-the-middle solution. 
 Users get there "google search away" and developers get the 
 necessary native speed, flexibility, and components necessary 
 to perform better work.

 The browser is a stellar user-interface engine. Certainly 
 better than GTK+ or MFC by a long shot. I just don't think the 
 browser is a useful *operating system* for all these "web 
 apps" that should be native.


 There's been lots of improvements in the DOM, those slick CSS3 
 transitions are actually hardware accelerated with OpenGL, lots 
 of GUI front-ends don't event have transitions in the first 
 place. I wouldn't rely on Javascript for crunching data though, 
 the "slowness" you talk about? Mostly stems from that. 
 Otherwise, for display, it certainly is a great tool with lots 
 of open source components.

 Just look at this data table with 640k rows: 


 THAT is some good javascript, and it certainly beats what I've 
 seen Excel do with sheets harboring 10x less data.

 While some are still blaming the hammer, I blame the person 
 trying to hit the nail on the head with his eyes closed.


Exactly why I said the browser is an excellent User Interface 
engine, but it's not a good data cruncher, or anything of the 
sorts. A full fledged 3D game in the browser using JS wouldn't 
run as fast as a fully native, well coded one.

Not to mention that JavaScript is inherently one of the worst 
thought-up languages.[2]

Regarding JavaScript being slower, this benchmark[1] seems to 
indicate that on average, JavaScript on V8 is at-least 4X slower 
than a g++ compiled native package. It also appears to use 
anywhere from 2-4X as much memory.

As for why Excel is slow, who knows. I don't genuinely like excel 
myself, but it is unbeatable in feature-set as of yet (personal 
opinion).


[1]http://benchmarksgame.alioth.debian.org/u64/compare.php?lang=v8&lang2=gpp
[2]http://live.julik.nl/2013/05/javascript-is-shit
Jul 29 2015
parent reply "Ola Fosheim Gr" <ola.fosheim.grostad+dlang gmail.com> writes:
On Thursday, 30 July 2015 at 03:56:25 UTC, Brandon Ragland wrote:

 Regarding JavaScript being slower, this benchmark[1] seems to 
 indicate that on average, JavaScript on V8 is at-least 4X 
 slower than a g++ compiled native package. It also appears to 
 use anywhere from 2-4X as much memory.


I think speed optimized javascript is at 50% of regular non-SIMD 
C. Javascript suffers when you use high level constructs and 
convenience frameworks, but so does C++ (which is why people 
don't use them). It will probably take a long time for javascript 
to get proper cross browser SIMD support though...

When you get rid of IE9 the real bottleneck to combat is the C++ 
browser runtime, reflow and "random delays" etc.

Memory usage/performance are issues you can limit by using typed 
arrays/free lists. But the browser impose limitations on memory 
usage...
Jul 29 2015
parent reply "Brandon Ragland" <brags callmemaybe.com> writes:
On Thursday, 30 July 2015 at 05:50:56 UTC, Ola Fosheim Gr wrote:

 On Thursday, 30 July 2015 at 03:56:25 UTC, Brandon Ragland 
 wrote:

 Regarding JavaScript being slower, this benchmark[1] seems to 
 indicate that on average, JavaScript on V8 is at-least 4X 
 slower than a g++ compiled native package. It also appears to 
 use anywhere from 2-4X as much memory.


 I think speed optimized javascript is at 50% of regular 
 non-SIMD C. Javascript suffers when you use high level 
 constructs and convenience frameworks, but so does C++ (which 
 is why people don't use them). It will probably take a long 
 time for javascript to get proper cross browser SIMD support 
 though...

 When you get rid of IE9 the real bottleneck to combat is the 
 C++ browser runtime, reflow and "random delays" etc.

 Memory usage/performance are issues you can limit by using 
 typed arrays/free lists. But the browser impose limitations on 
 memory usage...


This might be true, but then you're boiling down the whole reason 
JavaScript took off: Frameworks. JavaScript is a horrendous 
language to use, unless you throw some common framework at it 
that attempts to unify all the browser quirks into easy APIs, 
such as jQuery or Mootools.

JavaScript was never designed to be a language to run games or 
high-performance software with. The only reason we see that today 
is because of the trend towards "Web 2.0" and "google my 
software" where everyone wants everything to be easily accessible 
in the browser. We an overflow os knuckle-head JavaScript 
developers, and there bosses, we now have what we see today: 
Frameworks on-top of frameworks to complete the simplest things, 
because JS as a language cannot do it effectively.

Any language can be optimized more heavily if we throw the 
framework(s) out. However, your development time sky-rockets. In 
today's moving world, companies simply don't have time for that. 
Thus the end result: bloated web pages that stall and lag due to 
un-optimized framework heavy JavaScript.

In all the years I've been working, there was never one language 
I avoided more: JavaScript. My team and I have nick-named it 
"booty-script" because of it's lack of modern day anything, and 
it's terrible semantics.

Most people don't write JavaScript. They right jQuery, or 
Mootools, or some other framework API that abstracts away the 
JavaScript ridiculousness.
Jul 30 2015
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 30 July 2015 at 14:13:53 UTC, Brandon Ragland wrote:

 This might be true, but then you're boiling down the whole 
 reason JavaScript took off: Frameworks. JavaScript is a 
 horrendous language to use, unless you throw some common 
 framework at it that attempts to unify all the browser quirks 
 into easy APIs, such as jQuery or Mootools.


Javascript is never going to be great, but it is "ok" if you 
approach it like you would approach C and use the Closure 
compiler with type annotations. Closure does a reasonable job of 
constant folding and inlining. Of course, some tricks like 
coercing numbers to int by "x|0" are a bit annoying to type.

Typescript 1.5 is a lot more convenient than plain javascript. It 
emulates some ES6 syntax like proper foreach "for(var e of 
somearray)" and provides typed interfaces and more usual 
OO-inheritance. I am looking forward to Angular2 which is written 
in Typescript.

Browser quirk libraries no longer have merits IMO. For many 
projects IE8 is out, IE9 is becoming obsolete and IE10 is quickly 
replaced by IE11. MDN and caniuseit documents browser support 
fairly well.


 JavaScript was never designed to be a language to run games or 
 high-performance software with.


Yes, also writing games on the web is difficult as the GPU 
capabilities varies a lot.


 Any language can be optimized more heavily if we throw the 
 framework(s) out. However, your development time sky-rockets. 
 In today's moving world, companies simply don't have time for 
 that. Thus the end result: bloated web pages that stall and lag 
 due to un-optimized framework heavy JavaScript.


I think one of the problems with webdev is that 
customers/superiors are lead to expect a lot less development 
time than for native. I sometimes think that the relative 
effortless creation of HTML webpage or setting up a WordPress 
site has a negative effect on expectations for web app 
development.
Jul 31 2015
prev sibling parent reply "Laeeth Isharc" <laeethnospam nospamlaeeth.com> writes:
On Wednesday, 29 July 2015 at 13:22:43 UTC, Etienne Cimon wrote:

 There's a really minimal amount of code on web servers nowadays 
 with javascript frameworks and databases doing all the work. I 
 actually use the size of a vibe.d application (2mb) to my 
 advantage to produce a plugin that will overload certain 
 requests on the client's computer (via a windows service or 
 launchd daemon and reverse proxy). This allows much more 
 extensive use of local resources, which is really untapped way 
 of developing web applications at the moment, it really lets 
 your imagination fly.


Would you care to give a bit more colour on this?  Sounds very 
interesting.  So you have an executable running on client machine 
that they need to download and install (fine for a corporate 
internal application, I guess)?  And then you serve your 
application locally, or from a combination of server and local 
url paths?
Jul 29 2015
parent reply "Etienne" <etcimon gmail.com> writes:
On Wednesday, 29 July 2015 at 16:55:25 UTC, Laeeth Isharc wrote:

 On Wednesday, 29 July 2015 at 13:22:43 UTC, Etienne Cimon wrote:

 There's a really minimal amount of code on web servers 
 nowadays with javascript frameworks and databases doing all 
 the work. I actually use the size of a vibe.d application 
 (2mb) to my advantage to produce a plugin that will overload 
 certain requests on the client's computer (via a windows 
 service or launchd daemon and reverse proxy). This allows much 
 more extensive use of local resources, which is really 
 untapped way of developing web applications at the moment, it 
 really lets your imagination fly.


 Would you care to give a bit more colour on this?  Sounds very 
 interesting.  So you have an executable running on client 
 machine that they need to download and install (fine for a 
 corporate internal application, I guess)?  And then you serve 
 your application locally, or from a combination of server and 
 local url paths?


I can't share source but the idea is simple. You configure a DNS 
subdomain my.domain.com => 127.0.0.1, and test that address with 
javascript when a logins to the public website, if it doesn't 
work you show a message "plugin required". The user downloads the 
plugin and executes it, an elevation request is asked once for 
the exec to copy itself to program files and to register the 
service/daemon or open it (the only user interaction required!), 
and then the page is opened in a new browser window (borderless) 
or he can also refresh the page. The plugin's reverse proxy 
delivers the AngularJs app that uses Json models to populate the 
templates.

The important part is this: Any routes registered in the 
redistributable app will be prioritized over the reverse proxy 
(if the reverse proxy was registered after them). The reason this 
works is, vibe.d calls the routes by the order that they were 
registered, up until the HTTP header is written.

This simple but effective architecture is robust even for public 
applications. If you don't do any code signing, you might have an 
additional popup before you can open it but that's it. The packed 
executable can be as low as 2mb

You can also have a long polling task to check for file updates 
and let the executable replace itself / restart itself.

It's all around fun and games :)
Jul 29 2015
parent "Sebastiaan Koppe" <mail skoppe.eu> writes:
On Wednesday, 29 July 2015 at 17:25:17 UTC, Etienne wrote:

 I can't share source but the idea is simple. You configure a 
 DNS subdomain my.domain.com => 127.0.0.1, and test that address 
 with javascript when a logins to the public website, if it 
 doesn't work you show a message "plugin required". The user 
 downloads the plugin and executes it, an elevation request is 
 asked once for the exec to copy itself to program files and to 
 register the service/daemon or open it (the only user 
 interaction required!), and then the page is opened in a new 
 browser window (borderless) or he can also refresh the page. 
 The plugin's reverse proxy delivers the AngularJs app that uses 
 Json models to populate the templates.


You can even get rid of the download popup by having a hosting 
daemon, which your JS instructs to download and run your web-app. 
It can do all the virtual-host routing, updating, what-not.

It does still requires an install, but only once.

A huge security risk if not properly sandboxed though.
Jul 30 2015
prev sibling parent "Brandon Ragland" <brags callmemaybe.com> writes:
On Wednesday, 29 July 2015 at 11:06:03 UTC, Ola Fosheim Grøstad 
wrote:

 On Wednesday, 29 July 2015 at 10:39:54 UTC, yawniek wrote:

 sorry typo. i meant "we now can have statefull apis".



 Ok, then I get it. ;)


 and i disagree on the limited usefulness.

 do you have REST api in native apps? i don't see much reason 
 why we should not develop web applications the way we develop 
 native apps.


 The goal should be to keep the server-side simple, robust, 
 transactional and generic. Then push all the fickle 
 special-casing to the client side.

 Why do work on the server when you can do almost everything on 
 the client, caching data in Web Storage/IndexedDB?


Because connections are slow, and 80% of the world's "up and 
coming" nations are still way behind European download speeds. 
Chine barely got past 2Mbps last year. 50% the US is still under 
6Mbps. Africa can't get over 1.5Mbps.

Trying to send globs of data to the user to render each and every 
request is aching for a user to reject your service or app as 
"slow and stupid".

The browser was never intended to be a "virtual machine" but 
instead a rendering engine capable of rendering web-pages. Not 
parsing, and then interpreting JavaScript (or should we say: 
booty-script. I've never encountered a more horrid language with 
terrible speeds. V8 runs like a 2 cylinder lawn mower.)

Apps that should be native, should be kept native. The world 
hasn't *really* evolved fast enough yet to actually take on the 
browser as the "app virtual machine" we developers want it to be.
Jul 29 2015
prev sibling next sibling parent reply "Sebastiaan Koppe" <mail skoppe.eu> writes:
On Wednesday, 29 July 2015 at 07:30:50 UTC, yawniek wrote:

 In times of reactive frameworks it makes no sense anymore to 
 render html in the backend.


Nowadays with the many client-side dom manipulations it is 
tempting to just do it all in the client. But in terms of speed 
it also makes sense to do an initial render on the server, and 
only render the delta's on the client.

On Wednesday, 29 July 2015 at 07:30:50 UTC, yawniek wrote:

 backends/services should concentrate on data transformations 
 (and security etc).


Yeah, it makes it easier for frontend development to transform 
data into a nice structure.


 in my opinion also the REST style apis will come to an end as 
 we can easily have
 stateless apis these days ( 86.62%of browsers have websockets 
 already according to http://caniuse.com/#feat=websockets ).


Was a big fan of REST - but since it is hard to aggregate 
requests, you end up making too many - so am looking for 
alternatives.

When you say stateful, what exactly do you want to keep between 
requests?


 The whole ghetto around maintaining state over http for a web 
 application is nuts if you think about how native applications 
 work.


Care to elaborate?
Jul 29 2015
parent "yawniek" <dlang srtnwz.com> writes:
On Wednesday, 29 July 2015 at 14:17:34 UTC, Sebastiaan Koppe 
wrote:

 On Wednesday, 29 July 2015 at 07:30:50 UTC, yawniek wrote:

 In times of reactive frameworks it makes no sense anymore to 
 render html in the backend.


 Nowadays with the many client-side dom manipulations it is 
 tempting to just do it all in the client. But in terms of speed 
 it also makes sense to do an initial render on the server, and 
 only render the delta's on the client.

 On Wednesday, 29 July 2015 at 07:30:50 UTC, yawniek wrote:

 backends/services should concentrate on data transformations 
 (and security etc).


 Yeah, it makes it easier for frontend development to transform 
 data into a nice structure.


 in my opinion also the REST style apis will come to an end as 
 we can easily have
 stateless apis these days ( 86.62%of browsers have websockets 
 already according to http://caniuse.com/#feat=websockets ).


 Was a big fan of REST - but since it is hard to aggregate 
 requests, you end up making too many - so am looking for 
 alternatives.
 When you say stateful, what exactly do you want to keep between 
 requests?


 The whole ghetto around maintaining state over http for a web 
 application is nuts if you think about how native applications 
 work.


 Care to elaborate?


check how volt or meteor work
e.g. https://www.youtube.com/watch?v=P27EPQ4ne7o
the idea is that you don't to the whole MVC pattern twice.

the controler or similar objects reside on the server side, 
reacting on events from both, backends AND frontend/views to then 
act and push data out to be rendered.
aka the data from the backend will not be transformed[0] again 
within the client prior to being consumed by the rendering logic.


[0] meaning that there is no datatype specific code or other code 
that can't be hidden away in a generic framework. you may 
transform it from msgpack/protobuf to javascript object etc..
Jul 29 2015
prev sibling parent "Brandon Ragland" <brags callmemaybe.com> writes:
On Wednesday, 29 July 2015 at 07:30:50 UTC, yawniek wrote:

 On Monday, 27 July 2015 at 06:10:29 UTC, Sebastiaan Koppe wrote:


 For instance, for rendering pages I would rather front the D 
 backend with some (stateless) node app that fetches the data 
 from the D backend and uses something like React to render 
 server/client side. If the D backend could implement the 
 upcoming GraphQL that would be awesome.

 It has the benefit that a) the frontend-end devs still get 
 their familiar language, tools and libraries; and b) that all 
 the real stuff happens in D.


 this is absolutely the way to go.

 In times of reactive frameworks it makes no sense anymore to 
 render html in the backend.
 backends/services should concentrate on data transformations 
 (and security etc).

 in my opinion also the REST style apis will come to an end as 
 we can easily have
 stateless apis these days ( 86.62%of browsers have websockets 
 already according to http://caniuse.com/#feat=websockets ).
 The whole ghetto around maintaining state over http for a web 
 application is nuts if you think about how native applications 
 work.

 so the whole discussion about servlets is a bit moot or at 
 least its very backward looking.

 while its probably a few years too early to see frameworks that 
 _push_ webassembly to the client, we already see frameworks 
 where javascript (or stuff that then compiles into it) is being 
 pushed out. voltframework.com looks quite interesting.

 bottom line: in my opinion it will be hard to convince java 
 style web programmers to switch to d. it might be a better 
 strategy to build frameworks that can be used as solid, fast 
 and stateful backends for apps and especially for games.


I can agree that it would be difficult to convince Java style 
developers to switch.

Unfortunately Java and JSP based web systems are typically very 
business oriented, and deployed for internal uses. Take for 
example 1 World Sync. A huge part of it is built in Java and uses 
JSF. It's super speedy to load pages, but isn't exactly what 
mainstream sites are doing today.

The problem with Java being business oriented is that those 
businesses will be reluctant to try new systems that aren't as 
old, mature, or well-proven.
Jul 29 2015
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2015-07-26 20:18, Brandon Ragland wrote:


 The idea of a JSP like system would bring a lot of the Java guys over to D.

 JSP has JSTL and EL markup on the JSP pages that work well with servlets
 and EJBs.

 I've been fooling around the repos posted here and thinking about what
 it might take to get a framework on top of vibe.d to perform similar
 functions as a Java container.

 I appreciate the links / responses guys. It's always worth the read.


vibe.d has something called Diet templates [1].

[1] http://vibed.org/docs#html-templates

-- 
/Jacob Carlborg
Jul 28 2015
parent "Daniel Kozak" <kozzi11 gmail.com> writes:
On Tuesday, 28 July 2015 at 13:44:59 UTC, Jacob Carlborg wrote:

 On 2015-07-26 20:18, Brandon Ragland wrote:


 The idea of a JSP like system would bring a lot of the Java 
 guys over to D.

 JSP has JSTL and EL markup on the JSP pages that work well 
 with servlets
 and EJBs.

 I've been fooling around the repos posted here and thinking 
 about what
 it might take to get a framework on top of vibe.d to perform 
 similar
 functions as a Java container.

 I appreciate the links / responses guys. It's always worth the 
 read.


 vibe.d has something called Diet templates [1].

 [1] http://vibed.org/docs#html-templates


http://code.dlang.org/packages/mustache-d
http://code.dlang.org/packages/temple
Jul 28 2015
prev sibling parent "sigod" <sigod.mail gmail.com> writes:
On Saturday, 25 July 2015 at 22:47:59 UTC, Brandon Ragland wrote:

 Hi All,

 Not entirely certain if there is a decent D web applications 
 server implementation as of yet, but if there is a project 
 going on, I'd love to have a gander.

 On the off-chance there isn't one, who would be interested in 
 going at it, call it, a 'group' project.

 I've been yearning for a D web app server for a while, as most 
 of my day to day work is done on Java EE containers (think 
 Glassfish, Weblogic, etc. Java Beans, lalala) and the insane 
 system usage has bothered me from day one.

 There's Wt for C++, although I don't see much coming from that, 
 though the concept is grand. Rust has a few up and coming web 
 server frameworks as well.

 D could really excel here.

 -Thoughts? Am I crazy (probably)?


Sometimes I have the same thoughts. Despite that I use vibe.d in 
experimental project at work.
Jul 26 2015