Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Under the hood ReactJS

bogdan-lyashenko.github.io

Post reply on HN
Print view View original

21–30 of 124 posts

Re: Show HN: Under the hood ReactJS

#21

Post by daliwali »

kaoD wrote: post #18
daliwali wrote: post #14

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

I think it's a UML activity diagram, which is in fact a flow chart.

Re: Show HN: Under the hood ReactJS

#22

Post by litzer »

daliwali wrote: post #17
jacobr wrote: post #15

Earlier quoted context omitted.

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?

Not the OP but my answer to that is because something has to be complex in a large web app.

Complexity can be avoided until the number of features reaches some threshold (I don't think there's any debate that it's impossible to avoid complexity entirely if the app is large enough). In those cases, which I think are the majority of use cases, a simple DOM utility like yours would be enough to hide complexity because there wasn't much to begin with.

But some of the websites React powers exceed that feature threshold. For example, if multiple sections of a web app want to update at once, the author could leverage React's lifecycle hooks where needed and rely on its reconciler, but if using a simpler library, might have to explicitly schedule each update in a more hacky/less efficient way.

Re: Show HN: Under the hood ReactJS

#23

Post by matthewmacleod »

daliwali wrote: post #19
rimliu wrote: post #16

Earlier quoted context omitted.

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

These are all phrases I've heard that don't translate to tangible results.

Yeah… but they do translate to tangible results. Using something like React helps to make front-end code simple, scalable, fast, and testable.

The car analogy is even worse. A modern vehicle is better than a 60s Beetle by almost every conceivable metric – performance, emissions, safety. In both of these cases, it is preposterous to assume that complexity was introduced for no reason.

Re: Show HN: Under the hood ReactJS

#24

Post by rimliu »

daliwali wrote: post #19
rimliu wrote: post #16

Earlier quoted context omitted.

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

To me they very much translate to tangible results. Not having them usually translates into mess that is very difficult to untangle.

Re: Show HN: Under the hood ReactJS

#26

Post by daliwali »

litzer wrote: post #22
daliwali wrote: post #17

Earlier quoted context omitted.

Why does the third party library need to be so complex? And why should there be complexity in the first place?

Not the OP but my answer to that is because something has to be complex in a large web app. Complexity can be avoided until the number of features reaches some threshold (I don't think there's any debate that it's impossible to avoid complexity entirely if the app is large enough). In those cases, which I think are the majority of use cases, a simple DOM utility like yours would be enough to hide complexity because t…

I think the conventional dogma that one must resort to a framework for a large web app is wrong.

Your assumption that simpler is more "hacky" or less efficient, just isn't true. One can use built-in constructs like for loops in vanilla JS to update multiple DOM nodes at once, this yields the most optimal performance. Or one could use React/Redux and setup an action and a reducer and action creator and action type constant and... you see where this is going.

Re: Show HN: Under the hood ReactJS

#28

Post by TekMol »

daliwali wrote: post #14

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

I agree that React introduces way too much complexity.

From a quick look at your approach, I have one concern:

    
     
     ...
You seem to use classnames as variable names. What if some other template has a "name" variable too? What if a stylesheet uses it?

I prefer simple placeholders. Instead of:
I would use:

     {{NAME}}

Re: Show HN: Under the hood ReactJS

#29

Post by daliwali »

matthewmacleod wrote: post #23
daliwali wrote: post #19

Earlier quoted context omitted.

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

These are all phrases I've heard that don't translate to tangible results. Yeah… but they do translate to tangible results. Using something like React helps to make front-end code simple, scalable, fast, and testable. The car analogy is even worse. A modern vehicle is better than a 60s Beetle by almost every conceivable metric – performance, emissions, safety. In both of these cases, it is preposterous to assume that…

These are marketing buzzwords that can be said about every single web framework, effectively thought-terminating cliches. Every fanboy says their preferred framework is the simplest, fastest, most scalable and most testable.

In the car analogy the improved performance of modern cars have more to do with mechanical engineering than software. And the analogy falls apart when you consider that modern web frameworks are invariably slower or roughly equal in performance to its vanilla JS counterpart, but never faster.

Re: Show HN: Under the hood ReactJS

#30

Post by daliwali »

TekMol wrote: post #28
daliwali wrote: post #14

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

I agree that React introduces way too much complexity. From a quick look at your approach, I have one concern: ... You seem to use classnames as variable names. What if some other template has a "name" variable too? What if a stylesheet uses it? I prefer simple placeholders. Instead of: I would use: {{NAME}}

Using class names was just an example, people may get the wrong impression that has anything to do with the variable name. It could have been made more explicit, but I wanted to be as terse as possible:
It was also a design goal not to introduce a templating syntax, so `{{}}` brackets are out of the question.
Post reply on HN