7 ms·
If you use Typescript you can get most of the benefits of React from this little library: https://github.com/wisercoder/uibuilder https://github.com/wisercoder/
by netcommentator 10y ago
If you use Typescript you can get most of the benefits of React from this little library:
https://github.com/wisercoder/uibuilder 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.
- Cafey 10y agoFor 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.
- netcommentator 10y agoYou 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.
- untog 10y agoRight, 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.
- netcommentator 10y agoYou 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.
- untog 10y agoSo, 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.
- netcommentator 10y agoI 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?
- deleted 10y ago[deleted]
- tengbretson 10y agoI 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.
- farthenfurter 10y agoRight - 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.
- tengbretson 10y agoThat'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.
- farthenfurter 10y agoMore 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.
- tengbretson 10y agoI lied. More like 5 lines. http://codepen.io/anon/pen/MbjLMB http://codepen.io/anon/pen/MbjLMB
- magic_quotes 10y agoThe 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.
- ergo14 10y agoYou can do this with Polymer, Vue or Angular too (and many others)
- wwalser 10y agoIt'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.
- interlocutor 10y agoIt 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.
- lostPixels 10y agoYes but you didn't dispute his major point of server-side rendering.
- interlocutor 10y agoYou can uses this to do server-side rendering: https://github.com/pimterry/server-components https://github.com/pimterry/server-components
- wwalser 10y agoI 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.
- netcommentator 10y agoIt 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-and-the-psychology-of-the-birther-myth/the-echo-chamber-effect http://www.nytimes.com/roomfordebate/2011/04/21/barack-obama...