ReactJS in Java Hello World
aryweb.nl
aryweb.nl
This caught my eye, since what is being said now contradicts this directly, that it is much faster to host a static app on a CDN and only interact with the backend for consumption of APIs.
Rendering HTML on the server side is just banging (somewhat bigger) strings together.
JSON has lighter-weight transfer than HTML, but after compression the real-world impact is probably pretty marginal.
Say the JSON request was 50% fewer bytes though. It's probably only 20% faster to generate server-side (WAG). If TTFB is 50ms for HTML, maybe it's 40ms for JSON then. But then you render the HTML with a very fast renderer, while you must first parse the JSON into a JavaScript object. Then you create HTML elements paying most of the same rendering costs.
If your requests are fairly small and update only a small portion of the page, maybe the JSON is faster. I think you could consider this the "traditional" use-case for AJAX. The JSON isn't really the important part there.
If your requests are large, then it's probably much quicker to deliver HTML, and outright skip the interim parsing/programatic-markup-construction penalty. IME. Which seems to be the strategy of sites like Twitter.
I think that's a much simpler to reason about and execute solution as well.
My theory is that the only way that formula really swings in favor of JS, SPA, etc is if your application is a platform for multiple clients, wether that's businesses or end-points (JS/SPA, iOS, Android, etc), so you get a lot of mileage out of your API. But there's no scenario in which that's the _simpler_ overall solution I think. Though you might get benefits from teams dedicated to each platform, allowing them to ignore the complexities of the API, simplifying their individual domains overall. Which seems like a balancing act I suppose.
But circling back around to your comment, for the majority of platforms, rendering on the server allows you to write less code, and burn fewer total CPU cycles to render a request. If, like me, your typical applications are business oriented content-management or reporting based.
I think XML makes more sense than JSON for data transport in most cases. Richer types (you can actually represent Dates for example), faster transformations, you get to avoid programmatic generation and slow client-side templating. OTOH if your responses are messages instead of data, and you're going to be handling them programmatically anyway, it's hard to beat the convenience of JSON.
/end-rambling
If you need to be able to have a user jump into any given page from a search engine result, it matters even more. Initial page rendering is paramount. Depending on your usage a fairly simple flux application (flux, react, templates => broserify) will yield out a 500kb JS payload pretty easily. Which in the scheme of things really isn't too bad.. but it's a lot more than, say 30k of HTML for the initial render... not to mention parsing time and display of additional resources (images).
I try to avoid images (save for logo) in the shell/design of a site. favoring CSS tricks and even multiple layers. It was done a while ago, but there are relatively few images on photogallery.classiccars.com (other than the gallery images) for example. It was pretty much my first SPA that needed to be search engine accessible about 3 years ago.
Today I'm working on a flux application that will share server/client logic using Yahoo's tooling as a base. It isn't really much easier in the end than progressive enhancement over HTML delivery. Where it does help is allowing for the same code client and server, and a lot of conditionals for optimal rendering for browser or mobile (minimal useragent detection). Initial renders for mobile devices are very light. Some reactive design (bootstrap base) catches the rougher edges. And progressive enhancement takes the rest.
What this allows for is a very nice initial rendering system that is highly cache-friendly. That output caching is what can allow a site to scale to a much larger load. Caching reverse-proxy servers can ease the stress on back-end servers. Client-side enhancement allows for logged in users to get the whole picture while still working for others.
Being able to share a single framework is a huge boost. Not trying to manage a server-side only rendering system... bolting on client-side templating beyond that is really nice. I agree that it isn't simpler overall... but will argue that it is easier to maintain, especially when you aren't context switching for server/client tooling.
The problem is you can't easily send HTML to update many parts of the page. For instance, if you have messages as part of your app, but there are multiple ways to read a message, you have to make sure all of those are updated when you read one. It's WAY easier to just have the client know what to update and do that automatically, rather than having the server send several bits of HTML. There's also the fact that you don't have to wait for a response from the server before updating the app, so you can see the result of reading a message instantly (which becomes really important on high-latency connections like 3G).
So it certainly depends on your use case, but I think letting the client handle templating/HTML generation is a much better default than the server sending bits of HTML. In my experience, the cost of HTML generation in React.js is pretty minimal. And with React allowing server-side rendering, there really aren't that many drawbacks.
If I can summarize your point: Data-binding can simplify complex pages.
That can be true. I do think most page interactions for most websites don't come close to approaching that level of complexity however. And even then, a helper-function that takes one message and performs multiple assignments can be simpler to write, simpler to understand and simpler to maintain. You still have to explicitly bind the data after all. If you only need to make one update, such as a message post in a chat application, then you're probably not saving a lot from a pure character count perspective.
You're also throwing in a framework requirement, a need to maintain it, spreading your data-binding across the page, adding abstractions, etc.
I'm not sure what you mean by not waiting for a response from the server before updating the app, though I suspect it implies even more complexity (local storage, synchronization, out-of-band management of failures, etc).
From a maintenance stand-point: $(".content").html(response) has had a very long shelf-life. Where you can probably put a 2-year expiration date on any project targeting most of the handful of popular JavaScript MVC frameworks. Trying to predict which one is going to go the distance, not replace major components in that time, and provide a smooth, relatively painless upgrade path is probably futile I'd guess.
Well now you're getting into the framework-or-not debate, which I don't really care to argue. (There are valid arguments on both sides, and it's really a judgement call you have to make for each specific application, but it seems like that's been beaten to death here on HN.) I was specifically replying to your point about having the server generate all HTML changes, which I think is generally a bad idea.
> If you only need to make one update, such as a message post in a chat application, then you're probably not saving a lot from a pure character count perspective.
Either way, the "character count" of the data being sent over the wire shouldn't be an issue, and if it is, that's an edge case and not the general rule. Saving a few bytes on each response is not why JSON is used for data exchange.
> I'm not sure what you mean by not waiting for a response from the server before updating the app, though I suspect it implies even more complexity (local storage, synchronization, out-of-band management of failures, etc).
That's not what I meant at all. If the server is your templating engine, then you can't update the UI until you get a response from the server. So that means, if I click to read the message in my chat application, the UI doesn't acknowledge that it's been read until I get a response from the server, which can be more than a full second in a high-latency environment. In something like React, I can instantly update the UI before the request even finishes.
Having said that, you make web apps seem trivial to develop. In practice (at least in my experience), many (most?) web apps are complex. I've been bitten too many times by projects that seemed "too simple" for a framework. If the web apps you're building really are that simple, then I think your solution is great, but I think most of today's rich web apps aren't simple CRUD applications anymore.
> From a maintenance stand-point: $(".content").html(response) has had a very long shelf-life.
It's also a pain in the ass to maintain. You have to imperatively define changes to your UI based on different events, which makes refactoring difficult and often leads to spaghetti code. There's also the fact that you'd have to keep UI state on the server as well (if this menu is open, change this thing, else change this other thing), which opens a whole new can of worms.
> If I can summarize your point: Data-binding can simplify complex pages.
React actually doesn't do data binding. The reason React is awesome is because it isolates different parts of your app and allows you to define the UI almost declaratively. Rather than keeping track of the current state of your application at all times, changes in state cause React to just (conceptually) re-render components. So your components essentially become pure functions that take state and render a UI. And for event handling and dispatch, check out [Flux](http://facebook.github.io/react/blog/2014/05/06/flux.html) if you haven't already. Even if you don't use React specifically, I think the architecture (treating components like pure functions
Let me know if I'm misunderstanding the architecture you're proposing, because architecture is something I've thought about a lot and am genuinely interested to see how others are structuring their web apps.
The isomorphic model is that the first page load happens on the server (1 round trip), and that any additional page loads hit the api directly and re-render the page in the browser (also 1 round trip).