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

81–90 of 124 posts

Re: Show HN: Under the hood ReactJS

#81

Post by bliashenko »

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…

Well, actually it looks like (IMHO) there are too many abstractions levels, in fact - I omit many of them on the scheme, and it's still complex. But if we think why that happened, it's because of multiple platforms supports mostly (native, server rendering, etc), each "sensitive for platform" part of logic requires at least module with interfaces, modules with implementation per each platform, module-injector for exact implementation and so on..

Re: Show HN: Under the hood ReactJS

#82

Post by matthewmacleod »

daliwali wrote: post #68
matthewmacleod wrote: post #63

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

Your Simulacra.js is a framework, though. Yes, one framework might be faster than another; that's why there are other tradeoffs.

Re: Show HN: Under the hood ReactJS

#83

Post by daliwali »

mst wrote: post #76
daliwali wrote: post #68

Earlier quoted context omitted.

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

That describes the DBMon benchmark [0] pretty accurately. It has a hundred "components" (rows), each with several subcomponents that re-render based on state changes.

Actually it is less interesting and indicative of mainly one aspect of web app performance, that is re-rendering. The JS Framework Benchmark gives one a more holistic overview that includes bulk insertion, deletion, swapping, events, startup time, etc.

On this benchmark, Simulacra.js outperforms React by a wider margin.

[0] https://mathieuancelin.github.io/js-repaint-perfs/

Re: Show HN: Under the hood ReactJS

#84

Post by daliwali »

matthewmacleod wrote: post #82
daliwali wrote: post #68

Earlier quoted context omitted.

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

Your Simulacra.js is a framework, though. Yes, one framework might be faster than another; that's why there are other tradeoffs.

Simulacra.js is a single function (!), not much of a library, and very far from being a framework.

Re: Show HN: Under the hood ReactJS

#85

Post by lopatin »

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…

It's not complexity that you take on. The React API is minimal. It's complexity that the React authors take on in order to provide a stable, cross platform, predictable component lifecycle. And if some of that complexity leaks through, or you don't like the file size of the resulting library, feel free to not use it, but I wouldn't go so far as to say that solving hard problems via sufficiently abstracted away complexity is a bad thing.

With React Native I re-use over 75% of code from the web version of my apps. An actual measurable leap in productivity. Or even just for the web version, React and other frameworks (inb4 "not a framework"), provide their own proven patterns and best practices for scaling a code base, a task that is out of scope of any DOM utility library. And if providing those patterns requires more complexity under the hood, well, you don't refuse a free Lamborghini because it's "more complex under the hood" than your current Toyota.

Re: Show HN: Under the hood ReactJS

#86

Post by daliwali »

mst wrote: post #75
daliwali wrote: post #47

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

Minimalist, modern web browsers exist. A good example of this is surf [0], which is based on WebKit and is [0] http://surf.suckless.org/

Re: Show HN: Under the hood ReactJS

#87

Post by ivanr »

hardwaresofton wrote: post #67

At this point I'm sure I and others sound like a broken record, but if you're new and just jumping into frontend component-based frameworks, please don't start with React. There are simpler ways to get reasonably fast re-usable components on your project that introduce less accidental complexity. Carefully consider which thing you actually need: - A view library that uses components as the main building block (this u…

Perhaps you're right, but it would be useful if you mentioned those other choices here.

Re: Show HN: Under the hood ReactJS

#88

Post by always_good »

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…

You're being a bit dishonest in these posts. Maybe it's your marketing style and maybe it works, but it puts me off.

I even see it in your landing page marketing.

    > MINIMAL
    > One function
    > Its entire API surface area is a single function
Then I scroll down.

    var bindObject = require('simulacra')
    var bindEvents = bindObject.bindEvents
    var animate = bindObject.animate
    var retainElement = bindObject.retainElement

Re: Show HN: Under the hood ReactJS

#89

Post by daliwali »

TekMol wrote: post #79
daliwali wrote: post #72

Earlier quoted context omitted.

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 I beg to differ. There is no mapping needed for CSS. CSS works by once defining where the style shall go: And once what the style is: .city {color: blue; font-family: arial;} Similar, template syntax once defines where the data shall go: {{NAME}} has {{POPULATION}} residents And once, what the data is: city={name: "New York", population: 8491000} Neither need additional mapping.

I'm not sure I understand what you mean by additional mapping.

Here's all that's needed in the template:

     has  residents
And the mapping would be:

   [ 'city': [ '.city', { name: '.name', population: '.population' } ] ]
If you don't want to manually define a mapping, you could do it automatically by assuming that some attribute like `data-bind` corresponds to a binding, but Simulacra.js doesn't make assumptions like that.

Re: Show HN: Under the hood ReactJS

#90

Post by daliwali »

always_good wrote: post #88
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…

You're being a bit dishonest in these posts. Maybe it's your marketing style and maybe it works, but it puts me off. I even see it in your landing page marketing. > MINIMAL > One function > Its entire API surface area is a single function Then I scroll down. var bindObject = require('simulacra') var bindEvents = bindObject.bindEvents var animate = bindObject.animate var retainElement = bindObject.retainElement

There is actually only one function, that is the one returned from `require('simulacra')`, the others are merely conveniences that are common enough, and `retainElement` is a symbol, not a function.

To demarcate this separation better I have considered moving the optional convenience functions into a separate module, which might help clear things up.

Edit: actually it seems that you were being dishonest when quoting me, this is what it says, you cut it off short:

>Its entire API surface area is a single function (with some optional helpers and symbols)

That makes it pretty clear that the core functionality is a single function.

Post reply on HN