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

51–60 of 124 posts

Re: Show HN: Under the hood ReactJS

#51

Post by Ralfp »

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 am sorry but this sounds like Dunning-Kruger effect on your part. You have created library that you think the problem, but which seems to have limited adoption in the wild. What experience in the field you have? Have you wondered how much you don't know about problems and scenarios that view layer has to handle?

I've been in same situation once with my OS project. I've did something small that I've been certain does what all those other heavier solutions do. But when users came I've learned that there's unimaginable number of edge cases and scenarios that are common enough to require annoying amount of work.

React.js is not "DOM utility". Its battletested view library running one of busiest social sites in the world. It's highly performant, capable of handling thousands of components at single time, and handles countless edge cases, like maintaining input state while user is typing in it and its moved around DOM, normalizing events between browsers, maintaining scroll between large redraws or jumping user to components #fragment.

Ember.js and Angular are complete app frameworks that implement view, layers, services, data, communications testing, tooling and more. Those are solid options for people writing dashboard applications (think intercom or Podio), even if they are losing ground in public-facing sites to more elastic stacks like React or Vue.

Re: Show HN: Under the hood ReactJS

#52

Post by harel »

daliwali wrote: post #47
harel wrote: post #41

Earlier quoted context omitted.

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…

But you're missing a context here. My context. I run two companies and contract on top. I also have a life. If any Big Company (tm) wants to give me a good solid presentation layer blackbox I'll take it and say thank you. I could develop my own presentation layer/frameword du jour/library/toolkit/whatever. But WHY would I do that when its already done. And those who did it do it full time as their day job, paid by said Big Company (tm). So i'll ride that train and use their blackbox and focus my energies where they are needed - in domain specific business logic that actually generates revenue.

I'm having fun doing it but i'm not doing it for fun.

Re: Show HN: Under the hood ReactJS

#53

Post by jasode »

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…

>that I've heard countless times from fanboys

If you're unaware, "fanboys" is a grenade to incite juvenile flamewars instead of collegial discussion.

>What's missing is that you can make complex web apps without any of these things,

To attempt better instructive discussion instead of arguing from vague and generic platitudes about "needless complexity", can you explain how your simulacra.js (~12kb) is better than reactjs (~130kb)?

For example, does Simulacra have the same features that React? If so, how did you eliminate ~100kb of Javascript to accomplish it, or conversely, what redundant or incompetent code takes up additional ~100kb of wasted bytes in React?

If Simulacra accomplishes its smaller 12kb footprint by having less features, which features in React do developers no longer need because of "modern browsers have standards-compliant DOMs".

In other words, some concrete analysis would be a more productive discussion.

Re: Show HN: Under the hood ReactJS

#55

Post by jchw »

Vinnl wrote: post #50
daliwali wrote: post #48

Earlier quoted context omitted.

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.

Simply saying "No" after a point and not rebutting it is not a good argument.

A lot of people like to point out that the "real DOM" can be just as fast, but far fewer people have any good examples of this being done.

Yeah, for making a button that signs you up to a mailing list or a simple SPA or something like that, you can just use the DOM. But if you have a complex app with a huge amount of data flow and many components, React (and Preact and etc.) absolutely will beat the naive answer because it will get rid of needless DOM updates. And it will do that without you having to do caching everywhere, because it's all done in one place at the lowest level before hitting the page. I'd love to see the horrible abomination of hand DOM updates that can magically beat a large React app.

edit: Just noticed this wasn't a reply to me, but I think the points I raise here are still fairly valid, if I'm understanding your reply correctly. Sorry if that was confusing.

Re: Show HN: Under the hood ReactJS

#56

Post by jchw »

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…

Sure, the abstractions can be different. I didn't say React is literally the only answer. I said it's fast and it beats the naive approach (i.e. jQuery crap.) But even if binding is fast, I think most people who moved on from stuff like Knockout to React do not have any desire to move back. I know I don't.

But if you're going to accuse React's value proposition as being just a marketing pitch, I'd love to hear what evidence that virtual DOM is in fact pointless, and then why Angular 2 and Ember are doing the same sort of thing despite this, even though they have vastly different programming models than React.

Also, regarding your last point, I really doubt Facebook accidentally made DOM diffing without realizing it would improve performance of reactive programming in JS.

Re: Show HN: Under the hood ReactJS

#57

Post by daliwali »

Ralfp wrote: post #51
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 am sorry but this sounds like Dunning-Kruger effect on your part. You have created library that you think the problem, but which seems to have limited adoption in the wild. What experience in the field you have? Have you wondered how much you don't know about problems and scenarios that view layer has to handle? I've been in same situation once with my OS project. I've did something small that I've been certain doe…

I've done very little marketing, and I am effectively a nobody without a huge following or elite credentials unlike some of the people behind the most popular frameworks. It would be completely unfair to judge me based on popularity and making negative assumptions about my experience, rather than merit.

In fact I refuse to market my pet project as if it is something to be bought and sold. or to assign it a valuation based on how many big companies are using it.

Re: Show HN: Under the hood ReactJS

#58

Post by daliwali »

jasode wrote: post #53
daliwali wrote: post #48

Earlier quoted context omitted.

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…

>that I've heard countless times from fanboys If you're unaware, "fanboys" is a grenade to incite juvenile flamewars instead of collegial discussion. >What's missing is that you can make complex web apps without any of these things, To attempt better instructive discussion instead of arguing from vague and generic platitudes about "needless complexity", can you explain how your simulacra.js (~12kb) is better than rea…

A paragraph of well thought out text will be ignored. A critical remark on the web framework du jour will be carefully deconstructed, rebutted, and shamed. Funny how that works.

Re: Show HN: Under the hood ReactJS

#60

Post by jchw »

daliwali wrote: post #58
jasode wrote: post #53

Earlier quoted context omitted.

>that I've heard countless times from fanboys If you're unaware, "fanboys" is a grenade to incite juvenile flamewars instead of collegial discussion. >What's missing is that you can make complex web apps without any of these things, To attempt better instructive discussion instead of arguing from vague and generic platitudes about "needless complexity", can you explain how your simulacra.js (~12kb) is better than rea…

A paragraph of well thought out text will be ignored. A critical remark on the web framework du jour will be carefully deconstructed, rebutted, and shamed. Funny how that works.

Well for one thing, I really think you're taking this a bit too personally. I don't think anyone here is intending to 'shame.'
Post reply on HN