Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

React: Finally, a great server/client web stack

eflorenzano.com

Post reply on HN
Print view View original

61–70 of 134 posts

Re: React: Finally, a great server/client web stack

#61

Post by drfloob »

ForHackernews wrote: post #26

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. P…

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.

Re: React: Finally, a great server/client web stack

#62

Post by collypops »

spullara wrote: post #42
hrvbr wrote: post #37

Earlier quoted context omitted.

Yes, Instagram is super slow because of all its useless Javascript. And it took Twitter years of optimization to make it about as fast as static HTML.

Actually, Twitter gave up on it every performing and everything is rendered server-side.

Actually, it gave up on performing _everything_ client-side, and now renders the first page server-side, and then handles subsequent rendering client-side.

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.

Re: React: Finally, a great server/client web stack

#63

Post by Iftheshoefits »

Sssnake wrote: post #49
ForHackernews wrote: post #26

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. P…

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

As long as enterprise continues to shift to a no-install web application based IT infrastructure, fad driven client based "web dev" will continue to increase in frequency and prominence. If (when?) people realize that the browser actually can't do everything this might change, but I wouldn't hold my breath. It's too easy to save a buck now by minimizing application development and support costs (browser-based web app vs. native) and let the poor idiot who takes over management five years from now worry about the fallout.

Re: React: Finally, a great server/client web stack

#64

Post by auvrw »

ForHackernews wrote: post #26

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. P…

did some searching... turns out you can get medium content as rss feeds as well.

Re: React: Finally, a great server/client web stack

#65

Post by RivieraKid »

ForHackernews wrote: post #26

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. P…

Sometimes you need interactivity. Yes, it comes at a price (small imo) but it's pretty useful.

Re: React: Finally, a great server/client web stack

#66

Post by avolcano »

ssorallen wrote: post #22
tomphoolery wrote: post #18

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

The big difference is that Handlebars always produces strings that your browser has to parse as HTML. Handlebars also doesn't know how to mutate between states, meaning if you add a class 10 levels deep in the template the best you can do is re-render the entire thing. 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…

HTMLBars is rendering to DOM instead of to string, to enable React-level performance: http://jsfiddle.net/Ut2X6/10/

Re: React: Finally, a great server/client web stack

#67

Post by taivare »

jbeja wrote: post #53
hbbio wrote: post #33

Earlier quoted context omitted.

It's not exactly novel. Opa ( http://opalang.org ) has been doing this for a few years...

Opa should be more popular.

Also, fruitmachine (Github)- Financial Times - Graphics Lab. They say it handles multiple pages better then React. They also claim to have had the React concept first.

Re: React: Finally, a great server/client web stack

#68

Post by ssorallen »

avolcano wrote: post #66
ssorallen wrote: post #22

Earlier quoted context omitted.

The big difference is that Handlebars always produces strings that your browser has to parse as HTML. Handlebars also doesn't know how to mutate between states, meaning if you add a class 10 levels deep in the template the best you can do is re-render the entire thing. 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…

HTMLBars is rendering to DOM instead of to string, to enable React-level performance: http://jsfiddle.net/Ut2X6/10/

Thanks for the demo link; I hadn't heard of HTMLBars.

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

Re: React: Finally, a great server/client web stack

#69

Post by swah »

matchu wrote: post #41
ForHackernews wrote: post #26

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. P…

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…

My understanding is that since React has a virtual DOM, it can just render everything on the server with Node.JS, instead of evaluating it in a browser.
Post reply on HN