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

71–80 of 134 posts

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

#71

Post by peterhunt »

ssorallen wrote: post #68
avolcano wrote: post #66

Earlier quoted context omitted.

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…

There is a very nuanced set of performance (mem and cpu) and usability tradeoffs you make when adopting a dirty checking vs change tracking system. I'm working on coming up with a reasonable talk about it.

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

#72

Post by WickyNilliams »

tel wrote: post #70

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? [1] "a tiny and isomorphic URL router for JavaScript http://github.com/flatiron/director"

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

[0] http://blog.nodejitsu.com/scaling-isomorphic-javascript-code...

[1] http://nerds.airbnb.com/isomorphic-javascript-future-web-app...

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

#73

Post by rurounijones »

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"

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

#74

Post by tomhallett »

lucaswoj wrote: post #35
[deleted] wrote: post #28

[deleted]

There aren't any library features for TDD per se but standard JavaScript testing practices work on React objects (barring some weirdness around autobound methods)

I wrote a jasmine helper utility to tdd reactjs components. And I handle spying on functions which are autobound by react!

I just launched it last week, so I will be working on some screencasts to explain using it in further detail.

https://github.com/tommyh/jasmine-react

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

#75

Post by [deleted] »

swah wrote: post #69
matchu wrote: post #41

Earlier quoted context omitted.

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.

[deleted]

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

#76

Post by andrewflnr »

sgdesign wrote: post #46
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…

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?

That's actually a perfect use-case for this render-serverside-update-clientside paradigm.

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

#77

Post by okayzedd »

WickyNilliams wrote: post #72
tel wrote: post #70

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? [1] "a tiny and isomorphic URL router for JavaScript http://github.com/flatiron/director"

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 [0] http://blog.nodejitsu.com/scaling-isomorphic-javascript-code... [1] http://nerds.airbnb.com/isomorphic-javascript-future-web-app...

http://superfluous.io/glossary/read/007_isomorphic_javascrip...

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

#78

Post by Iftheshoefits »

drfloob wrote: post #61
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.

Browsers aren't general purpose applications. They can't fill every application role on the computer. The more "web dev" tries to push them in that direction, the slower, more difficult to develop and maintain, and generally poor they will be, and then the "dynamic web applications" that run on them will suffer.

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

#79

Post by danenania »

rurounijones wrote: post #73

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…

You are making the same sort of evidence-less dismissal that you accuse the OP of (whereas the OP actually explains the reasoning behind his assertion).

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.

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

#80

Post by sahat »

I would be interested to know what exactly React solves when we already have so many options - Ember, Angular, Backbone to do the same thing.

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.

Post reply on HN