Am I the only one that kind of thinks most websites should just be static pages? Like, I get pretty irritated when I go to read a blog post on Medium or wherever and it loads a header and a blank page, and then loads a bunch of javascript (mostly tracking and analytics frameworks), and finally goes out and gets the actual content. And then if I scroll down, it has to load some more garbage from Disqus or something.
PLEASE JUST GIVE ME A STATIC PAGE WITH YOUR CONTENT.
I really do not care if the comments don't refresh live.
So, you read an article about how easy server-side rendering is with React, and your first impulse is to rant about client-side rendering? Did you not read the post or did you just feel an overwhelming urge to posture?
I think the author largely agrees with your beefs, since he's proposing this as a client-side and server-side rendering solution.
> 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.
I get your gripe, but there's a good use case for this stuff in building dynamic web applications. Just because a technology is misused doesn't mean the technology is to blame.
For content sites, you are correct. But what about an in browser app, like Trello. Obviously in those cases javascript significantly improves the experience. So its just a case by case scenario. But I agree with the general point you are trying to make, and I work as a front-end dev who builds a lot of js heavy web pages/apps for a living.
To a large degree I agree with your sentiment. I have never had to manage a site with thousands of pages but I would assume even then any template changes would not be that hard to render and then upload to a CDN.
Not all use cases are equal. Static pages might work great for static content, but what about something like GitHub? Wouldn't it be nice to see the issues list refresh live when somebody else closes one?
Kids these days, not around in the 90s when all web pages were static and every link refreshed the entire page.
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.
Completely agree with your point. It doesn't mean that we don't want/need dynamic user interface, of course. But the Web was designed to be static mostly. That's why the best experience we can enjoy is from the static web sites. Let's just recall what HTTP term means: Hypertext Transfer Protocol!
>Am I the only one that kind of thinks most websites should just be static pages?
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.
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...
Wouldn't this make it even more difficult for search engines to index your 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 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.
> Wouldn't this make it even more difficult for search engines to index your pages?
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.
Various companies (in one famous case, Twitter) have found that server rendering beats client rendering for initial rendering speed. React is designed so that if you care about server rendering, you can have the best of both worlds -- using Node you can render a component to HTML on the server, then pick it up the prepopulated DOM in client-side JS once your page loads. Since the server sends down plain HTML, search engines are happy too.
Can someone explain to me what "isomorphic" means in the tagline for the linked Director library[1]? I have no idea how isomorphism is supposed to play into all of this?
It means that it can be used on client and server. Its a term coined by (I believe) the nodejitsu people in this article [0]. Airbnb also used the term to describe their rendr library [1] which aims to allow exactly that: rendering on both client and server
> You can choose to use this, but after getting over my initial distaste for it ("Ack! Who got markup in my code!"), I could never go back to not using it.
Or you could just use HTMLbars/Handlebars. Seems like "JSX" is just a more complicated version of a Mustache-esque logic-less template.
I come from an Ember.js background and its router / nested layout management is the best I have used. I like react, and have been diving into OM as well in my free time, but I'm not sure of the best way to approach routing / page transitions.
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.
The lack of understanding and amount of hatred against web applications (different from web pages) is both sickening and rejuvenating. It is sad because the article is fairly clear, it describes the future of most computing (since most "human" computing will happen on the web) and it really shouldn't be hard to understand. But I am glad that most of the top commenters here instead focus on hating "webdevs". It means these people will stay on the desktop and won't create clones of desktop applications in the browser (see google docs for a missed opportunity of a better office system). History will show which way things shifted, no need to flame about it here now.
I am learning how to make desktop apps with Reactjs + Backbone + PouchDB and Brackets-Shell just for fun and learning purposes, so far it has been a very exciting experience.
Can anybody explain to me how to use react.js without their "guard" feature. I need my app to throw the error natively and not wrapped by the framework.
God I am sick of the passive-agressive "Finally, we have something GOOD! for X" titles that disparage everything that already exists for X.
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"
It's cool, you don't have to use JSX, you can just use the React.DOM functions. Or build a backend for whatever your preferred template system is, as long as the backend ends up creating nodes of React.DOM objects. Or you go with Om[0] and use EDN[1], Enlive-style[2] or hiccup-style[3] tempting.
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.
Separation of concerns is a good goal, and your reaction is popular with people first seeing React (including me, several months ago!).
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.
Yes, yes you do. Pete Hunt's talk introducing React makes a really persuasive argument that in large frontend applications, having something markup-esque along with your JS is the best way to reduce component coupling and increase cohesion.
I still don't get it that you would like to write in an inferior language such as js on the server side. Cm'on its broken by design. There are a lot of better alternatives.
The only reason to use .js on the serverside is that you don't know better.
[+] [-] ForHackernews|12 years ago|reply
PLEASE JUST GIVE ME A STATIC PAGE WITH YOUR CONTENT.
I really do not care if the comments don't refresh live.
[+] [-] chc|12 years ago|reply
[+] [-] matchu|12 years ago|reply
> 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.
[+] [-] drfloob|12 years ago|reply
[+] [-] paultannenbaum|12 years ago|reply
[+] [-] antihero|12 years ago|reply
[+] [-] hrvbr|12 years ago|reply
[+] [-] noptic|12 years ago|reply
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.
[+] [-] infecto|12 years ago|reply
[+] [-] koshak|12 years ago|reply
[+] [-] sgdesign|12 years ago|reply
[+] [-] SkyMarshal|12 years ago|reply
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...
[+] [-] lightblade|12 years ago|reply
I know this may sounds sarcastic, but I am totally serious.
[+] [-] nicklovescode|12 years ago|reply
[+] [-] woah|12 years ago|reply
[+] [-] swah|12 years ago|reply
[+] [-] eliah-lakhin|12 years ago|reply
[+] [-] RivieraKid|12 years ago|reply
[+] [-] weland|12 years ago|reply
[+] [-] tripzilch|12 years ago|reply
[+] [-] dllthomas|12 years ago|reply
[+] [-] auvrw|12 years ago|reply
[+] [-] Sssnake|12 years ago|reply
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.
[+] [-] rubiquity|12 years ago|reply
[+] [-] jashkenas|12 years ago|reply
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...
[+] [-] ssorallen|12 years ago|reply
[+] [-] CGamesPlay|12 years ago|reply
[+] [-] jbeja|12 years ago|reply
[+] [-] thrush|12 years ago|reply
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.
[+] [-] masklinn|12 years ago|reply
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.
[0] https://github.com/facebook/react-page/
[+] [-] spicyj|12 years ago|reply
[+] [-] tel|12 years ago|reply
[1] "a tiny and isomorphic URL router for JavaScript http://github.com/flatiron/director"
[+] [-] WickyNilliams|12 years ago|reply
[0] http://blog.nodejitsu.com/scaling-isomorphic-javascript-code...
[1] http://nerds.airbnb.com/isomorphic-javascript-future-web-app...
[+] [-] tomphoolery|12 years ago|reply
Or you could just use HTMLbars/Handlebars. Seems like "JSX" is just a more complicated version of a Mustache-esque logic-less template.
[+] [-] lsdafjklsd|12 years ago|reply
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.
[+] [-] lumpypua|12 years ago|reply
[+] [-] sahat|12 years ago|reply
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.
[+] [-] xixixao|12 years ago|reply
[+] [-] jamesbritt|12 years ago|reply
[+] [-] kitd|12 years ago|reply
I don't know how suitable it would be for server-side rendering though.
[+] [-] jbeja|12 years ago|reply
[+] [-] hamxiaoz|12 years ago|reply
[+] [-] ttty|12 years ago|reply
Thanks (http://stackoverflow.com/questions/21040538/how-to-disable-t...)
[+] [-] unknown|12 years ago|reply
[deleted]
[+] [-] rurounijones|12 years ago|reply
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"
[+] [-] ocfx|12 years ago|reply
[+] [-] masklinn|12 years ago|reply
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
[2] https://github.com/ckirkendall/kioo
[3] https://github.com/r0man/sablono
[+] [-] spicyj|12 years ago|reply
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.
[+] [-] lumpypua|12 years ago|reply
http://2013.jsconf.eu/speakers/pete-hunt-react-rethinking-be...
[+] [-] TeeWEE|12 years ago|reply
The only reason to use .js on the serverside is that you don't know better.