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

61–68 of 68 posts

Re: How I built a fast JavaScript framework

#61

Post by localvoid »

naasking wrote: post #58
localvoid wrote: post #55

Earlier quoted context omitted.

> 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

Re: How I built a fast JavaScript framework

#62

Post by naasking »

localvoid wrote: post #61
naasking wrote: post #58

Earlier quoted context omitted.

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

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.

Re: How I built a fast JavaScript framework

#63

Post by lhorie »

pygy_ wrote: post #36
Froyoh wrote: post #32

Earlier quoted context omitted.

Looks like the regex is only used to strip comments?

https://github.com/radi-js/radi/blob/eace84e9b74c944b233f631... It parses the source code of the view function at run time, matching parentheses, but ignoring whether those are present in strings or regexes. Likewise, the comment stripper will turn "/*whoops*/" into the empty string... In other words, the parser is buggy :-/

Having taken a closer look, it looks like the problems go even deeper than that: it rewrites `l()` calls in functions through a regex/replace on `fn.toString()`. This is similar to the mechanism that broke shorthand Angular.js DI in production. So code can break if it goes through some bundler than renames the `l` variable, or if a minifier does it, etc.

I'd imagine closures also break.

Re: How I built a fast JavaScript framework

#64

Post by localvoid »

naasking wrote: post #62
localvoid wrote: post #61

Earlier quoted context omitted.

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

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

> They have virtually nothing in common.

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

Re: How I built a fast JavaScript framework

#65

Post by pygy_ »

lhorie wrote: post #63
pygy_ wrote: post #36

Earlier quoted context omitted.

https://github.com/radi-js/radi/blob/eace84e9b74c944b233f631... It parses the source code of the view function at run time, matching parentheses, but ignoring whether those are present in strings or regexes. Likewise, the comment stripper will turn "/*whoops*/" into the empty string... In other words, the parser is buggy :-/

Having taken a closer look, it looks like the problems go even deeper than that: it rewrites `l()` calls in functions through a regex/replace on `fn.toString()`. This is similar to the mechanism that broke shorthand Angular.js DI in production. So code can break if it goes through some bundler than renames the `l` variable, or if a minifier does it, etc. I'd imagine closures also break.

Closures will break, yes. It looks like it is intended to react to mutations to the properties of `this`...

I hadn't thought of minification, yes it pretty bad :-/...

It looks like the author is smart but has little JS experience (`var last = temp.splice(-1)[0]` where `temp.pop()` would do tells me that it may be one of his first JS project).

Re: How I built a fast JavaScript framework

#66

Post by lhorie »

naasking wrote: post #58
localvoid wrote: post #55

Earlier quoted context omitted.

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

Re: How I built a fast JavaScript framework

#67

Post by meuk »

exogen wrote: post #52
expertentipp wrote: post #46

Earlier quoted context omitted.

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.

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

I disagree. Conceptually, it is exactly how you would do layout in the old days. This still works, btw, it's just considered bad practice.

It's a bit like saying that a kitchen knife is totally unlike a dagger and completely unrelated in every way, because the former is for slicing food and the latter for stabbing.

Re: How I built a fast JavaScript framework

#68

Post by exogen »

meuk wrote: post #67
exogen wrote: post #52

Earlier quoted context omitted.

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.

> I have no idea why you keep bringing up . It is totally unlike CSS Grid and completely unrelated in every way. I disagree. Conceptually, it is exactly how you would do layout in the old days. This still works, btw, it's just considered bad practice. It's a bit like saying that a kitchen knife is totally unlike a dagger and completely unrelated in every way, because the former is for slicing food and the latter for…

I'd say it's more like comparing a horse to a car:

Horses were never really "vehicles." We just misappropriated them that way, because they just happen to be big and move around and we can sit on them. Cars are purpose-made to be vehicles for humans.

If a designer shows you their wireframes with their grid lines drawn on top of it, I don't think many people would think "ah! so it's like in a science paper when they're printing the raw data from their experimental results in tabular form."

The fact that some web developers consider them alike is a historical accident.

Post reply on HN