So we are here. It didn't took so long for vue to go from "will vue be new react ?" To "vuejs alternative".
Isn't it a fun time to be a front-end developer?
Show HN: Moon – fast 7k Vue alternative
101–110 of 200 posts
Re: Show HN: Moon – fast 7k Vue alternative
#102Earlier quoted context omitted.
I just reran the test page in the repo and browsers have certainly improved. The gains have shrunk to the point (2x speedup at best) that the use of an unsafe API would not be recommended for general use. The test can also run a 'Simple' virtual dom which is a naive implementation with Javascript Objects. That one is currently faster than the typed arrays in Firefox, but in Chromium, the typed arrays are still much f…
> The gains have shrunk to the point (2x speedup at best) call me a skeptic, but i suspect that whatever impl you're comparing against is not terribly good. this bench [1] allocates (and discards) ~3,000 virtual nodes per redraw, and each redraw is ~1.3ms, pegged @ 60fps. the GC time is ~2% [2], so even if all GC went away, a 2x speedup is plain impossible. unless you're suggesting that the majority of the time spent…
> whatever impl you're comparing against is not terribly good.
Indeed it is not. The reference is a naive Object based DOM. The benchmark is also not using complete rendering and diffing: it uses versioning on the nodes. It replaces the updated dom nodes at a configurable rendering frequency. So it's very different and probably slower than current frameworks.
The remark that triggered the mention of baredom was the supposed unavoidability of the GC. Baredom does not use it and WebAssembly might make non-GC VDoms popular. Still, JS engines GC has gotten very good.
Re: Show HN: Moon – fast 7k Vue alternative
#103Earlier quoted context omitted.
> This makes it faster to load on mobile devices. That's not very significant, since even your favicon will be of comparable or even bigger size, much less any static asset like an image.
it's significant because code has to be additionally parsed and JIT-compiled. which is not true of images which simply blit pixels to screen as they decompress; it's not simply about size on the wire. https://twitter.com/HenriHelvetica/status/877924754195324928
Even in parse time, a 23kb difference would be barely if at all noticeable on the worst performant devices. That chart is for 1MB of JavaScript, and I assume the x-axis is in milliseconds.
Re: Show HN: Moon – fast 7k Vue alternative
#104Earlier quoted context omitted.
it's significant because code has to be additionally parsed and JIT-compiled. which is not true of images which simply blit pixels to screen as they decompress; it's not simply about size on the wire. https://twitter.com/HenriHelvetica/status/877924754195324928
Even in parse time, a 23kb difference would be barely if at all noticeable on the worst performant devices. That chart is for 1MB of JavaScript, and I assume the x-axis is in milliseconds.
true. i guess the point of the comment was that you can't compare loading an image to loading & executing a script by filesize.
Re: Show HN: Moon – fast 7k Vue alternative
#105Earlier quoted context omitted.
It's 7kb minified and gzipped. Vue is almost 30kb. If you use a runtime version of Moon, it becomes 3kb. This makes it faster to load on mobile devices. Along with that, it also has lots of official plugins similar to what Vue provides.
If it has plugins, how many do you need to match key Vue features and how long do they take to load?
Each plugin is about 2kb and takes a couple milliseconds to load. By plugins I meant things like moon-router and monx.
Check out the "extras" section in the README: https://github.com/kbrsh/moon#extras
Re: Show HN: Moon – fast 7k Vue alternative
#106Earlier quoted context omitted.
> This makes it faster to load on mobile devices. That's not very significant, since even your favicon will be of comparable or even bigger size, much less any static asset like an image.
it's significant because code has to be additionally parsed and JIT-compiled. which is not true of images which simply blit pixels to screen as they decompress; it's not simply about size on the wire. https://twitter.com/HenriHelvetica/status/877924754195324928
>it's significant because code has to be additionally parsed and JIT-compiled.
Which again be insignificant compared to the time it takes to download those assets from a cellular connection.
Not to mention that today's (and 2015's) mobile CPUs aren't that slow, they are comparable to mid-level laptops from 2010 or even later. If you're catering to the developed world, visitors wise, you'll be ok with 30K.
Re: Show HN: Moon – fast 7k Vue alternative
#107So we are here. It didn't took so long for vue to go from "will vue be new react ?" To "vuejs alternative".
Isn't it a fun time to be a front-end developer?
>Isn't it a fun time to be a front-end developer?
No.
I came to frontend development on the peak of web 2.0 craze, when 10mb of jQuery "bells and whistles" on a corporate front page was considered hip and progressive. No matter how awful these 10mb of animation scripts were, they ran faster than 1mb of "highly optimised" react spa today.
Re: Show HN: Moon – fast 7k Vue alternative
#108Can all the JS framework people lock themselves in a building for a year and figure our the right way to do this -- and only then share it with the world? Getting ridiculous.
browser vendors need to do this. we need a standardized declarative dom patching mechanism with data-binding that has optimal perf so we dont need to keep reimplementing virtual-dom.
Over in Polymer, we're exploring ways to do exactly that: https://github.com/PolymerLabs/lit-html
Template literals in JS give us a way to always tell the static from dynamic parts of a template. HTML elements let us stamp out pre-defined trees of DOM quickly. Combined we can then only update the dynamic parts without a virtual DOM.
Re: Show HN: Moon – fast 7k Vue alternative
#109Earlier quoted context omitted.
Isn't it a fun time to be a front-end developer?
>Isn't it a fun time to be a front-end developer? No. I came to frontend development on the peak of web 2.0 craze, when 10mb of jQuery "bells and whistles" on a corporate front page was considered hip and progressive. No matter how awful these 10mb of animation scripts were, they ran faster than 1mb of "highly optimised" react spa today.
Can you really prove that feeling? because that's far from my experience and far from logical too..
Additionally, this 'fatigue' with front-end is getting a bit over told, I suspect it might be more alienation from developers who hacked jquery scripts together and feel they need to transition to app frameworks (I see so many simple websites and landing pages as react etc now).. where as those sites should just transition to vanilla js + dom..
The thing about inspired frameworks and 'churn' isn't a javascript/front-end thing, it happens everywhere, constantly... how many IOC, DI, ORM frameworks did Java and .NET have..
Re: Show HN: Moon – fast 7k Vue alternative
#110Earlier quoted context omitted.
browser vendors need to do this. we need a standardized declarative dom patching mechanism with data-binding that has optimal perf so we dont need to keep reimplementing virtual-dom.
Over in Polymer, we're exploring ways to do exactly that: https://github.com/PolymerLabs/lit-html Template literals in JS give us a way to always tell the static from dynamic parts of a template. HTML elements let us stamp out pre-defined trees of DOM quickly. Combined we can then only update the dynamic parts without a virtual DOM.
were you aware of https://github.com/trueadm/t7 when you started?
are there advantages over t7, other than NIH?