Hacker News new | ask | show | jobs
by lhorie 3026 days ago
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.
2 comments

> 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.
Lifecycles has nothing to do with vdom. Even web components has lifecycle hooks https://developer.mozilla.org/en-US/docs/Web/Web_Components/...

Have you tried to build a components library, or have you seen any component libraries that is built on top of a framework that doesn't provide lifecycle hooks for components? Something like https://ant.design/docs/react/introduce or https://developer.microsoft.com/en-us/fabric#/components

The term "lifecycle" in web components has a completely different meaning compared to its use in vdom implementations. Compare the semantics of "lifecycle" events in web components against React: https://reactjs.org/docs/react-component.html

They have virtually nothing in common. Web components are essentially just new DOM events, albeit more restricted.

I started this thread by mentioning Surplus, which has no lifecycles because it operates directly on the DOM, and so React's lifecycle callbacks have no use.

> They have virtually nothing in common.

If you think so, then there is really nothing to discuss ;)

Lifecycles are important if you need to do some arbitrary DOM manipulation upon mounting an element to the DOM tree. For example, you may want to render a google map when navigating to some route.

"Overcomplication" is in the eye of the beholder. You can't tell your client that his wanting a map in the contact page is "overcomplicating a conceptually simple process". At some point, if a system's restrictions are too strict for the sake of simplicity/beauty/etc, then it ceases to be useful in the real world.

Does S.js keep track of dependencies that are no longer needed? Is there some sort of garbage-collection implemented?