Live data from Hacker News

React: Finally, a great server/client web stack

eflorenzano.com

1–10 of 134 posts

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

#3
post #2

I don't want to write a bunch of markup next to my javascript.

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.

[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

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

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

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

#6
post #2

I don't want to write a bunch of markup next to my javascript.

JSX isn't markup - it's XML which translates to Reacts internal representation which looks something like:

bar -->

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.

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

#7
post #4

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.

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.

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

#8
post #2

I don't want to write a bunch of markup next to my javascript.

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.

http://2013.jsconf.eu/speakers/pete-hunt-react-rethinking-be...

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

#9
post #4

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.

[0] https://github.com/facebook/react-page/

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

#10
post #2

I don't want to write a bunch of markup next to my javascript.

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.

Post reply on HN