Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How I built a fast JavaScript framework

medium.com

Post reply on HN
Print view View original

51–60 of 68 posts

Re: How I built a fast JavaScript framework

#51

Post by amelius »

lhorie wrote: post #50
amelius wrote: post #49

Earlier quoted context omitted.

Yes, you can code like that, but ultimately that block will be contained inside a closure that will get triggered by some change. Of course, unless you are very careful.

The element creation part will be triggered if a creation is required. It won't be triggered by a prop update, for instance. In the following example, I change the button id on click. It's still the same button element after the change: https://jsfiddle.net/dwn36aw4/8/

But it's very difficult to prevent unnecessary dependencies from triggering in all cases. Consider a map (dict) with some values. Some outer code depends on the map. This code builds some DOM elements and sets values based on the values in the map. Now, if the map changes, all the elements will be recreated, even if effectively some irrelevant part of the map changed. Of course you can prevent this from happening by doing smart diffing on the map, but now you've effectively moved the problem from dom-diffing to map-diffing.

Re: How I built a fast JavaScript framework

#52

Post by exogen »

expertentipp wrote: post #46
exogen wrote: post #39

Earlier quoted context omitted.

CSS Grid does the opposite of what you claim – it fixes the mixing of concepts that previously tied HTML elements to their layout, not make it worse.

table, td, tr, etc are perfectly valid and semantic HTML elements. Are HTML5's footer and header elements broken as well, shall we expect "footer-" and "header-" CSS properties in 5 years?

I have no idea why you keep bringing up . It is totally unlike CSS Grid and completely unrelated in every way.

CSS Grid is for layout, not tabular data. It allows you to move the presentation of your elements around at different breakpoints regardless of your markup structure.

In general I recommend understanding a feature before you spout off nonsense about it.

Re: How I built a fast JavaScript framework

#53

Post by lhorie »

amelius wrote: post #51
lhorie wrote: post #50

Earlier quoted context omitted.

The element creation part will be triggered if a creation is required. It won't be triggered by a prop update, for instance. In the following example, I change the button id on click. It's still the same button element after the change: https://jsfiddle.net/dwn36aw4/8/

But it's very difficult to prevent unnecessary dependencies from triggering in all cases. Consider a map (dict) with some values. Some outer code depends on the map. This code builds some DOM elements and sets values based on the values in the map. Now, if the map changes, all the elements will be recreated, even if effectively some irrelevant part of the map changed. Of course you can prevent this from happening by…

I wrote about that (and the drawbacks and alternative takes) here: https://news.ycombinator.com/item?id=16540223 but yes, in a nutshell, "move the problem from dom-diffing to map-diffing" is basically what a reactive system is supposed to be taking care of.

You're absolutely right that reactive systems are not trivial to implement (let alone implement well), but inefficient DOM recreation under these systems is a symptom of poor granularity in the reactive layer (which may be a problem with the reactivity library just as well as it could be poor usage of its API), rather than a limitation of the rendering library itself.

Re: How I built a fast JavaScript framework

#54

Post by brlewis »

lhorie wrote: post #47
TomMarius wrote: post #45

Earlier quoted context omitted.

That's not true. Virtual DOM was created to avoid recreating huge DOM elements each time a re-render is needed, which was the way apps used to be done in the days of jQuery.

Eh, not exactly right either. In the jQuery days, the problem is that you needed different procedural code paths to go from one DOM state to another depending on what action you took. For example, adding a row to a list would be `$('.list').html(html)`, removing would be `$('.list :last-child').remove()` and updating one item might be `$('.list #' + id).text(value)`. Templating engines such as handlebars provide a de…

I was reading this thinking, gee, here's someone who knows a lot about JS frameworks. Only later noticed the username. Hi Leo!

Re: How I built a fast JavaScript framework

#55

Post by localvoid »

lhorie wrote: post #22
naasking wrote: post #14

Surplus [1] is the fastest framework in the big JS benchmark challenge, and it too uses the native DOM directly rather than a virtual DOM. Looking forward to seeing Radi.js added to that benchmark suite to really put it to the test. [1] https://github.com/adamhaile/surplus

What primarily makes surplus fast isn't necessarily that it doesn't use a virtual dom, but that changes are tracked with a data reactivity library reminiscent of knockout called s.js instead. On the DOM side, it has a compiler like svelte that generates JIT friendly expressions, e.g. el.className = val instead of el[prop] = val.

> but that changes are tracked with a data reactivity library reminiscent of knockout called s.js instead

Surplus is fast because it doesn't have many features that available in many other libraries. For example, component model with lifecycles.

In this benchmark, "select row" should be the best case scenario for library like this, but even in such scenario it is slower than some vdom libraries.

Re: How I built a fast JavaScript framework

#56

Post by localvoid »

lhorie wrote: post #47
TomMarius wrote: post #45

Earlier quoted context omitted.

That's not true. Virtual DOM was created to avoid recreating huge DOM elements each time a re-render is needed, which was the way apps used to be done in the days of jQuery.

Eh, not exactly right either. In the jQuery days, the problem is that you needed different procedural code paths to go from one DOM state to another depending on what action you took. For example, adding a row to a list would be `$('.list').html(html)`, removing would be `$('.list :last-child').remove()` and updating one item might be `$('.list #' + id).text(value)`. Templating engines such as handlebars provide a de…

> It's inherently memory intensive

Even if we pretend that other architectures doesn't have any memory overhead, vdom memory overhead in a large UI app will be less than a single small decoded image. But in reality, KVO can be way much more memory intensive, especially when we consider cases that involve filtering items in large collections.

Re: How I built a fast JavaScript framework

#57

Post by amelius »

lhorie wrote: post #53
amelius wrote: post #51

Earlier quoted context omitted.

But it's very difficult to prevent unnecessary dependencies from triggering in all cases. Consider a map (dict) with some values. Some outer code depends on the map. This code builds some DOM elements and sets values based on the values in the map. Now, if the map changes, all the elements will be recreated, even if effectively some irrelevant part of the map changed. Of course you can prevent this from happening by…

I wrote about that (and the drawbacks and alternative takes) here: https://news.ycombinator.com/item?id=16540223 but yes, in a nutshell, "move the problem from dom-diffing to map-diffing" is basically what a reactive system is supposed to be taking care of. You're absolutely right that reactive systems are not trivial to implement (let alone implement well), but inefficient DOM recreation under these systems is a sym…

Ok, that makes sense.

I'm also worried about debugging accidental dependency triggers. Imagine that suddenly the scroll-state of some div is reset; how do you determine which dependency caused the DOM element to be recreated? With a vdom you avoid the whole problem.

Re: How I built a fast JavaScript framework

#58

Post by naasking »

localvoid wrote: post #55
lhorie wrote: post #22

Earlier quoted context omitted.

What primarily makes surplus fast isn't necessarily that it doesn't use a virtual dom, but that changes are tracked with a data reactivity library reminiscent of knockout called s.js instead. On the DOM side, it has a compiler like svelte that generates JIT friendly expressions, e.g. el.className = val instead of el[prop] = val.

> but that changes are tracked with a data reactivity library reminiscent of knockout called s.js instead Surplus is fast because it doesn't have many features that available in many other libraries. For example, component model with lifecycles. In this benchmark, "select row" should be the best case scenario for library like this, but even in such scenario it is slower than some vdom libraries.

Lifecycles are only needed because of the vdom, it's not a desirable "feature" since it overcomplicates a conceptually simple process.

Re: How I built a fast JavaScript framework

#59

Post by Can_Not »

murukesh_s wrote: post #11
ng12 wrote: post #7

Earlier quoted context omitted.

Yup. I find that most cases of "JavaScript fatigue" are really cases of "I want tools custom tailored to my use case, but don't want to do the legwork to figure out what they are". The only thing wrong with jQuery is that it's perfectly fine until it isn't. Conversely, if you'll never need React's power you don't need it's complexity either.

React's (or other SPA frameworks like Vue's) complexity is much higher than it should have is probably because of the tooling (Babel, Webpack, NPM etc) and additional build process required even for a simple hello world app. That coupled with the rapid revision of the underlying ECMAScript standard and the race by developers and framework authors to adopt them causing further chaos. Another issue was the rapid deprec…

> React's (or other SPA frameworks like Vue's) complexity is much higher than it should have is probably because of the tooling (Babel, Webpack, NPM etc) and additional build process required even for a simple hello world app.

This is false or misleading. There is complexity, yes, but those tools abstract it away and simplify everything. Then they have configs with great documentation for when you need to deviate from a default or add a plugin. Next, these things are pre-configured for you. "More complex than it should be" is when you try to reinvent the power of these tools for literally no coherent reason.

Re: How I built a fast JavaScript framework

#60

Post by lhorie »

amelius wrote: post #57
lhorie wrote: post #53

Earlier quoted context omitted.

I wrote about that (and the drawbacks and alternative takes) here: https://news.ycombinator.com/item?id=16540223 but yes, in a nutshell, "move the problem from dom-diffing to map-diffing" is basically what a reactive system is supposed to be taking care of. You're absolutely right that reactive systems are not trivial to implement (let alone implement well), but inefficient DOM recreation under these systems is a sym…

Ok, that makes sense. I'm also worried about debugging accidental dependency triggers. Imagine that suddenly the scroll-state of some div is reset; how do you determine which dependency caused the DOM element to be recreated? With a vdom you avoid the whole problem.

> how do you determine which dependency caused the DOM element to be recreated

Normally, I would toss in a throw and look at the stack trace. But yes, the stack trace gets noisy as hell.

Post reply on HN