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

111–120 of 134 posts

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

#111

Post by tel »

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

While I like the idea man do I her hate that term. You can't just be isomorphic: you must be isomorphic to or with respect to aomething.

It's like McDonald's named their new hamburger the RESTful Patty.

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

#112

Post by jbeja »

taivare wrote: post #67
jbeja wrote: post #53

Earlier quoted context omitted.

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.

I never hear of it, i will give it a look. Thanks

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

#113

Post by sehr »

danabramov wrote: post #105
Iftheshoefits wrote: post #78

Earlier quoted context omitted.

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.

What do you propose, exactly?

It's always easier to criticize than rectify.

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

#114

Post by swah »

peterhunt wrote: post #104
lennel wrote: post #90

Earlier quoted context omitted.

I started with this line: >initial rendering should definitely be on the server 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…

PyExecJS is slow :) We are actively working on more static analysis tools for React: it's certainly one of our major priorities.

I suppose Rhino can also be used? :)

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

#115

Post by lennel »

swah wrote: post #114
peterhunt wrote: post #104

Earlier quoted context omitted.

PyExecJS is slow :) We are actively working on more static analysis tools for React: it's certainly one of our major priorities.

I suppose Rhino can also be used? :)

we use rhino for some types of testing. brutally slow.

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

#117

Post by Iftheshoefits »

antihero wrote: post #94
Iftheshoefits wrote: post #78

Earlier quoted context omitted.

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.

What, for instance? Your comments seem heavy on condemnation but light on substance. Sure there are certain donation specific tools such as Photoshop or 3dsmax or ableton etc that wouldn't work in the browser, but for your day to day business 99% application, the user generally does not need to do anything that the browser cannot. The fact is, the web world is evolving at an extremely fast rate, and leaving the nativ…

I don't argue that the browser cannot be made to do something. I merely point out that making it do "everything" will only end up in disaster for browser creators and maintainers, and for app developers alike.

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.

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

#118

Post by asdasf »

spion wrote: post #100
Sssnake wrote: post #49

Earlier quoted context omitted.

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

Building an application by rendering static webpages is just a horrible cludge. How did we even get here? How are we still even considering that the godawful turd that is string concatenation of DOM descriptors polished by a layer of templating languages is actually a decent way of writing applications? Do you seriously believe this? The virtual DOM is probably the biggest elephant in the room. It begs the question:…

If you have to pose a really terrible strawman to argue for client side templates, you are basically conceding the argument. It is even worse given that moving it to the client doesn't change anything you complained about.

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

#119

Post by peterhunt »

lennel wrote: post #106
peterhunt wrote: post #104

Earlier quoted context omitted.

PyExecJS is slow :) We are actively working on more static analysis tools for React: it's certainly one of our major priorities.

i assume you work on the team at FB. Are you considering writing jsx compilers for platforms like the jvm?

Our approach is going to make js interop performant with our stack (which is not jvm). We don't have a concrete plan at this time. You would need more than jsx to make this work through (jsx is just sugar)

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

#120

Post by trekforever »

sahat wrote: post #80

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 ta…

I think the biggest reason to use React is how it handles the DOM. In most framework views, DOM access is slow and can be a bottleneck. React addresses that problem by using a virtual DOM. In order to make a change to the real DOM, React computes a diff between the newly virtual DOM and the previously computed virtual DOM, and then it applies the diff to the real DOM. The triggering to the virtual DOM computation is done explicitly, hence React has a lot better DOM rendering performances. Everything you can do in React, you can do with other frameworks (Angular's directives and isolated scopes for example), but React is a lot faster and easier to learn, and definitely worth looking into.
Post reply on HN