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..
