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

Show HN: Moon – fast 7k Vue alternative

github.com

Post reply on HN
Print view View original

91–100 of 200 posts

Re: Show HN: Moon – fast 7k Vue alternative

#91

Post by oever »

leeoniya wrote: post #85
oever wrote: post #15

Earlier quoted context omitted.

> There is really no way to avoid GC when you have a virtual DOM. If you keep the virtual DOM in a typed array, there is not need for relying on the JavaScript garbage collection. Here's an example: https://github.com/vandenoever/baredom/blob/master/src/bared...

what's the cost of resetting & reusing pre-allocated memory vs letting the GC discard stuff. if the cost of resetting is greater than the cost of collecting & re-allocating, then you're in the same place. at least in my experiments of trying to reuse already-allocated virtual nodes and resetting their properties was slower than simply unreferencing them for the GC and re-allocating new ones. have you tested the trade…

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

As a vdom hidden behind an API like in the case of Moon or Vue, typed arrays could still make sense.

Re: Show HN: Moon – fast 7k Vue alternative

#93

Post by cwbrandsma »

smegel wrote: post #72
litzer wrote: post #62

Earlier quoted context omitted.

This is a common thought: https://xkcd.com/927/ You could point to frameworks which have had majority usage at any given point and say those were the "right" ways at the time. But ideas evolve, which isn't so ridiculous.

The correct analogy would be "There are 14 competing standards with a new one released each week that creates doubt about the ongoing use of existing established standards and know one knows what the fuck is going on".

Do you want an open ecosystem or a controlled one? There is no in between, and you will hate it no matter what you choose. On the Open ecosystem side of things you have things like Linux with 10,000 independent distributions doing slightly different things. On the controlled you have Microsoft, Apple, and Oracle telling developers the "right" way to do things.

Re: Show HN: Moon – fast 7k Vue alternative

#94

Post by leeoniya »

oever wrote: post #91
leeoniya wrote: post #85

Earlier quoted context omitted.

what's the cost of resetting & reusing pre-allocated memory vs letting the GC discard stuff. if the cost of resetting is greater than the cost of collecting & re-allocating, then you're in the same place. at least in my experiments of trying to reuse already-allocated virtual nodes and resetting their properties was slower than simply unreferencing them for the GC and re-allocating new ones. have you tested the trade…

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 in "Scripting" is heap allocations, which i'll concede may be a good amount - do you know if there's a way to measure cumulative time spent growing the heap?

[1] http://leeoniya.github.io/domvm/demos/bench/dbmonster/

[2] http://imgur.com/a/TwwRf

Re: Show HN: Moon – fast 7k Vue alternative

#95

Post by xigency »

continuations wrote: post #90
kbr wrote: post #79

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

Does it support native mobile development? To me that's an important issue. Vue has Weex. React has React Native. Angular has NativeScript. I'd need something similar to switch to a new frontend framework.

Why? Are you making a website or creating an app.

Re: Show HN: Moon – fast 7k Vue alternative

#96

Post by valuearb »

kbr wrote: post #79
nkkollaw wrote: post #78

Looks good, but a slight improvement in speed is not enough IMHO to switch from a proven, popular framework (like React or Vue). I think it takes a radical take on the problem to balance out the cons of using an unproven framework for any non-personal project.

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?

Re: Show HN: Moon – fast 7k Vue alternative

#98

Post by kbr »

factsaresacred wrote: post #97

Congrats on building something that obviously took a lot of time and effort. But would it not have been easier to simply submit a few pull requests to the Vue.js project?

Thank you. It would actually have been more difficult to submit a PR to Vue, as Moon's internals are completely different. It would have tons of breaking changes as well, so I created a new project as a result.

Re: Show HN: Moon – fast 7k Vue alternative

#100

Post by wolco »

xigency wrote: post #95
continuations wrote: post #90

Earlier quoted context omitted.

Does it support native mobile development? To me that's an important issue. Vue has Weex. React has React Native. Angular has NativeScript. I'd need something similar to switch to a new frontend framework.

Why? Are you making a website or creating an app.

The answer to that question is always: yes.
Post reply on HN