
Show HN: Moon – fast 7k Vue alternative - kbr
https://github.com/kbrsh/moon
======
iansowinski
So we are here. It didn't took so long for vue to go from "will vue be new
react ?" To "vuejs alternative".

~~~
hashbig
Isn't it a fun time to be a front-end developer?

~~~
bartread
No: it leaves no goat unblown. Particularly for people new to it.

Back in the day anyone could hack together a bit of JS for their website and
get something up and running, even if it was a bit Heath Robinson. You
actually still can do this but you wouldn't necessarily come away with that
impression from reading about front-end development. Cynically, it sometimes
feels like front-end developers are overcompensating for years of JS derision
from "real" programmers with the plethora of tools and technologies you "need"
to know.

If people want to use this, well, they're welcome. I can even see some benefit
to a very lightweight UI/framework, especially if you don't have to worry
about any version of Internet Explorer below 11, because the browser APIs
these days are pretty comprehensive, and tend to behave reasonably
consistently. Likewise CSS. [1]

Still, I can't get in any way excited about yet another library/framework. Go
ahead and use it if you like but don't be trying to evangelise me about it.

([1] As an aside: I will say that IE11 is still something of a problem child
in terms of not supporting some things I use, or not supporting them well -
flexbox is an obvious example. Conversely, "scumbag" Chrome can be a problem
child simply because it lets you get away with doing things that you shouldn't
be allowed to do at all. E.g., `element.style = 'display: none'` instead of
`element.style.display = 'none'`, meaning that when you come to test your code
in other browsers... it breaks.)

~~~
greyskull
> it leaves no goat unblown

That's a first. Is that a common saying somewhere? Does it refer to literal
oral sex with a goat?

~~~
dasil003
"blows goats" goes back decades, but tbh I never really thought about what it
meant until this comment came forth with the hyperbole of fellating literally
every goat in existence.

------
samuelantonioli
I'm a big fan of Vue and I think Moon looks very promising. I have some
questions w.r.t Vue API compatibility:

\- In Vue, you can call a method or access a variable directly using this.var
or this.fn, did you deliberately choose to do it in a different way or are you
planning to implement this using _defineProperty_?

\- Are you planning to implement filters and refs?

\- Are you planning to make it compatible with Vue to make it a drop-in
replacement?

If it's gonna be a drop-in replacement and existing code can be reused, I can
imagine testing it for some projects (framework7 based).

Edit: Another idea would be to integrate all the performance improvements in
Vue, Evan You is a great developer who single-handedly built this great
framework and I think it's a good idea to make your ideas available for the
whole Vue ecosystem. Are you having plans to do that?

~~~
kbr
Awesome, I'll be glad to answer these!

1\. I'm not planning for this, as it has a runtime cost, but it can easily be
done with a plugin[1].

2\. I'm not planning to implement filters, as you can use methods instead.
Refs might be coming if there is enough demand.

3\. Moon is actually going in a different direction from Vue now. The core API
will be very similar, but it might not be a drop in replacement for some of
the advanced features of Vue. Most directives work, components are similar,
but it won't be fully compatible.

[1] [https://jsfiddle.net/btoegknn/](https://jsfiddle.net/btoegknn/)

EDIT: To answer your edited question: I agree, Evan is a super smart
developer, kudos to him for building Vue!

Applying some of the performance improvements might be a little complex for
Vue, because Moon's compiler is fundamentally different in a couple ways. It
generates code for a stricter HyperScript-like syntax (called "HyperMoon"),
while Vue aims to be compatible with JSX as well.

Differences like these, while might seem small, are actually pretty complex
when implemented in code.

~~~
samuelantonioli
Thanks for the fast answer!

That's a tough path you took and I wish you'll reach your goals. There are
currently many frameworks who want to get the mind share. Would you mind to
share your mindset behind the decision to split and build a new framework? Is
there something in Vue you oppose or new concepts you would like to introduce?
Would be very interested to hear your thoughts, I'm always on the lookout.

~~~
kbr
No problem! I wanted to build a new framework mainly because my Vue app was
becoming slow and I wanted something small. Moon is 7kb minified and gzipped,
that makes it really fast to load on mobile.

If you take out the compiler (similar to Vue's runtime version), Moon is only
3kb minified and gzipped!

Check out the Medium Article[1] and the README for more information on why I
made it.

[1] [https://hackernoon.com/introducing-
moon-1d44a99635f0](https://hackernoon.com/introducing-moon-1d44a99635f0)

~~~
samuelantonioli
Ah thanks, missed the "Another library?" part. I think it's a good idea to
address this question because this is the first one someone has after reading
the title (Vue, but faster & smaller). Maybe I'll use it for some side
projects, would be interesting to see if it is still easy to develop with a
subset of Vue's API.

------
sametmax
Can you explain what makes moon so much smaller and faster than vue ? What are
the key differences ? Does it lack features ? Could vue use some tricks from
moon ?

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

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

~~~
nkkollaw
Sure, don't get me wrong—I'm not saying it's useless or it isn't an
achievement.

You have to realize though that as developers we invest a lot of time on
learning a technology. Companies invest a lot of money into stacks. It's not
always easy to find developers and if your stack is "standard", it makes it
easier to both grow your team and get up to speed with the code.

For a developer, company, or team, 23KB of JavaScript aren't going to be a
very good incentive to ignore the advantages that come with using a standard
framework like Vue. Websites are easily 10MB in size nowadays, 23KB are a drop
in the ocean. I can optimize the logo and get 23KB without have my team learn
a whole new framework.

What I'm trying to say is that I don't think "smaller Vue alternative" is a
good selling point. If anything, because as your framework gains acceptance
people will want more features, and it will inevitably grow, and there goes
your competitive advantage.

It should do something better, or differently in a big way or a way people
care about.

Just my two cents. I've never created anything that a huge number of people
use, so I'm no institution in this area.

~~~
SamBam
> You have to realize though that as developers we invest a lot of time on
> learning a technology

But plenty of front-end developers have not developed in Vue. If I'm starting
a new project and someone suggests doing it in Vue, and I have to learn it all
anyway, I might consider this as an alternative.

------
sockopen
The title here says 7kb your front-page on moonjs.ga says 5kb and on the
overview page comparing it to other frameworks it says 6kb. All say minified
and gzipped.

~~~
kbr
Sorry! It looks like I haven't updated some parts of the site. The correct
size is 7kb, thanks for pointing that out.

------
lucisferre
The API looks very similar to Vue. Are there any places where you specifically
chose to be different, and can you explain some of your reasons?

~~~
kbr
Sorry for the late reply!

I chose to be different in small things, such as being explicit about getting
and setting properties on an instance. There are a couple oddities I didn't
like with Vue as well, such as the syntax for a couple directives.

Check out the Medium article[1], it has the main reasons on why I made Moon.

[1] [https://hackernoon.com/introducing-
moon-1d44a99635f0](https://hackernoon.com/introducing-moon-1d44a99635f0)

------
pspeter3
How does Moon automatically detect static virtual nodes? What makes Moon
faster than the alternatives? Finally, how does Moon avoid GC pressure with
large trees?

~~~
kbr
The compiler treats everything as static by default. When the compiler detects
something dynamic (such as a {{mustache}} template), it will mark the current
node as dynamic, and the parent node as well.

These propagate up the tree so Moon eventually has a render function that is
extremely optimized and can skip everything static, and the diff will only hit
the nodes that can change.

Moon also has a stricter syntax for virtual DOM, allowing for less checks to
be made at runtime compared to alternatives like HyperScript. This is made
possible because Moon's compiler itself is in charge of creating the render
functions, allowing it to give certain hints to the virtual DOM diffing
engine.

There is really no way to avoid GC when you have a virtual DOM. The virtual
DOM trees are pretty light and have memory usage similar to that of React and
Inferno.

~~~
oever
> 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...](https://github.com/vandenoever/baredom/blob/master/src/baredom/impl/Dom.js)

~~~
kbr
This is really cool! I'll definitely look into this and apply some of it to
Moon.

~~~
oever
BareDOM is a proof of concept, the code is not very clean, but I'm sure you
can get the ideas.

Since Moon has a specific way of using the DOM, you might be able to cut down
on the number of array positions per node (currently 8).

~~~
pspeter3
Is there any documentation on why to use a typed array

~~~
yorwba
Typed arrays are essentially tightly packed chunks of memory that the GC won't
walk. If you know what you're doing, you can use them to both save memory
(shaving off the per-object overhead of JS objects) and reduce the time spent
on GC collections (but you have to do your own memory management on the typed
array). That the typed array contains only objects of a single data type
probably also helps the JIT to optimize.

------
jcoffland
The performance improvements are impressive if they translate to real-world
apps, however speed is only one of the reasons I use Vue.js. The other big
reasons are stability and incredibly good documentation.

------
anon764587
I've lurked a while and seen people give all the js is shit js fatigue blah
blah and again we have this on this.

question I've got to ask to people posing this question is are you not
adaptable enough as a programmer to learn things fast?...I was a c# programmer
and in 1 month it was like yeah no problem I understand the new tools. in fact
the new frameworks taught me a lot about functional programming which was
fantastic.

You can winge all you want but it's here. It's not going away due to corp IE9
and to be honest it annoys me because the js ecosystem as well is the nearest
to open source ideals at the moment as a _lot_ of people are sharing code. I
can fix any bug in my dependency because I can read the source.

Yeah maybe some packages are useless. but tbh they're the ones that will sink
to the floor but the good ideas are passed about like a zep cd. js is the
first meme language (in the Dawkins sense) and it's extremely interesting to
see it develop in the public eye

~~~
adpoe
Just an opinion:

It's not that it's hard to learn this stuff. More so, it's tiresome and _hard
to care_ after watching the JS community re-inventing the same wheel(s),
repeatedly.

Personally, I'd rather see the JS community solve a wider variety of
problems.. instead of the same ones, over and over.

The amount of talent focused on building JS tools really is incredible. But it
seems like the tools that generate the most hype always do the _same_ things,
just in a shinier newer package. Which is frustrating.

I wasn't around at the time, but reading about programming languages past --
it seems like these are the same kinds of problems that fractured Lisp, back
in the day.

The problem is this: It's fun, exciting, and relatively simple to roll your
own X. So everyone does it. That's good. But too much fractures the community,
instead of uniting it. Which.. may be more harmful than helpful, in the long-
run. Time will tell. But the strongest & most productive communities typically
converge on 'best-practices', once a problem is solved well enough. JS doesn't
seem to do that. (At least not yet.)

------
cdevs
I just want someone to take another look at ontercooler js, the best CSS and
JavaScript is the CSS and JavaScript I don't have to write. Every time we hire
someone fresh out of college they ask if we can learn angular and my reply is
why do you need it? Because you heard of it? And basically that's the only
reason they mentioned it.

------
fny
If you want a blazing fast JavaScript framework that's actually supported by a
big company, look to Marko: [http://markojs.com/](http://markojs.com/)

The syntax is a bit strange, but once you get used to it, it's a pretty simple
framework to grok.

~~~
leeoniya
careful now...

all frameworks are blazing fast, but some are more blazing fast than others.

[https://rawgit.com/krausest/js-framework-
benchmark/master/we...](https://rawgit.com/krausest/js-framework-
benchmark/master/webdriver-ts-results/table.html)

~~~
pkstn
yup, and non-keyed is the easiest part :)

~~~
leeoniya
indeed, it is; i don't need to tell _you_ , though :p

when i originally asked the author to submit Moon to js-framework-benchmark
[1] i was surprised to hear that Moon's users have never needed or asked for
keyed updates [2].

there are some authors (myself included) that consider libs without keyed DOM
reconciliation to be seriously deficient.

[1]
[https://github.com/kbrsh/moon/issues/84](https://github.com/kbrsh/moon/issues/84)

[2] [https://github.com/krausest/js-framework-
benchmark/pull/212#...](https://github.com/krausest/js-framework-
benchmark/pull/212#issuecomment-315480911)

~~~
pkstn
I believe so too!

------
factsaresacred
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?

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

~~~
johnfn
Not knocking on your effort here, but you think that it would have taken more
effort to submit a PR to Vue than _building an entirely new open source
framework from scratch over the course of several years?_

If so, there is something very wrong with the state of open source
development.

~~~
kbr
Working on Vue would take similar effort, deleting tons of the code and
rewriting it.

Part of it is that this is project started as a way for me to learn what goes
on under the hood of libraries like React and Vue. While I made this, I wrote
a compiler (lex + parse + generate), virtual DOM engine, reactivity system,
and more!

I've started to take Moon in a different direction than Vue, and in the future
it will most likely be even more different than Vue.

~~~
5zBFyURxgY
Is that supposed to be good news?

------
sscarduzio
You say it's faster than Vue, but how much, how did you measure?

~~~
kbr
Moon is a part of js-framework-benchmark[1] (in the non-keyed results), and it
performs faster than Vue there. The article I wrote a while back also has some
benchmarks[2]. Finally, the overview section of the documentation also has
benchmarks[3].

[1] [https://rawgit.com/krausest/js-framework-
benchmark/master/we...](https://rawgit.com/krausest/js-framework-
benchmark/master/webdriver-ts-results/table.html)

[2] [https://hackernoon.com/introducing-
moon-1d44a99635f0](https://hackernoon.com/introducing-moon-1d44a99635f0)

[3] [http://moonjs.ga/docs/overview.html](http://moonjs.ga/docs/overview.html)

~~~
pkstn
There's no keyed benchmark for Moon, that's more difficult to optimize.

~~~
localvoid
He tried to solve performance problems in complex applications, and obviously
complex applications doesn't need to preserve internal state when children
list is changing :)

~~~
kbr
Haha didn't see this. Moon hasn't hit v1 yet, and a keyed virtual DOM is
definitely on the roadmap.

~~~
agumonkey
Hi, pardon my noobness, what keyed means here ?

------
maxscam
I dont particularly care whether or not its faster than vue or react. If I'm
going to build a heavy use production app I would use one of those just
because it has so much of a community supporting it. But sometimes less is
more. The api here is simple, and yes similar to vue and react. The guts of
the docs took like 5 minutes to read through. Over time, the novel concepts
introduced by these frameworks turn into general best practices. That's what
we see here. A boiling down of the reactive web framework into a small set of
core methods. Certainly not the most powerful or extensible. But perhaps the
most simple.

------
gedy
Looks like nice work, also reminds me of Ractive
([https://ractive.js.org](https://ractive.js.org))

------
swlkr
If your web app is highly interactive and has a very complex user interface
with lots of animations and small http requests you would be well served to
use React, vue or this thing.

If your web app doesn't have that, which I imagine the majority do not, don't
use any client side framework at all. Javascript still works, even without a
framework.

~~~
shusson
> Javascript still works, even without a framework

Are you suggesting jquery?

~~~
swlkr
Could be jQuery could be rolling your own set of functions depending on how
far back your users are with their IE versions.

[http://youmightnotneedjquery.com/](http://youmightnotneedjquery.com/)

I guess I should also say you don't need a virtual DOM to make web apps. I
personally like things like turbolinks
([https://github.com/turbolinks/turbolinks](https://github.com/turbolinks/turbolinks))

------
ausjke
the issue is that, for product development, it is really about the whole
package, the ecosystem that is, which includes third-party modules/add-ons,
documents, longevity concerns, road maps, tools around it and so on. one
shining improvement is normally not enough.

~~~
kbr
I agree! Moon has an official router[1], store[2], CLI[3], and an SSR
module[4]. It might not have the biggest community, but that is why I am here
:)

[1] [https://github.com/kbrsh/moon-router](https://github.com/kbrsh/moon-
router)

[2] [https://github.com/kbrsh/monx](https://github.com/kbrsh/monx)

[3] [https://github.com/kbrsh/moon-cli](https://github.com/kbrsh/moon-cli)

[4] [https://github.com/kbrsh/moon-ssr](https://github.com/kbrsh/moon-ssr)

------
sAbakumoff
My comment that said "So far, the Infinite monkey theorem is just giving us an
infinite number of javascript frameworks, and no Shakespeare" acquired 29
points but then has been deleted. Why is it so?

~~~
grzm
It isn't deleted. It's rolled up down thread.

[https://news.ycombinator.com/item?id=15106370](https://news.ycombinator.com/item?id=15106370)

------
sAbakumoff
So far, the Infinite monkey theorem is just giving us an infinite number of
javascript frameworks, and no Shakespeare

~~~
kbr
Honestly, I think libraries are great, if they improve on existing solutions
and actually bring something new. Don't try and stop innovation just for the
sake of having to make less decisions.

Moon's purpose is to provide an API similar to Vue, while being less than half
of the size, and having improved performance in most cases. Why try and stop
something new without giving any valid criticism? If we all have a mindset
like this, the web isn't going to ever improve.

~~~
zzalpha
Well, to be a bit crotchety for a moment: Copying someone else's idea but
doing it a little smaller or faster isn't exactly revolutionary. At this
point, UI libraries are turning into the JS equivalent of programming
languages (everyone is writing one, and few of them are that interesting).

If you really want to improve the web, we're gonna need to think a bigger than
this...

~~~
kbr
It might not be revolutionary, but it _is_ an improvement. I just don't like
when people say they hate something because they don't want to make decisions.
I'd rather have feedback than someone ranting about "just another Javascript
framework".

Moon has the core features of Vue, but it's started going in a different
direction. I'd love any feedback and to hear your thoughts :)

~~~
zzalpha
Well, so first of all, it wasn't a rant, it was a joke and a bit of a jab, and
you gotta admit these days there's good reason for people to be... uhh...
skeptical about yet-another-JS-library.

Second, that reaction isn't about not wanting to "make decisions"... that
simplifies a rather complex set of thoughts and beliefs that are driven by the
often-comical Javascript world, which appears to favour extreme complexity,
constant churn and obsolescence, a near-complete absence of standards or best
practices, duplication of effort, and fragmentation. Of course, the flipside
of this is rapid evolution, competition in a marketplace of ideas, etc, etc.

Third, if you don't want people to see this effort as yet-another-UI-
framework, it'd probably be a good idea to position the project as something
other than "everyone else's good ideas, but smaller and faster" (lightly
paraphrasing from the project landing page)!

~~~
kbr
Yeah, I was just saying my thoughts against the hate towards new JS frameworks
in general. While this reaction was a joke, there are tons of people that
would have been ranting about another Javascript framework.

I am by no means trying to force people to use Moon. Instead, I am trying to
show something that you might want to consider if you use and like Vue, as it
is smaller and faster.

I agree I might need to reposition this project and state a little more. But
I've already clarified why I made this in an article I wrote[1].

[1] [https://hackernoon.com/introducing-
moon-1d44a99635f0](https://hackernoon.com/introducing-moon-1d44a99635f0)

~~~
jacquesm
Was there a specific reason you chose to do a rewrite rather than to improve
vue.js?

~~~
kbr
Yup. Moon is completely different internally than Vue. Submitting a PR to Vue
would require a rewrite of Vue itself, and would change a lot of it.

Moon's goal isn't to have complete API compatibility with Vue, but instead to
have a light alternative with a similar API.

~~~
jacquesm
Fair enough. I take it that you weighed the cost of fragmentation versus the
advantage that a rewrite would give you. Even so, it feels to me - as an
outsider, without having looked in depth at either code base - that it might
have been better to see how far you could have pushed vue.js with respect to
your improvements before deciding to roll your own. After all, now you are
comparing apples with oranges, many of your improvements likely would have
applied to vue.js as well and then the difference between your offering and
theirs would have been a lot smaller, possibly small enough not to justify a
for and yet another incompatible API.

These are hard decisions.

------
roadbeats
Nice work! What did you use for building the documentation ?

~~~
kbr
Thanks! I created a static site generator called Sold [1]. The Moon
configuration for Sold is available at the gh-pages branch [2].

[1] [https://github.com/kbrsh/sold](https://github.com/kbrsh/sold)

[2] [https://github.com/kbrsh/moon/tree/gh-
pages](https://github.com/kbrsh/moon/tree/gh-pages)

~~~
kristofferc
FWIW, I'm having extreme troubles reading the docs at
[http://moonjs.ga/docs/overview.html](http://moonjs.ga/docs/overview.html).
The text is almost the same as the background for me.

~~~
kbr
Sorry about that! I just updated the font-weight and colors. There should be
more contrast now.

~~~
kristofferc
Yes, much better, thank you! Perhaps the menu to the left could get the same
treatment? :)

------
desireco42
You know what? All this is good, but it repaints the whole screen between
states/pages.

And one more thing. Just use Elm and live happily ever after.

I welcome new js framework. Seriously.

------
jszymborski
Cool... looks like Mithril:React;Moon:Vue, as they're only 1kb different.
Wonder if Moon also benefits from low-latency like Mithril does.

------
Walkman
[https://dayssincelastjavascriptframework.com](https://dayssincelastjavascriptframework.com)

------
SeriousM
So moon is the alternative to vue which is the alternative to angular(ui
engine)/react... Oh dear... How those frameworks want to get used in a wider
manner when they place themselves in a 10% of 10% of 30% of the market
segment?

~~~
jacquesm
It's a good thing that writing an OS is a bit more complex or we'd have seen a
huge fragmentation of that space too.

What's bugging me is that most JS work would have probably been better off as
an improvement on something existing.

~~~
always_good
And your time commenting would be better spent doing pushups. But that's not
really how motivation and interest work.

~~~
jacquesm
But I _also_ do push-ups. See, it is rarely an either-or proposition. One
could push vue.js to the limit and _then_ decide to do a rewrite. But to take
the rewrite option as the first available exit whilst explicitly referring to
the original is fragmentation where I wonder if it is actually needed.

~~~
always_good
Well, it _is_ either-or. All time spent has an opportunity cost. Just doesn't
strike me as an argument. Nothing is needed, and need doesn't describe why
most software exists.

These sorts of comments amount to judging how others spend their time. It's
just as silly to me as me suggesting that you spend your time credentializing
in React so you can improve it for free.

I'd say there's plenty of value to offer the world by creating alternative
projects that stand on their own, experimenting with different approaches.

~~~
jacquesm
Well, we're going to have to disagree on that. I feel that a lot of the
fragmentation in open source is due to the fact that it sounds good to be the
maintainer of some project, the fact that github presence is now considered a
factor in getting hired certainly contributes to that.

Fragmentation - without sufficient forethought - is not cost free and 'more
wood behind fewer arrows' works both for commercial entities _and_ for open
source.

Most of these 'alternative projects that stand on their own' are announced
with great fanfare and die a silent death a few months later, the same effort
spent on improving what is already out there would go a much longer distance.

Obviously everybody is entirely free to spend their time in whatever way they
want.

------
G4BB3R
Seems nice for Js devs, but I prefer Elm :)

------
webreac
If it is smaller, is it easier to learn?

------
kingwill101
Oh look a new JavaScript framework

------
rajington
so preact for vue? how is this not called prevue?

------
korzun
Technically, one can pull down any mature framework, decouple all of the
features into smaller segments, get rid of all the code responsible for
backward compatibility, and re-brand it as 'lighter' alternative.

How is this any different? You can't claim that X is better or faster than Y
just because X is smaller or has fewer features. There are a lot of other
factors in play here.

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

~~~
kbr
I'd love to know why you think Moon is ridiculous, so I can try to improve it.
I honestly think what you're doing here is really ridiculous, try and give
some feedback instead.

Edit: Sorry, I misunderstood your comment. I interpreted your comment as
saying all of these new frameworks are making things ridiculous. This implies
that Moon is contributing to that, and I'd rather have feedback.

~~~
smegel
Your English comprehension is really bad. How's that for some feedback?

~~~
dang
Incivility and acerbic swipes will get you banned here. You've done this many
times on HN, unfortunately. Would you please fix this? Among other things, it
sets the wrong example for the less laconic.

