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.
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.
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.
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.
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.
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.)
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...
XmlHttpRequest is an awesome innovation from the point of view of the software development community as a whole.
But from a Microsoft shareholder's point of view it was a disaster. XmlHttpRequest and ContentEditableDiv (known back then as DesignMode) ushered in Web 2.0 and Web 2.0 ended Microsoft's dominance of the software industry by making Windows irrelevant.
> But from a Microsoft shareholder's point of view it was a disaster.
The disaster is not in inventing the next technology, because if you don't someone else will do so anyway. The failure is failing to exploit what you invented before anyone else does.
But that's inherently difficult to do. Large organizations are usually oriented towards rewarding and incentivizing what makes them money today.
It's easier to be a real start-up than an internal startup at a large company, because it's hard to duplicate real-world market incentives internally.
> What Web2.0 did is that it removed the need of certain type of desktop software.
The commonly held belief at the time was that Microsoft's dominance rested in large part on that desktop software. Think how hard it would be today if you wanted to start a new mobile OS (let's call it "windows phone") years after entire software ecosystems have been established for iPhone and Android.
It's safe to say that Microsoft is not the shining star they once were. If we were to pick a single moment in history that lead to their undoing, I think this would be it.
> BTW if Microsoft didn't invent XmlHttpRequest, somebody else had done it.
"Somebody else" didn't have the market share IE did. Something that was incompatible with IE at the time was a non-starter. What's remarkable about this story is that when Microsoft saw the browser coming in the Netscape years, their entire strategy was to head that shit off by ensuring that their own browser become market dominant so that they could keep the web in a place that wouldn't hurt MS.
After all that effort, the anti-trust suit, etc, etc... and they'd gotten themselves in the place where they controlled the future of the web, it was some random developer at Microsoft itself that invented the very thing which was their undoing.
> If we were to pick a single moment in history that lead to their undoing
I always find these sorts of comments interesting.
Microsoft is a very different business than say other failures who you could point to a single event (Kodak, Word Perfect, Lotus Software, Myspace)
Remember, Microsoft have over $100 BILLION in cash[0].
You could perhaps cherry pick certain parts of the business. But I remember the stories of how they made more money from Android than Windows Phone[1].
Microsoft has a long, LONG way to fall before I would say they have failed.
> If we were to pick a single moment in history that lead to their undoing, I think this would be it.
That was a pivotal moment but I would pick 2005/2006 when they decided to stop investing in Windows Mobile. The same period that Apple was secretly inventing the iPhone.
Recall that at the time Java was set to make Windows irrelevant. Microsoft had a massive success, via XML, in derailing this future.
To explain a little, the Sun position was "use Java to write everything; then it all talks together nicely". But folks realised they could use XML to tie different pieces together and relegated Java to the server. Yes, there were other other ways to interop, eg CORBA, but they were ugly, expensive and heavyweight.
I get a bit paranoid that some high schooler who will be the world's next Bill Gates is reading your post and think, "hmm, I've got to keep a lookout for any of my developers building XmlHttpRequest-like technology that paves the way for my future monopoly to get busted up prematurely!"
Imagine if someone in Microsoft had a clue and was able to constrain the browser to being a simple scripted document viewer? I'm convinced suppressing client-side web application development would have lent the Windows OS a few more years of platform and developer mindshare dominance!
Imagine if someone in Microsoft had a clue and was able to constrain the browser to being a simple scripted document viewer? I'm convinced suppressing client-side web application development would have lent the Windows OS a few more years of platform and developer mindshare dominance!
...and the web might have turned out to be a bit less user-hostile and inefficiently resource-consuming than it currently is today, which might not be so bad after all.
Given national security interests, we need new laws: 1. IOT devices should not ship with default passwords. 2. Internet infrastructure companies should not be allowed to get "too big to fail".
As far as (2) goes, they actually need to be too big too fail. Otherwise, it's plainly impossible for internet infrastructure companies to be able to financially weather ddos attacks like this. These sorts of attacks are very expensive to mitigate, and part of the way we can do that is to centralize under services like AWS and collectively pay for ddos protection (short of the government doing so and separating our network from those of major malicious foreign actors').
