

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

======
bkirkbri
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](https://github.com/OtherPeoplesPixels/curmudjeon)

------
TazeTSchnitzel
PHP has the V8 extension you could use similarly:

[http://php.net/manual/en/book.v8js.php](http://php.net/manual/en/book.v8js.php)

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

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

~~~
ssmoot
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

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

~~~
ssmoot
I'm definitely interested in playing with React. My Angular experience was
pretty painful.

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.

~~~
RussianCow
> You're also throwing in a framework requirement, a need to maintain it,
> spreading your data-binding across the page, adding abstractions, etc.

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

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

[https://github.com/KnisterPeter/jreact](https://github.com/KnisterPeter/jreact)

