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

41–50 of 124 posts

Re: Show HN: Under the hood ReactJS

#41

Post by harel »

daliwali wrote: post #33
harel wrote: post #31

Earlier quoted context omitted.

Because when you build large web applications, things get complex. Now a large part of that complexity is not my problem. Its Facebook's/React's problem. And I'm fine with it. With that complexity removed I can get things done much much quicker and in a more uniform and modular way than before. Not to mention it performs better. So I'm fine with this complex black box that just sits there and does its thing. And to t…

You literally said, "complexity is not my problem". You are the problem. This is how projects end up with millions of lines of black box dependencies. This is why `node_modules` folders that are hundreds of megabytes exist. Take a look at benchmarks [0] and tell me, if any framework performs faster than vanilla JS. They probably are faster than vanilla code that you'd be able to write on your own, but that says more…

I disagree with you here. The complexity of my app is my problem. The complexity of how to render some stuff into the screen is not. I don't have the time to deal with both. As far as bloated node_modules - I agree and I will always opt for my own version instead of some trivial npm that has one function in it. But some things I don't have time to deal with. I've done work with All-In Javascript frameworks where you have to submit to the framework, and work within it fully. React essentially eliminated this for me. I don't need a framework beyond React as a view library and perhaps redux to manage state. I can then pick and choose what to bring in as 3rd party because it saves me time and what to implement myself. I've also done a good deal of Vanilla JS which has its place for smaller projects. And more often than not, those smaller projects grow beyond "Vanilla".

Doing my own thing is of course possible and in many cases is fast to get something up. But doing it correct and proper takes a lot of time and attention. When I'm trying to get a project going - time is not on my side, but I still want it done correct and proper. If someone comes in and does a complex part of my app correctly, I'd use it. Its NOT a problem.

Edit: By the way, taking a snippet of a line from what I said and quoting it without its context does not make for good discussion.

Re: Show HN: Under the hood ReactJS

#42

Post by harel »

daliwali wrote: post #40
localvoid wrote: post #37

Earlier quoted context omitted.

>They probably are faster than vanilla code that you'd be able to write on your own, but that says more about your abilities than the performance of frameworks. I won't be able to write efficient vanilla code for something even slightly more complicated than this benchmark, and I wrote one of the fastest virtual dom implementations out there, so what you expect from an average web developer?

I'm not saying, "don't use an abstraction on top of vanilla DOM code". Better performance just isn't a valid reason to use a DOM abstraction, it's a non-argument.

Performance was never the only reason. In fact its the last reason on the list. Development speed and efficiency and the modularity of it all is what sold me on React.

Re: Show HN: Under the hood ReactJS

#43

Post by [deleted] »

daliwali wrote: post #33
harel wrote: post #31

Earlier quoted context omitted.

Because when you build large web applications, things get complex. Now a large part of that complexity is not my problem. Its Facebook's/React's problem. And I'm fine with it. With that complexity removed I can get things done much much quicker and in a more uniform and modular way than before. Not to mention it performs better. So I'm fine with this complex black box that just sits there and does its thing. And to t…

You literally said, "complexity is not my problem". You are the problem. This is how projects end up with millions of lines of black box dependencies. This is why `node_modules` folders that are hundreds of megabytes exist. Take a look at benchmarks [0] and tell me, if any framework performs faster than vanilla JS. They probably are faster than vanilla code that you'd be able to write on your own, but that says more…

[deleted]

Re: Show HN: Under the hood ReactJS

#44

Post by daliwali »

notsrg wrote: post #38
daliwali wrote: post #33

Earlier quoted context omitted.

You literally said, "complexity is not my problem". You are the problem. This is how projects end up with millions of lines of black box dependencies. This is why `node_modules` folders that are hundreds of megabytes exist. Take a look at benchmarks [0] and tell me, if any framework performs faster than vanilla JS. They probably are faster than vanilla code that you'd be able to write on your own, but that says more…

I would rather the complexity live in a third party library with an extremely simple public interface than have it live in multiple 1000 LOC of vanilla JavaScript that's laid out however whoever wrote it felt that day. You couldn't pay me to do frontend without React - the developer experience is absolutely terrible.

It is a dogma that React has an "extremely simple" public interface. It's got two different flavors of "components", "lifecycle hooks", "synthetic events", "prop types", and more that I'm missing.

Why do you assume that vanilla JS code is terrible? Is it because the average developer can not be trusted to write competent code without the conventions of a framework? If one cannot write competent code without being completely dependent on frameworks, I wouldn't trust them to write code at all.

Re: Show HN: Under the hood ReactJS

#45

Post by jchw »

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…

React's complexity literally only exists for two reasons:

1. To sidestep problems with the DOM. The virtual DOM helps with performance, and fibers help with responsiveness.

2. To implement reactive components. Virtual DOM makes rebuilding sub trees of the DOM cheap, making it possible to have clean components that don't need to constantly attempt to tweak the DOM. Doing this style of programming without DOM diffing is possible, but much slower.

There are other approaches, but this one is significantly nicer to code for than DOM binding and is significantly faster than any naive approach.

Yes, you can extract the essence of React into a several kb bundle. It's been done to death. But why? React is fast, mature, has a great ecosystem, and it's nice to code for. It does nice things like seamlessly support SVG and intelligently batching changes. If you're truly making a complex app, it's worth the bump in bundle size.

The largest part of any web app is the browser. If the DOM wasn't so bloated and ridiculous, maybe we wouldn't need to spend all of our time minimizing our interactions with it. But if you try to count all of the work the browser has to do to layout and render one DOM element, suddenly React feels very tiny.

Re: Show HN: Under the hood ReactJS

#46

Post by rimliu »

daliwali wrote: post #29
matthewmacleod wrote: post #23

Earlier quoted context omitted.

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…

Car analogy was just so say that external API does not necessarily reflect complexity of the implementation.

How much of the buzzword is dependency injection you understand when forced to go through entire codebase and replace instantiation of some concrete class with something saner.

Not every user of some framework is its fanboy, some just choose based on the value they think particular framework provides. And React is not a framework.

Re: Show HN: Under the hood ReactJS

#47

Post by daliwali »

harel wrote: post #41
daliwali wrote: post #33

Earlier quoted context omitted.

You literally said, "complexity is not my problem". You are the problem. This is how projects end up with millions of lines of black box dependencies. This is why `node_modules` folders that are hundreds of megabytes exist. Take a look at benchmarks [0] and tell me, if any framework performs faster than vanilla JS. They probably are faster than vanilla code that you'd be able to write on your own, but that says more…

I disagree with you here. The complexity of my app is my problem. The complexity of how to render some stuff into the screen is not. I don't have the time to deal with both. As far as bloated node_modules - I agree and I will always opt for my own version instead of some trivial npm that has one function in it. But some things I don't have time to deal with. I've done work with All-In Javascript frameworks where you…

>The complexity of how to render some stuff into the screen is not [my problem].

But it is. You are depending on some complex third party code to do your job, how you want to punt responsibility to someone else is irrelevant. Web developers aren't owning up to the sorry state of front-end web development, because everyone says "it's not my problem", ask Facebook/Google/whatever.

Correct and proper have little meaning if at all in web development, they're usually dictated by the biggest companies and most popular bloggers. Moreover, these definitions are constantly in flux (no pun intended). Nobody cares if your web app correctly follows the proper conventions of your framework. Front-end web developers seem to focus more on navel-gazing about the "developer experience" than results.

Re: Show HN: Under the hood ReactJS

#48

Post by daliwali »

jchw wrote: post #45
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…

React's complexity literally only exists for two reasons: 1. To sidestep problems with the DOM. The virtual DOM helps with performance, and fibers help with responsiveness. 2. To implement reactive components. Virtual DOM makes rebuilding sub trees of the DOM cheap, making it possible to have clean components that don't need to constantly attempt to tweak the DOM. Doing this style of programming without DOM diffing i…

You don't need to rehash the marketing pitch of React here. It's the same old "virtual DOM fast, real DOM slow" that I've heard countless times from fanboys and repeated ad infinitum in any discussion about React.

What's missing is that you can make complex web apps without any of these things, or the abstractions used can be something completely different. The reasons you stated just sound like ex-post facto rationalizations of what they did after they built it.

Re: Show HN: Under the hood ReactJS

#49

Post by onion2k »

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…

Now that the DOM API is implemented in a standards-compliant way across most browsers...

At Facebook 'most browsers' has a very different meaning compared to other websites. When Facebook deploys code that works for 99.5% of their users that means they're failing ~10,000,000 people. Consequently they have a lot of code to handle the cases where they can't just rely on 'most browsers'. It's entirely valid that they maintain a relatively large library, and pretty awesome that they share it publicly.

Re: Show HN: Under the hood ReactJS

#50

Post by Vinnl »

daliwali wrote: post #48
jchw wrote: post #45

Earlier quoted context omitted.

React's complexity literally only exists for two reasons: 1. To sidestep problems with the DOM. The virtual DOM helps with performance, and fibers help with responsiveness. 2. To implement reactive components. Virtual DOM makes rebuilding sub trees of the DOM cheap, making it possible to have clean components that don't need to constantly attempt to tweak the DOM. Doing this style of programming without DOM diffing i…

You don't need to rehash the marketing pitch of React here. It's the same old "virtual DOM fast, real DOM slow" that I've heard countless times from fanboys and repeated ad infinitum in any discussion about React. What's missing is that you can make complex web apps without any of these things, or the abstractions used can be something completely different. The reasons you stated just sound like ex-post facto rationa…

No, the main point was that it's

> significantly nicer to code for than DOM binding

There are other ways to code this nicely, but _those_ are slower than virtual DOM. Real DOM _can_ indeed easily be faster, but that's not nearly as nice to program for.

Post reply on HN