Hacker News Reader

Comment by netcommentator | Hacker News Reader

If you use Typescript you can get most of the benefits of React from this little library: https://github.com/wisercoder/uibuilder

It doesn't support fine-grained screen update but you get support for Web Components (Polymer) which React doesn't support.

Facebook is being arrogant by not supporting the Web Components W3 standard.

View on HN

For me the best asset of React is not having to manipulate the DOM directly with jQuery, which in my experience leads to code that injects DOM elements from everywhere making it very difficult to maintain.

This is certainly not a replacement.

You can do this with Polymer, Vue or Angular too (and many others)

You can divide your page into multiple components, then to update the screen replace the components that contain stale data. You do not have to deal with elements--you only have to deal with components.

Regardless of which library you use there is nothing preventing you from injecting DOM elements from everywhere. Only discipline can prevent that.

I guess I fail to see the value of this. If you don't want the component lifecycle, event system, or DOM diffing that React gives you, you might as well just write your own declarative wrapper around `document.createElement(...)` and be done with it. You can achieve this for templating alone in < 10 lines of code, and if you want to add some event delegating on top of it you can include that for another ~30.

Right - DOM diffing is the key selling point of React. But the fine-grained screen updates possible via DOM diffing is not super important for most applications.

Event system is already supported by DOM. React doesn't add anything there. Component lifecycle is also not compelling.

That's kind of what I'm saying. If you don't value those things, why introduce a library at all? What you're describing can be implemented in < 10 lines.

More like 200 lines, so it is useful to have a library. BTW it is rare to hear component lifecycle and event system described as key selling points of React. Most people would say DOM diffing and perf are the key selling points.

The point of React is to make it practical to structure view logic as a function (projection) of the application state. Virtual DOM is just an implementation detail.

By the way, for the most minimal diffing implementation see https://github.com/patrick-steele-idem/morphdom.

I lied. More like 5 lines. http://codepen.io/anon/pen/MbjLMB

Right, but the point is that React is disciplined for you. You never do any manual HTML manipulation so you don't have to worry about injection issues.

You don't do manual HTML manipulation with this lib either. You can just see your page as being composed of components and replace components in order to update screen.

So, you're still controlling what is updated and when, with the same potential for making mistakes that you'd get in direct DOM manipulation.

React doesn't require you to ever manually replace a component - that's why the two are not comparable.

I am not familiar with the type of mistakes you are talking about. I have used both React and UIBuilder and find them to be comparable. Would you be willing to share an example of the type of mistake that developers frequently make?

It's not that React doesn't "support" web components. React is a competitive alternative to web components. Custom HTML elements (components) done better, done now and without aggressive browser shimming. My understanding is that a significant driver for an alternative to WC was Facebook's view that no server-side rendering made WC a complete non-starter within the company.

Competition is good for the web.

It is actually not "done better". Web Components have shadow DOM, which permits scoped CSS. React Components are brittle because styles and scripts are global. Also, some people think you can only pass strings as attributes to Web Components. This is not true; you can pass objects just like in React. Also, Web Components are declarative not imperative, again like React.

I didn't mean "done better" as an absolutist statement, but I can understand why it would be read that way. I meant it more as a brand statement, obviously the React team, contributors and users are likely to believe it's better. I get that some will come down on the other side of that coin.

I stand by the statement that the competition between these two projects is good for the web which I think is the important part of my response to the parent comment. I'm glad there are people working with and on web components.

What is the point of open standards if everyone competes against the open standard as opposed to supporting the standard?

Facebook isn't "everyone". As I noted in the comment to which you're replying, there are people building and using Web Components.

Nothing about Facebook creating React prevents browser vendors from implementing Web Components natively. React uses other open standards (ECMA & HTML) which have existed for a decade previous to Web Components.

Web Components contains good ideas. React contains good ideas. You're arguing against people who are helping. Stop doing that.

Somehow I think the reaction would be different if Microsoft had done this, i.e., make proprietary competing technology instead of supporting an open standard. (Yes, React is proprietary--look into the patent rider issue.)

Yes but you didn't dispute his major point of server-side rendering.

You can uses this to do server-side rendering: https://github.com/pimterry/server-components

It is unfortunate that this post got so many downvotes. Apparently people only want to hear from people who agree with them. This is known as the echo chamber effect, and HN is becoming one: http://www.nytimes.com/roomfordebate/2011/04/21/barack-obama...

Reply on news.ycombinator.com