Earlier quoted context omitted.
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.
And people can read both the article and the source code.
Show HN: Under the hood ReactJS
71–80 of 124 posts
Re: Show HN: Under the hood ReactJS
#72Earlier quoted context omitted.
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.
I see now, that the bindObject() function takes a mapper from data to DOM. There are two downsides to this: 1) You have to define twice where the data is displayed. Once in the template and then again in the mapper. 2) {{NAME}} explicitly tells the reader "The name goes here". In your solution one would have to look it up in the mapper to be sure what goes where.
I'm well aware that there must be an element and a selector for that element. But this is exactly how CSS works as well, it's separation of concerns. Only recently have inline styles become trendy, much to my dismay.
The total absence of templating syntax is a deliberate decision. It enables one to start from an HTML mock-up or static page, and build interactivity on top of that without changing any HTML.
Re: Show HN: Under the hood ReactJS
#73This is helpful to me because I want to learn how to explain (complex) systems.
Incidentally, this complexity is what led me to build my own little vdom utility " rel="nofollow">https://github.com/hyperapp/hyperapp>.
I'll be drawing inspiration from this chart to explain it.
Re: Show HN: Under the hood ReactJS
#74Earlier quoted context omitted.
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.'
If shaming isn't the purpose of downvoting, or the soft suppression of controversial opinions, then I don't know what is.
Crying "shaming" in response to people pointing out your neither being constructive nor producing a substantive point to engage with is, honestly, rather missing the point of how HN works.
The purpose of downvoting is to indicate that your comments mostly consist of assertions that "react is bad" without really making a proper case for it, and as such don't really contribute to the signal of the discussion at hand - especially since the discussion at hand is about an explainer of the architecture, not a critique of the architecture itself.
If you look at e.g. discussions on vue vs. react posts you'll find that the "react is overcomplicated, here's a cost/benefit analysis" opinion is not controversial at all, and that a reasoned discussion of it will be responded to constructively (or that non-constructive responses will themselves be downvoted).
Re: Show HN: Under the hood ReactJS
#75Earlier 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…
> You are depending on some complex third party code to do your job
Yes. It's called a web browser.
The additional complexity of react is a drop in the bucket compared to the complexity of the undertlying platform.
Re: Show HN: Under the hood ReactJS
#76Earlier quoted context omitted.
Every fanboy says their preferred framework is the simplest, fastest, most scalable and most testable. That's a way argument though; just because these are metrics on which frameworks are compared does not mean that there is no comparison possible. In fact, I'd say quite the opposite! And the analogy falls apart when you consider that modern web frameworks are invariably slower or roughly equal in performance to its…
>I'll bet that React will be a whole bunch faster than whatever DOM reconciliation library you build up from scraps of vanilla JS You don't have to bet, you can verify the results yourself. Look here at these benchmarks [0] and compare, Simulacra.js is 22-42% faster than React v15 (depending on whether you also use Redux or MobX). My "scraps of vanilla JS" performs faster! Vanilla without frameworks/libraries is and…
Those all seem to be single-widget relatively simple benchmarks.
What happens in an app with multiple views on screen into the same state and multiple pieces of data updating at once is much more interesting.
Remember most of these frameworks are aimed at things that are far more 'web application' than 'web site'.
Re: Show HN: Under the hood ReactJS
#77Earlier 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.
So does that mean inferno is both theoretically better and already dead? :(
Re: Show HN: Under the hood ReactJS
#78Earlier quoted context omitted.
>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…
> You are depending on some complex third party code to do your job Yes. It's called a web browser. The additional complexity of react is a drop in the bucket compared to the complexity of the undertlying platform.
Haha so true. I keep forgetting that... I take browsers for granted sometimes.
Re: Show HN: Under the hood ReactJS
#79Earlier quoted context omitted.
I see now, that the bindObject() function takes a mapper from data to DOM. There are two downsides to this: 1) You have to define twice where the data is displayed. Once in the template and then again in the mapper. 2) {{NAME}} explicitly tells the reader "The name goes here". In your solution one would have to look it up in the mapper to be sure what goes where.
I'm well aware that there must be an element and a selector for that element. But this is exactly how CSS works as well, it's separation of concerns. Only recently have inline styles become trendy , much to my dismay. The total absence of templating syntax is a deliberate decision. It enables one to start from an HTML mock-up or static page, and build interactivity on top of that without changing any HTML.
this is exactly how CSS works as well
.city {color: blue; font-family: arial;}
{{NAME}} has {{POPULATION}} residents
city={name: "New York", population: 8491000}
Re: Show HN: Under the hood ReactJS
#80Earlier quoted context omitted.
If shaming isn't the purpose of downvoting, or the soft suppression of controversial opinions, then I don't know what is.
Crying "shaming" in response to people pointing out your neither being constructive nor producing a substantive point to engage with is, honestly, rather missing the point of how HN works. The purpose of downvoting is to indicate that your comments mostly consist of assertions that "react is bad" without really making a proper case for it, and as such don't really contribute to the signal of the discussion at hand -…
You missed the first sentence:
>A paragraph of well thought out text will be ignored.
I don't feel that it is necessary to have to explain in depth why having such a complex architecture for doing a simple task such as manipulating web pages is a bad thing. It would be like having to explain a joke. Moreover, such a critique would hardly be specific to React, but rather all of the current mainstream front-end web frameworks.