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

31–40 of 124 posts

Re: Show HN: Under the hood ReactJS

#31

Post by harel »

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…

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 the OP - thanks. This is quite a feat.

Re: Show HN: Under the hood ReactJS

#32

Post by litzer »

daliwali wrote: post #26
litzer wrote: post #22

Earlier quoted context omitted.

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

> One can use built-in constructs like for loops in vanilla JS to update multiple DOM nodes at once

That's not the kind of use case that'd require React. I think we're on the same page that for the majority of apps, that setup is overkill. I'm just pointing out that there are apps with complex use cases where the "see where this is going" will end up being more elegant/simpler than fleshing out your own constructs (certainly more than a for loop)

Re: Show HN: Under the hood ReactJS

#33

Post by daliwali »

harel wrote: post #31
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…

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 about your abilities than the performance of frameworks.

[0] http://www.stefankrause.net/js-frameworks-benchmark6/webdriv...

Re: Show HN: Under the hood ReactJS

#35

Post by gfxl »

Nice work, but some parts make as much sense as Lorem ipsum text. One of my favorites so far:

> An instance of what should be created (03)? Component… right, but which one? Well, it’s a good point. No, not that’s 100% :) We actually should instantiate some internal class. Let’s check out the next scheme at first.

Re: Show HN: Under the hood ReactJS

#36

Post by madeofpalk »

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…

That post doesn't benchmark how a team of developer worth together, or how you manage all your code.

The speed of a for-loop is only a part of what makes a codebase 'fast'.

Re: Show HN: Under the hood ReactJS

#37

Post by localvoid »

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…

>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?

Re: Show HN: Under the hood ReactJS

#38

Post by notsrg »

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

Re: Show HN: Under the hood ReactJS

#39

Post by kaoD »

daliwali wrote: post #21
kaoD wrote: post #18

Earlier quoted context omitted.

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

I was taught UML activity diagrams were high-level representations, while this is a (summarized) flow chart of code paths (which makes it quite big in comparison to what would be its high-level UML counterpart).

UML is supposed to be an architectural diagramming standard. What's the point of diagramming in UML the actual code paths?

E.g.: you'd never have object shapes or function calls in an UML activity diagram.

This is just an ad-hoc flow chart AFAICT.

Re: Show HN: Under the hood ReactJS

#40

Post by daliwali »

localvoid wrote: post #37
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…

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

Post reply on HN