14 ms·
Show HN: Moon – fast 7k Vue alternative
- deleted 9y ago[deleted]
- pspeter3 9y agoHow does Moon automatically detect static virtual nodes? What makes Moon faster than the alternatives? Finally, how does Moon avoid GC pressure with large trees?
- nickthemagicman 9y agoif(virtual_node.type == static){do stuff;} Super easy.
- pspeter3 9y agoSo developers mark it manually?
- kbr 9y agoNo, that comment was a joke. (A really bad one). Moon's compiler will do all of the work.
- nickthemagicman 9y agoIt was a good joke.
- kbr 9y agoThe 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 9y ago> 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/baredom/impl/Dom.js https://github.com/vandenoever/baredom/blob/master/src/bared...
- pspeter3 9y agoThanks, I'll have to check this out!
- kbr 9y agoThis is really cool! I'll definitely look into this and apply some of it to Moon.
- oever 9y agoBareDOM 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 9y agoIs there any documentation on why to use a typed array
- yorwba 9y agoTyped 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.
- 9y ago
- mlevental 9y agoyes but wait until there's a 6kb moon alternative
- roadbeats 9y agoNice work! What did you use for building the documentation ?
- kbr 9y agoThanks! 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 9y agoFWIW, 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 9y agoSorry about that! I just updated the font-weight and colors. There should be more contrast now.
- kristofferc 9y agoYes, much better, thank you! Perhaps the menu to the left could get the same treatment? :)
- sscarduzio 9y agoYou say it's faster than Vue, but how much, how did you measure?
- kbr 9y agoMoon 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/webdriver-ts-results/table.html https://rawgit.com/krausest/js-framework-benchmark/master/we... [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
- gedy 9y agoLooks like nice work, also reminds me of Ractive (https://ractive.js.org https://ractive.js.org)
- fny 9y agoIf 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 9y agocareful now... all frameworks are blazing fast, but some are more blazing fast than others. https://rawgit.com/krausest/js-framework-benchmark/master/webdriver-ts-results/table.html https://rawgit.com/krausest/js-framework-benchmark/master/we...
- pkstn 9y agoyup, and non-keyed is the easiest part :)
- leeoniya 9y agoindeed, 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#issuecomment-315480911 https://github.com/krausest/js-framework-benchmark/pull/212#...
- pkstn 9y agoI believe so too!
- lucisferre 9y agoThe 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 9y agoSorry 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
- sAbakumoff 9y agoSo far, the Infinite monkey theorem is just giving us an infinite number of javascript frameworks, and no Shakespeare
- zzalpha 9y agoTruly, in the JS world, it is the best of times, it is the blurst of times...
- kbr 9y agoHonestly, 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.
- sAbakumoff 9y agoHey it's just a joke, take it easy. I didn't mean to discourage the work of OP in any way.
- agumonkey 9y agoI guess that's where a bit of "static type" would make it easier. Different framework could explicitely back themselves against an API. With js, it's all implicit.
- SeriousM 9y agoSo 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 9y agoIt'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 9y agoAnd your time commenting would be better spent doing pushups. But that's not really how motivation and interest work.
- jacquesm 9y agoBut 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 9y agoWell, 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.
- 9y ago
- ausjke 9y agothe 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 9y agoI 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
- jcoffland 9y agoThe 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.
- samuelantonioli 9y agoI'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 9y agoAwesome, 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 9y agoThanks 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.
- smegel 9y agoCan 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.
- leeoniya 9y agobrowser 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.
- spankalee 9y agoOver in Polymer, we're exploring ways to do exactly that: https://github.com/PolymerLabs/lit-html 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 <template> elements let us stamp out pre-defined trees of DOM quickly. Combined we can then only update the dynamic parts without a virtual DOM.
- leeoniya 9y agowere you aware of https://github.com/trueadm/t7 https://github.com/trueadm/t7 when you started? are there advantages over t7, other than NIH?
- spankalee 9y agoT7 is quite a bit larger than lit-html, and requires a vdom reconciler still. lit-html is self-contained and < 2k minified and gzipped. I also didn't want to use vdom because it doesn't encode whether nodes are static or dynamic, and even static sections are diffed. That's extremely important feature for performance and memory overhead, which is why I'm happy to see that emphasized in Moon. Also, coming from the Polymer team, where we've had a lot of success using <template> elements to stamp out large pre-defined DOM trees, I wanted a system backed by those.
- sockopen 9y agoThe 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 9y agoSorry! It looks like I haven't updated some parts of the site. The correct size is 7kb, thanks for pointing that out.
- nkkollaw 9y agoLooks 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 9y agoIt'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.
- coldtea 9y ago>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.
- leeoniya 9y agoit'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 https://twitter.com/HenriHelvetica/status/877924754195324928
- albedoa 9y agoEven 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.
- leeoniya 9y agotrue. i guess the point of the comment was that you can't compare loading an image to loading & executing a script by filesize.
- iansowinski 9y agoSo we are here. It didn't took so long for vue to go from "will vue be new react ?" To "vuejs alternative".
- hashbig 9y agoIsn't it a fun time to be a front-end developer?
- baybal2 9y ago>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.
- meandmycode 9y agoCan 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..
- eterm 9y agoMy perspective is this: A lot of people got a lot of productive work done 'hacking' together jquery and jquery-ui scripts. The result wasn't pretty and was a bit of a maintenance nightmare. They are not only a bit of alienated by having to work with frameworks, but they're expected to be as productive with these frameworks as they were hacking together jquery scripts and snippets, but are still the 1-man or 2-man developers within a wider business. These frameworks are great in a business built around the web such as a SAAS business, but a lot of people are in businesses where their saas part is secondary, or are trying to maintain sites which just aren't the main product of the business. They're pressured by well meaning but often misguided higher-ups to use the latest and greatest and feel the pressure of churn.
- factsaresacred 9y agoCongrats 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 9y agoThank 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 9y agoNot 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 9y agoWorking 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 9y agoIs that supposed to be good news?
- webreac 9y agoIf it is smaller, is it easier to learn?
- sametmax 9y agoCan 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 ?
- anon764587 9y agoI'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 9y agoJust 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.)
- swlkr 9y agoIf 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 9y ago> Javascript still works, even without a framework Are you suggesting jquery?
- swlkr 9y agoCould 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)
- sAbakumoff 9y agoMy 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 9y agoIt isn't deleted. It's rolled up down thread. https://news.ycombinator.com/item?id=15106370 https://news.ycombinator.com/item?id=15106370
- kingwill101 9y agoOh look a new JavaScript framework
- cdevs 9y agoI 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.
- desireco42 9y agoYou 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.
- maxscam 9y agoI 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.
- jszymborski 9y agoCool... looks like Mithril:React;Moon:Vue, as they're only 1kb different. Wonder if Moon also benefits from low-latency like Mithril does.
- rajington 9y agoso preact for vue? how is this not called prevue?
- Walkman 9y agohttps://dayssincelastjavascriptframework.com https://dayssincelastjavascriptframework.com
- G4BB3R 9y agoSeems nice for Js devs, but I prefer Elm :)
- korzun 9y agoTechnically, 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.