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.
