[mlangenberg]

Don't people realize that returning HTML instead of JSON will solve their problem for 80% of the use cases?

Looking at Relay/GraphQL, the whole picture appears as a gigantic layer of indirection to generate a DOM tree, something you could do serverside 10 layers below.

Even 'Components' are just fragments of HTML, retrieving them in the format you want from the server is much easier. And be honest, replacing a fragment of HTML in the DOM is fast enough for most applications. (don't delete form input, though)

How does all of this bring Web Development forward? Look at this blog post for example: http://fancypixel.github.io/blog/2015/01/28/react-plus-flux-...

In 2006, after part 1 you would be done and call it a day. Now I understand that today you need 'realtime' updating. But the "notification count is off by one" Facebook example is really bad, because instead of doing all the math in JS, one can simply do a GET request to fetch the count from the actual Single Point Of Truth, which is your database.

Did this get so complicated because front-end development and back-end development is separated at many places?

[meistro]

Agree that the trend to assemble HTML client side has complicated development way more than it should have. However, returning html fragments isn't the solution for all use cases. Consider native apps for Android/iOS/OSX/Windows. They will need data to be delivered via an API. Instead of creating a one-off data pipeline for web browsers, consuming data from a standard API cuts out the need to assemble views for a specific platform. Creating applications via the browser just isn't up to par with the ease of creating applications in other environments (mobile, pc).

[babuskov]

You can have both.

The way I did this in some of my apps is that JSON data is shared between web and Android/iOS client, BUT rendering that data into HTML is done server side:

The server detects if the request is coming from the browser or client app. If it's the client app. it just hands over the JSON data. If it's the browser, it uses the same data to render HTML and sends that to the browser.

[tomjen3]

On an architecture like Facebook they don't have a database and it wouldn't surprise me at all if the unread count was computed before you logged on. If you want to hide that for the client (so that it actually goes away the moment you click the notification) then you need to use some client state and when you need client state you can't just send dom objects.

In general things gets way, way, way more complicated once your system becomes "distributed".

[kansface]

HTML fragments are a (very) poor solution to real time websites.

Applications that use streaming data sets tend to use the data for more than just presentation. Does the backend send both HTML and JSON? The backend can't send the entire data set because that's too slow; the client needs to be responsible for maintaining its own copy of the data. What happens when there is a bug and the two sources are inconsistent?

Even if the client doesn't need the data, HTML fragments suck for practicality.

Does your website have any forms? You now have to write a bunch of code to copy the data and preserve the focus. Does your website ever use JS to update the DOM in response to user action? Does your website ever suck in any data from a third party? You now have to compare the state of the DOM (or whatever data generated it) against the HTML fragment and do something sane.

Even if you solve the problem of consistency and applying fragments to the DOM, chances are you will be left with performance problems. You will need to batch updates to control repaints.

Maybe, performance isn't an issue or you solve it, too. Congrats, you just spent man years rewriting React.

[quest88]

You don't have to write a bunch of code for forms, that was written 10 years ago.

Also, you wouldn't apply generating html on the server to everything, on the parts that make sense. If you want to use JS to update part of the DOM (e.g. showing an error that passwords don't match), then you'd obviously use JS. It's completely ok to use the right tool for the right job.

[exogen]

> Also, you wouldn't apply generating html on the server to everything, on the parts that make sense. If you want to use JS to update part of the DOM (e.g. showing an error that passwords don't match), then you'd obviously use JS.

In practice, this actually sucks to do. Now you need to query the DOM to get a handle on all the places you want to inject dynamic parts into. Now you've got coupling between the structure generated by the server and all the selectors in your client JS targeting those nodes. What if your client JS is served from a CDN and you can't guarantee the new version will be served up at the same time the server starts outputting different markup structure? You not only need to keep your code synced in two places, you need to keep the distribution of it synced. If it had all been generated in the client JS in the first place, you wouldn't have to worry about it.

And if an update to that markup arrives from an AJAX request or whatever, wiping out the existing markup as you're suggesting? you lose the dynamic stuff you injected and gotta do it all over again.

> It's completely ok to use the right tool for the right job.

Why is the server the right tool for generating DOM structure, something only a web browser cares about? For static documents, sure it still makes sense. But in the age of the DOM representing an application, people are rightly questioning why you'd ever generate the DOM structure on the server in the first place: it not only causes jank but just doesn't make intuitive sense.

[ak1394]

One huge advantage of serving data to the client app via some API, is not having to worry about clients application state.

It greatly simplifies development of any but the elementary webapps.