React: Finally, a great server/client web stack
eflorenzano.com
eflorenzano.com
PLEASE JUST GIVE ME A STATIC PAGE WITH YOUR CONTENT.
I really do not care if the comments don't refresh live.
It found a performant happy medium, which is something I hope React will enable a lot more people to do with a lot less work.
> I've thought for a long time (and blogged about it previously) that the ideal solution would fully render the markup on the server, deliver it to the client so that it can be shown to the user instantly. Then it would asynchronously load some Javascript that would attach to the rendered markup, and invisibly promote the page into a full app that can render its own markup.
That is, everything is rendered server-side for the reasons you outline, but that rendering logic also lives on the client should something need to update. This post doesn't detail exactly how to do all that, but it sounds like it's scheduled as a future topic.
the downside to his reasoning is that he is tying himself to a single back end (node) if he used something like mustache he coulkd use any backend, but mustache implies parsing templates on the client. googles closure compiles to javascript functions and I am sure something like that exists for mustache and this would seem very sensical.
Converting a large string to a dom element is not expensive, it is when that dom element is added to the actual display tree when things go a bit awol, this is to be expected, redrawing any GUI costs a lot.
React is an excellent library and I am glad people use it, none of the ideas are radical however.
fwiw, React isn't tied to Node: I've used it with Django via PyExecJS (which just uses raw JavaScriptCore).
this technique is called pre-rendering, and yes, I am amazed people don't do it.
"PyExecJS (which just uses raw JavaScriptCore)." this seems pretty slow or can you cache the execution function. (aka you don't have to parse the js multiple times)
Our backend is jvm so we decided on closure, with this on startup we compile our templates on the server and then pass the rendering functions around pumping the data into it to render initial pages. At the same time, we compile the same templates into javascript functions which are included into our app via the closure dependency system to render on the client. This has the advantage of not having to parse and "compile" a template at the point of delivery.
This is why I think react is an excellent library, because it allows anybody to do this and brings this notion into the minds of developers who jump easily on bandwagons.
I also think that the react team are well on their way to building a library which would fair excellently under all sorts of static analysis
We are actively working on more static analysis tools for React: it's certainly one of our major priorities.
Yes, there are use cases for it. But doing it just because you can, because it's supposedly "cool", is also hurting other use cases.
Maybe a tiny bit. I guess. Really, I'd just reload the page if I wanted to see recent changes.
Why not deliver an RSS/Atom feed with the page and a standard feed reader within HTML that could present the content, polling at specified intervals.
In the same way that HTML finally standardized on HTML5 semantic page markup (not that HTML1.0 was grossly inadequate), and we're finally getting integrated video / multimedia support (though lacking the ever crucial "off" switch), once you dig through all the bullshit and hype, most of Web 2.0 corresponds to "we can update the page you're looking at while you're looking at it".
Some client-side capabilities to sort and filter content would finish off about 90%+ of the use cases. Good enough.
And you'd end up with far fewer monstrosities such as Facebook, Gmail, G+, etc., in which a simple content stream has a client-side footprint of 1-2 GB. SRSLY?
Yes, the standard problem of having users upgrade their client software to support the featureset remains, but there are still huge numbers of what are effectively Web 1.0 sites (Craigslist comes to mind) that are phenomenally useful and successful.
I've had a very late and passionate come-to-Jesus love affair with RSS/Atom feeds. Taking Craigslist, for example I can get an RSS feed of any given category search:
http://www.craigslist.org/about/rss
Remember "Web agents", you know "a personal online assistant that would scour the Internet for you"? Well, this is it.
Combine that feed with rsstail and multitail, and you can track items of interest in a console window. Find something particularly useful? Fire off an email alert to yourself.
http://www.reddit.com/r/dredmorbius/comments/1udv6i/further_...
I've got Chromium running on my Thinkpad T520i, sucking down about a gig and a half of RAM. newsbeuter tailing 85 feeds is around 300 MB (a single Chromium browser tab), and rsstail weighs in at about 145 MB resident. Since they're only intermittently active, they swap out with very little performance overhead.
The existing Web design model is a fucking trainwreck waiting to happen. The browser-as-app-platform metaphor has its advantages, mostly in rapid development, though that's also a weakness (users HATE change), and it's a bastardization of two competing uses (content vs. app).
Much of the design and feature set serves advertisers and NSA water-carriers far more effectively than it does users. Sadly, that's where the funding comes from, so it's no real surprise. Be careful what you incent for, you'll get it.
So are my critiques. In particular, that the Web alternatives aren't as fast or light as native apps.
Purely native apps haven't "lost the war". They are the battleground for the most part on mobile devices, as you note, though you omit the observation that these typically operate via an API, which is in fact the direction I'm leaning as a hybrid browser/app model. Fully native apps retain crucial advantages in many spaces.
I'm curious as to what aspects of this you consider to be FUD? I'm reporting actual memory utilization for apps doing comparable tasks, at least as far as rendering raw information is concerned. If you want to consider graphical presentation, I've also got a number of PDF files open using xpdf and evince, both of which perform full graphical rendering including images. The maximum RSS for these is 14 MB, and the 20 or so processes running here have far less system impact than my chromium child processes.
The train wreck I'm describing is precisely that. Light websites are generally not an issue, but the full-fledged app instances, again, Google+, Gmail, and the like, cause wild amounts of swapping and instability, to the point that I make minimal use of them, and where possible find alternatives. The RSS/Atom readers I mention aren't doing the full work of a Web browser, but that's precisely the point: for keeping me informed of an information stream, they're far more than sufficient, and require far fewer resources. I can open an item in a console-mode browser (and yes, that's old-school and an acquired taste), or pop over to a browser and read the item. It's far less overhead than keeping the stream in my browser at all times, and as I noted, the RSS readers offer hooks to perform other local actions if I choose.
I've written recently of the frustrations I'm increasingly having with browsers in general: they serve neither the needs of application users nor of content readers particularly well. Quoting myself:
"It's neither a good reading environment -- for that you'd want something like Readability, Pocket, Instapaper, or an eBook management tool such as Moon+Reader, Kindle, or (bad as it is) Calibre -- nor a decent applications environment: it's bloated, crash-prone, slow, full of security holes, and underfeatured relative to native applications.
"However in both cases the browser's ability to load and display or run arbitrary content makes it convenient."
https://news.ycombinator.com/item?id=7062219
I see a few possible directions things could head:
⚫ Continue down the current path. This is the course of least resistance.
⚫ I don't know where the HTML working group(s) are headed, but continuing the pattern of HTML5 of offering highly semantic markup and leaning in the direction of an API model of HTML rather than a designer model (or in addition to) could be useful.
⚫ We now have <header> <article> <aside> and <video>. How about a <stream> as I described, and perhaps native <plot> features which could present graphics based on realtime data updates? Again, a huge class of applications now essentially consists of "poll regularly for new data, update stream, present graphics, respond to user inputs".
⚫ A content-oriented browser which strips out virtually all distractions, and provide vastly improved content management and referencing capabilties (see: zotero). Readability, Instapaper, Pocket, etc. approach this. I presently have a local "unstyled.css" stylesheet which I apply to many sites. It works best on bare-naked pages (without any native styling or table/frame based page layout) but works pretty well on most minimally-styled pages. And it is, for my purposes at least, almost always a huge improvement over native presentation. In other cases I've extensively modified how pages present themselves. See: http://www.reddit.com/r/dredmorbius/comments/1tniu3/user_sit...
⚫ An application-development platform based on (mostly) standard APIs and an HTML/SHTML transport back-end. This would be the area you're most interested in.
I'm not convinced this is the way things should go, but it seems it would resolve some of the present tensions in Web development and use.
No, the majority of people agree. And contrary to what javascript happy dumbasses keep repeating, the majority of new development is absolutely not doing everything client side. It is sad that the web is so fad driven, but this stupid fad will pass just like flash intros and spinning under construction animated gifs.
Do you seriously believe this?
The virtual DOM is probably the biggest elephant in the room. It begs the question: why the hell isn't the REAL DOM like that?
But yes I realized I'm arguing about the wrong thing - about web applications, not (most) websites. Whoops.
I know this may sounds sarcastic, but I am totally serious.
The article just says it's easy. It doesn't provide any concrete examples.
I imagine it would be easy in Node to do this but what about Ruby, Python etc.
It doesn't provide code, but it points out that you can render to a string. It is literally that easy — you can just call React.renderComponentToString instead of React.renderComponent, though in practice there are Node libraries that make this even easier.
> I imagine it would be easy in Node to do this but what about Ruby, Python etc.
Well, it's a JavaScript library. If you can run JavaScript, you can render React templates. For example, Instagram is a Django app that runs a Node subprocess to render templates.
The fact is, the web world is evolving at an extremely fast rate, and leaving the native world in the dust.
The "web world" hasn't even caught up to the native world yet. It may be evolving very rapidly, faster than native, even, but it's still behind.
Add some bacon (js) to your salad and you have a healthy and balanced meal.
make a "salad" out of bacon and and mayo dressing and you have a problem.
There's a happy middle ground between heavyweight javascript SPAs and static pages.
Frankly I love it when I interact with a web page and it doesn't have to reload the whole page just to update a single element, article, etc that I requested.
But neither am I fan of overly heavy frontend JS apps, like how Twitter used to be [1], or Quora seems to be, for example. Especially since I'm a chronic browser tab abuser where JS-heavy pages bring my browser to a halt or make it chug.
So yeah, aim for that sweet spot happy middle ground when possible.
[1]:https://blog.twitter.com/2012/improving-performance-on-twitt...
But you can also use your existing Backbone Views (if they have some nice, say, formatting or data-munging-for-display logic in them) and simply replace your render function with React.
The next step you can take is replacing your HTML templates with React's JSX templates, if you'd like...
I'm still up in the air on how I feel about the whole JSX thing but I'm willing to give it a try.
Also, I'm not sure we want a full rendering on the server. That will make the page appear to have a longer loading time rather than the other way around. Unless I'm misunderstanding what you're trying to say.
It does sound interesting though. I'm looking forward to your follow up posts.
If the string rendering is your initial page[0], why would it be difficult for crawlers do index pages?
> Also, I'm not sure we want a full rendering on the server. That will make the page appear to have a longer loading time
Servers tend to be beefy and have caches up the ass. Serving a pre-rendered "home" has been found time and again to be faster than generating it from the raw data on the client, and definitely gives the impression of faster loading.
[1] "a tiny and isomorphic URL router for JavaScript http://github.com/flatiron/director"
[0] http://blog.nodejitsu.com/scaling-isomorphic-javascript-code...
[1] http://nerds.airbnb.com/isomorphic-javascript-future-web-app...
It's like McDonald's named their new hamburger the RESTful Patty.
Or you could just use HTMLbars/Handlebars. Seems like "JSX" is just a more complicated version of a Mustache-esque logic-less template.
We changed the license two years ago.
JSX + React produce functions that return React's representation of the DOM, their "virtual DOM", and React knows how to make small mutations based on state. If a change in state only needs to add a class 10 levels deep in the hierarchy, that is the only change that happens in the real DOM; it doesn't have to re-render the entire template.
It makes for a good demo I suppose, but I prefer React in a couple places: there's no separate template, style construction is done with an object and not a string (constructing that style string for HTMLBars seems error prone), and the connection between the values on the Ember object and how they will be used in the DOM is guessed only by naming convention. You could use `this.set('hotdogs', count % 255)` and reference 'hotdogs' in your template in place of 'color'.
When I start an app, I do not think from the bottom up, which is the react way. I want to start with the login page and redirects, or get the major page transitions down. I'll be interested in seeing how you approach that.
Why would one want to increase the complexity of the application by introducing "yet another new thing" on an already complex architecture.
I am just not sold on React. If someone could show a demo of why should we use React instead of, Backbone.View for example, then we can talk.
Then again, Knockout would also be pretty good at this, so I dunno. There are a lot of criteria for evaluating a framework... development speed, maintainability, simplicity, functionality. And a lot of it is better evaluated experientially rather than theoretically.
1) Performance -- React, with it's Virtual DOM, and the new idea to treat the DOM as an expensive remote rendering pipeline will give you a huge performance boost.
2) Compose-ability & Modularity -- While React only serves as the "view", there's huge potential for really decoupling your application.
3) Library, not framework -- The notion that React is simply a library is awesome. While I'm not a huge fan of the 1000nd super small libraries to make up your app, without any magic or complexity; I enjoy not being locked-in to a particular solution. Especially when new (potential) solutions are being presented regularly. I think modularity will win in the end. If React doesn't serve your needs in 6 months, then you can easily (still involves work, though) switch it out for something better. But, if you use something like Ember.js, you're tied into it's ecosystem and framework.
I don't know how suitable it would be for server-side rendering though.
You can probably skip explaining client.js (which seems to be stuff one can learn from React's docs) and just dive in to server.js and the npm packages that you wrote that this app uses.
I've been uninterested in React but really like the idea of server-side rendering for js-heavy apps. Besides Rendr, do you know of any other similar libraries/frameworks?
Thanks (http://stackoverflow.com/questions/21040538/how-to-disable-t...)
I saw a reddit article yesterday about "Finally a way of doing X that doesn't suck" despite there already being libraries to do X.
This casual dismissal and disparaging of existing work is the kind of thing that causes people to give up on stuff (WhytheLuckyStiff for example)
It also causes me to be instantly antagonistic towards said new library / feature. It raises the bar that I expect them ot reach. "Oh? You are the ONLY good way to do something? Prove it"
If you want to question the post's premise, at least point to some of these libraries that you believe are on par with react. Personally, I'm not aware of any that have nearly as compelling a model with regard to performance, composability, and minimization of mutable state. But if they exist, I'd love to know about them.
After the first person comments about how they're sick of articles that are titled like that, a real discussion starts among the other comments which is the goal.
If the author named it: "React: A great way to do this and that". It'd get 5 upvotes, 10 minutes in the primetime and die off.
Now if you want to physically separate the view logic and the corresponding markup generation, that's more debatable: they're extremely strongly coupled (and in fairly small chunks ideally) so you often can't trivially change one without the other, and thus keeping them together makes logical sense. See Pete Hunt's presentation which lumpypua linked, it tries to make that point fairly nicely.
[0] https://github.com/swannodette/om
[1] https://github.com/edn-format/edn
<div className='foo'>bar</div> -->
React.DOM.div({ className: 'foo', children: 'bar' })
You don't have to use it - it's a convenience provided for designers (and arguably developers who have realised that templating provides a false separation of concerns). Om notably (https://github.com/swannodette/om) ignores it.
> JSX transforms from an XML-like syntax into native JavaScript.
http://2013.jsconf.eu/speakers/pete-hunt-react-rethinking-be...
But consider that usually JS to control a view is inextricably linked to the underlying HTML and you need to modify both whenever making any change regardless -- since that's the case, you might as well combine all of the code and markup for the view in one place. Work to separate concerns, not programming languages.
The only reason to use .js on the serverside is that you don't know better.
However - there are lots of reasons to use javascript on the server even if we accept there are superior languages.