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.

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.

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.

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?

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.

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?

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?

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?

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 :)

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.