ReactJS in Java Hello World

http://aryweb.nl/2014/12/09/ReactJS-in-Java-Hello-World/

by swah • 12 years ago

56 13 12 years ago

Bahamut• 12 years ago

"Server rendering is not about SEO, it's about performance. Consider the additional roundtrips to get scripts, styles, and subsequent API requests. In the future, considering HTTP 2.0 PUSH of resources."

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.

TazeTSchnitzel2• 12 years ago

It's not faster on a mobile device. A pre-rendered page loads quicker.

ProCynic• 12 years ago

Just anecdotally, I've found that the second round trip overwhelms any performance gains from not rendering on the server, especially if you have to boot up a heavy framework such as e.g. angular before even starting it.

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

ssmoot2• 12 years ago

JSON is just banging strings together on the server side.

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

RussianCow2• 12 years ago

If your requests are large, then it's probably much quicker to deliver HTML, and outright skip the interim parsing/programatic-markup-construction penalty.

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.

tracker1• 12 years ago

But it isn't just the data and templates... Server-side rendering for an initial view puts the initially rendered data request(s) closer to the database(s). Not to mention the amount of JS that has to cross the wire and get parsed. It depends on your needs.

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.

albemuth• 12 years ago

Dion Almaer tweeted a video comparison using a 3g-throttled connection: https://twitter.com/dalmaer/status/538906815010836480

TazeTSchnitzel2• 12 years ago

PHP has the V8 extension you could use similarly:

http://php.net/manual/en/book.v8js.php

arenaninja• 12 years ago

You mean that I could do my templates and bindings in React isomorphically and choose whether the templates are prepared by PHP or the client? This I could sell to my boss...

bkirkbri• 12 years ago

This approach has been really helpful for us. We recently open-sourced our Clojure library[1] for running React on Nashorn (the Javascript engine in Java 8). Currently it consumes Hiccup-style markup, but we hope to add Enlive- and Om-style interfaces in the future.

[1] https://github.com/OtherPeoplesPixels/curmudjeon

bokchoi• 12 years ago

I just came across this project yesterday which packages up this technique in a library:

https://github.com/KnisterPeter/jreact

ReactJS in Java Hello World

Related Stories