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: http://ui-grid.info/docs/#/tutorial/404_large_data_sets_and_performance 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: http://ui-grid.info/docs/#/tutorial/404_large_data_sets_and_performance 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