> I would imagine it's possible to greate "progressive enhancement" stype React components, so that you'll yield virtual DOM for a plain input box, and somehow enhance it with a auto-complete JS.
You can put initialization code that needs to be done both in client and server in componentWillMount. Code that needs to be executed only in the client (ex jQuery integration) should be in componentDidMount which is only executed in the client.
Thank you for that. I was about to ask whether react on the server + react on the client is possible (instead of exclusively server or exclusively client).
Is there a tutorial targetting such scenario specifically?
Speaking of reactive DOM and JVM languages, this [1] impressed me greatly about a month ago. It's using Scala.js which is coming along fast w/ Scala.Rx and ScalaTags. I found it's a great way to share rendering code between the server side and client side. I was also impressed w/ the readability and small size of the TodoMVC app [2].
It is not necesssary to execute JavaScript on the server-side, or to use React.js at all (although it is a pretty neat tool.) For instance in Backbone, you can call setElement() on any view to replace its on-screen element with one that you've pre-rendered. If you're clever about templates this means that you can have views that both know how to build themselves up from zero, and can also attach to existing views on screen so you can save yourself that rendering time when you visit the page.
This could result in code duplication, but the end result is the same: a complete state of the application can be rendered server-side and then can evolve independently on the client side.
How are you going to make Backbone calls without Javascript? I believe the author's goal was to allow his single page web app to be properly indexed by search engines (which don't execute javascript) without having to change any of his code.
What he's saying is that the views you want to be SEO'd can be generated server side and bootstrapped into Backbone (hook backbone views into an element that is rendered server side).
I currently do this too - I'll add that it is helpful to use a templating language that will work both server side and client side so you only write your templates once.
What does become a pain is doing routers/controllers both client side and server side - end up writing some code more than once and in different languages. Harder to maintain, especially when changes are made.
Right, and if you want to generate them server side, you either need to have separate templates for server side and client side, or you can execute the javascript on the server (which is what the OP decided to do).
Noone is saying there aren't other solutions to the problem, but I think the OP's solution met his goals pretty well and I thought it was a neat concept.
So, in the past I achieved what the parent was talking about by using a templating engine that could be rendered natively by my server side language and by js. In this case it was moustache. With a little config glue my templates could be referenced from both the browser js (in which I called them in by backbone render method) and in rails (when they were rendered as partial calls in my views)
The nice thing about using React server-side rendering is that you only have to to implement your rendering logic once and run it in both client and server. While you need to take a little care (client-only code goes in componentDidMount, only require client only libs in client-only scope) it's fairly painless. I have my Python app return json and pipe it through a node subprocess for the first page load.
If all your content is generated by a single page web app
that downloads data and executes JS, your site won't get
crawled at all - no popular search engines executes JS.
It's not worth relying on IMO. We had some pretty straight-forward backbone views populated by AJAX content in production, and it was never crawled. In general it's very unclear what capabilities the crawler is capable of.
This is sort of a tangent question but is relevant to Nashorn and server side JavaScript execution. Is there a standard practice for sandboxing server side JavaScript execution?
I'm asking because my product has what I call "Smart Attributes" which are basically programmable context aware metadata. These "Smart Attributes" are designed to be attached to a Git commit, GitHub pull request, diff lines, etc. and can be programmed in JavaScript to react to what it is attached to.
In the beginning I gave the user the ability to execute their Smart Attribute scripts on the server side but I eventually removed that option because I didn't have the time to fully think it through. Basically I was paranoid about missing something that would allow them to do dangerous things on the server. This was a couple of years ago and I was using Rhino from Mozilla.
Now that Nashorn is available, I've been thinking about JavaScript server side execution again, and was wondering if there were any best practice sandboxing methods and/or libraries. If anybody knows of any good documentation or libraries for sandboxing in Nashorn, I would love to hear about it.
> Serving HTML from the server is great for search engines.
Google and the other search engines should go with the times and start to render and index single page js applications just like they index html pages. Executing js on the server and get the resulting output is a solved problem. JS is enabled by default on all browsers that matter (and very difficult to disable), I don't understand why we still have to play nice with search engines and render the html on the server as well just for them.
That link describes a method for translating a URL where a static version of a dynamic page can be found. So you still have to serve and generate static content yourself. So we're not quite there yet. But seems like at least Google has started executing _some_ JS. There are more search engines than Google though :)
It would be great if Nashorn could be used as part of a headless browser but I think that's still a long way off it it ever comes to pass.
Browsers have become extremely complex beasts. It is very difficult to simulate one using anything but the original browser code. So my bet is still on phantomjs.
I firmly believe that search engines will have to execute JavaScript as well (if they don't already do it). I think this is just Google's attempt to put off the inevitable for a little while longer: https://developers.google.com/webmasters/ajax-crawling/docs/...
Nice article! We're currently also coding a single page Web app with React, and we're planning to do the same. I wonder, though, why do the server side part in the Jvm and not node? My idea was to use the same API-calling code on the client and the server, and just have a Node instance that lives on the same server as the backend make those Http requests when serving the first page.
Any reason not to do this? (we're on Mono, not JVM but there's plenty of C# JS engines too
Calling out to Node is certainly not the end of the world :) I just wanted so show how convenient it is to do when you're on a JVM anyway. Only actual benefit is the API part, i.e. not doing remote calls, just invoke your API in procrss.
XSS works because the browser uses "eval" for some attributes, for example <img src="x" onerror="alert(1)">. React never uses eval internally so this class of attacks cannot happen on the server.
In order to exploit that vulnerability, improper string concatenation is the most used technique (see SQL injection).
In React, you don't use string concatenation to build the Virtual DOM. This way you cannot fool React into setting properties that the developer didn't explicitly let you.
Another advantage is that each value in React world is typed. It is either a string which is always escaped, or a component. You cannot turn a string into a component unless the developer explicitly let you.
React has been designed with security in mind and prevents by default a large amount of attack vectors that exist in the browser environment.
You can put initialization code that needs to be done both in client and server in componentWillMount. Code that needs to be executed only in the client (ex jQuery integration) should be in componentDidMount which is only executed in the client.
I'll make sure it is documented. Edit: https://github.com/facebook/react/pull/1288/files