This is super cool, thanks, I'm eagerly waiting for comparison with fiber.
Show HN: Under the hood ReactJS
11–20 of 124 posts
Re: Show HN: Under the hood ReactJS
#12Earlier quoted context omitted.
For even more fun, compare with inferno
FWIW a React lead said Inferno is how they would've designed React if they had to do it from scratch, and it's author joined Facebook to push React efforts forward.
"Inferno 1.0 is really well written. It's how I would've rewritten React. I'd recommend reading its source to learn." - reading the source is much more effective than reading an article written by someone who read the source code.
Re: Show HN: Under the hood ReactJS
#13Earlier quoted context omitted.
FWIW a React lead said Inferno is how they would've designed React if they had to do it from scratch, and it's author joined Facebook to push React efforts forward.
"Inferno 1.0 is really well written. It's how I would've rewritten React. I'd recommend reading its source to learn." - reading the source is much more effective than reading an article written by someone who read the source code.
What are you doing on HN when you could be off reading source code?
Re: Show HN: Under the hood ReactJS
#14There was a previous discussion on how do you know when someone is addicted to over-engineering, and looking at this giant UML diagram, I think this might be the case.
The amount of complexity I'm willing to accept is proportional to the the difficulty of the problem. In this case it's manipulating web pages, which shouldn't be too hard. This isn't a knock on React in particular, but it seems all the major vendors are competing on complexity. React has "fibers", Ember has a "virtual machine", Angular has their own overblown architecture (I don't know anything about it, and don't want to).
Now that the DOM API is implemented in a standards-compliant way across most browsers, it should be the perfect time to use it. I don't like the current mess that is front-end web development, and more of the status quo isn't going to get any simpler, quite the opposite.
Shameless plug for my own DOM utility: http://simulacra.js.org
Re: Show HN: Under the hood ReactJS
#15There was a previous discussion on how do you know when someone is addicted to over-engineering, and looking at this giant UML diagram, I think this might be the case. The amount of complexity I'm willing to accept is proportional to the the difficulty of the problem. In this case it's manipulating web pages, which shouldn't be too hard. This isn't a knock on React in particular, but it seems all the major vendors ar…
The place where complexity should be is exactly in third party library with a simple public API, avoiding as much complexity and optimizations as possible in your own application code.
Re: Show HN: Under the hood ReactJS
#16There was a previous discussion on how do you know when someone is addicted to over-engineering, and looking at this giant UML diagram, I think this might be the case. The amount of complexity I'm willing to accept is proportional to the the difficulty of the problem. In this case it's manipulating web pages, which shouldn't be too hard. This isn't a knock on React in particular, but it seems all the major vendors ar…
Well, that's like judging a car to be difficult to drive by looking at the listings of all the embedded software in its cpu's.
These are details of internal implementation. The public API which you actually use is very very simple.
Calling React "DOM utility" does not sound fair. While one of the major problems it solves—slow DOM operations, I'd say that unidirectional data flow is even more important.
Re: Show HN: Under the hood ReactJS
#17There was a previous discussion on how do you know when someone is addicted to over-engineering, and looking at this giant UML diagram, I think this might be the case. The amount of complexity I'm willing to accept is proportional to the the difficulty of the problem. In this case it's manipulating web pages, which shouldn't be too hard. This isn't a knock on React in particular, but it seems all the major vendors ar…
The place where complexity should be is exactly in third party library with a simple public API, avoiding as much complexity and optimizations as possible in your own application code.
Why does the third party library need to be so complex? And why should there be complexity in the first place?
Re: Show HN: Under the hood ReactJS
#18There was a previous discussion on how do you know when someone is addicted to over-engineering, and looking at this giant UML diagram, I think this might be the case. The amount of complexity I'm willing to accept is proportional to the the difficulty of the problem. In this case it's manipulating web pages, which shouldn't be too hard. This isn't a knock on React in particular, but it seems all the major vendors ar…
> looking at this giant UML diagram
It's not an UML diagram. Looks more like an ad-hoc flow chart (unless I forgot a specific type of UML diagram that looks like this).
Re: Show HN: Under the hood ReactJS
#19There was a previous discussion on how do you know when someone is addicted to over-engineering, and looking at this giant UML diagram, I think this might be the case. The amount of complexity I'm willing to accept is proportional to the the difficulty of the problem. In this case it's manipulating web pages, which shouldn't be too hard. This isn't a knock on React in particular, but it seems all the major vendors ar…
Well, that's like judging a car to be difficult to drive by looking at the listings of all the embedded software in its cpu's. These are details of internal implementation. The public API which you actually use is very very simple. Calling React "DOM utility" does not sound fair. While one of the major problems it solves—slow DOM operations, I'd say that unidirectional data flow is even more important.
Your analogy isn't apt, a better analogy would be judging a car to be difficult to maintain by looking at the listings of all the embedded software. I know a guy who restored a 1960's VW Beetle to working condition with minimal expertise, the same couldn't be done for modern cars without a full machine shop that specialized in that make.
Fancy selling points like "unidirectional data flow" don't actually mean anything. Each fanboy has their own variant of this, like "transclusions", "immutables", "dependency injection", etc. These are all phrases I've heard that don't translate to tangible results.
Re: Show HN: Under the hood ReactJS
#20Earlier quoted context omitted.
"Inferno 1.0 is really well written. It's how I would've rewritten React. I'd recommend reading its source to learn." - reading the source is much more effective than reading an article written by someone who read the source code.
What are you doing on HN when you could be off reading source code?
I don't think that your question makes any sense. I read both of HN and the source code.