Show HN: Moon – 3kb JavaScript UI compiler | Hacker News Reader

Show HN: Moon – 3kb JavaScript UI compiler

kbrsh.github.io

71 pointskbr50 comments

This looks like it takes Vue.js's approach of creating a brand new language that you have to learn (in this case MVL which is similar to HTML). It's definitely a preference for a lot of people, but I prefer React.js style, which lets you use languages you already know (HTML and JavaScript) to do literally everything. It may be inconvenient at times, but you don't have to reference a new language's manual every time you want to do a for-loop to figure out whether the @for attribute should go on the li or the ul.

It's definitely based on preference, but I designed MVL to be as simple and consistent as possible. For example, there are two ways to create a for loop (one on the ul and one on the li).

  <For={item in items}>
    <!-- multiple elements -->
  </For>

  <p For={item in items}><!-- single element --></p>

This syntax works for every component ("For" is just another component).

That is awesome that you have <For>! That's one of my biggest pet peeves with Vue.js, where it has to be an attribute on an element, and it's not intuitive whether it goes on the parent or the child. (I think Vue makes it go on the parent but I think it makes more sense for it to go on the child.)

IIRC for Vue.js it goes on the child, i.e.

    <ul>
      <li v-for="item in items">[...]</li>
    </ul>

It is something you do have to remember. I believe you can use a template tag too if you like.

Ah right, thanks. Yes this always looks backwards to me. The body of a loop should be inside of it. But here it is the body of the loop. That is very strange.

> I prefer React.js style, which lets you use languages you already know (HTML and JavaScript)

No, you also have to relearn, just not as much. The React docs rightly state "JSX is not HTML" because you cannot use comments, doctype and it's a shame that JSX deviates from HTML in attribute names. Having to use className instead of class annoys me to no end and is why I prefer preact (they use class). Also autoComplete and spellCheck - just why? Converting this-that to thisThat makes sense but renaming attributes without necessity was a stupid decision.

You really should check out lit-html. The JavaScript parts are real JavaScript, and the HTML parts (in JS template literals) are real HTML.

With a good IDE that suggests these as you type, it shouldn't matter. I recommend VS Code, it does this out of the box. I like how it even suggests the right thing if I get the letters a little mixed up, like typing "speclh" suggests spellCheck={...} for me. It's great!

is it weird that i prefer vim rather than fancy IDE for almost everything?

let { class } = this.props

Class is a reserved word. This is why they stuck with the dom attribute names. Because it is JS, not html :)

It works very well with preact so it obviously is possible. edit: And while you pass it often as a prop (<a class=...>) you usually never access it yourself in components - and if you do, just do `this.props['class']`.

A lot of my components contain something like this line: const Comp = ({children, className}) => {}.

If you need to merge it with some statically applied class names in your component you need to access it. This is an absolutely common thing. It would be terrible if i'd need to access it by using a string. And even then I would need to assign it to a name other then "class" which makes it even more confusing then naming it "className" by convention.

It's not all that annoying, tbh. At least there's a reason - those names are actual DOM names, right? Slightly annoying is to have a react function HAVE TO start with a capital case and use CamelCase.

I was annoyed with it too, but I read the developers reasoning for it and it makes sense. They didn't substitute "auto-correct" with "autoCorrect" for the hell of it, "autoCorrect" is actually the attribute in the JS DOM API.

So if you imagine that it's going through performing a document.createElement() call for each node then setting attributes then it makes sense. The only alternative is to maintain a list of mappings from HTML attribute to JS DOM attribute as part of the library, which would be a waste of bandwidth and irritating to maintain. The real problem is that JSX looks like HTML but is not describing HTML.

> it's a shame that JSX deviates from HTML in attribute names.

Actually, that's a React issue, not a JSX one.

JSX is attribute agnostic. You can use it with another view library like Mithril and not worry about those shenanigans (class, autocomplete and spellcheck will work out of the box).

React is quite consistent in naming things and if you write 100's of components (which you should easily accomplish if you use it seriously) then you will never mix up className and class. In fact almost everything in react is camel case which is also the most commonly used style for naming variables in javascript. This makes it very comfortable to create objects from variable names and spread it as props. It really did never annoy me at all (Maybe the first 10 components I wrote :D )

Also if you use a sophisticated IDE that shouldn't be an annoyance at all.

Yeah, this is a big reason why the Polymer project is moving away from a bespoke expression syntax and control-flow in HTML, ala Angular and Vue, to using just JavaScript with lit-html.

But not only does it mean that users don't have to learn a new language and concepts, but it mean the maintainers don't have to develop a new language and all the corner cases, feature requests and bugs that come with it.

And in the case of lit-html, you also eliminate compilers completely because there's also no non-standard markup-in-JS syntax.

There is handlebar, you can use it with Glimmer.js. It is still the fastest and future proof with WebAssembly.

How does this compare to Svelte, which also compiles itself away and at first glance, looks quite similar? What was your motivation for making this? (other than making something cool, ofc)

What do you mean by "compiles itself away"?

No runtime gets included in the build.

How are variables in "<p>{text}</p>" replaced? Is the security of it just an implementation detail left to the programmer who use it? Safe way would be finding the P and then doing p.textContent = data. But how do you find element by value efficiently? Or do you just to text replace?

Your views are compiled down to JavaScript beforehand. Your example would be compiled to something like:

  m2.textContent = instance.text;

Use Moon.compile(template) to get a better idea of outputs.

I continue to advocate MarkoJS as "the best" HTML templating language. https://markojs.com

It is the best mix of expressiveness, ease, and clarity I've found.

I believe Angular has a similar mechanism of compiling templates to code that corresponds directly to the template much like this, and they're now backing away from it. The reason is that you end up with a lot of code per template. Some indirection, like stuffing the template parameters via a key-value map, lets you generate more generic code that is overall smaller.

To prevent large bundles, Moon uses a lightweight runtime that is about the same size as the equivalent compiled virtual DOM render function (using React.createElement for example).

Maybe it's just me but if you're submitting something to Show HN then it's helpful if your "Examples" navbar link doesn't send me to a `//TODO`!

That’s a ToDo app example

Previous (2017, 192 comments): https://news.ycombinator.com/item?id=15105726

It's been rewritten completely and hit 1.0 beta a week ago :)

Looks like a neat project. What is the ultimate goal of it? I gather it's to do a subset of what e.g. Vue does, with simplified API and a small footprint. Is that accurate?

Thanks! It used to be a smaller version of Vue aiming to be a small subset of it. For the v1 beta (what the current documentation is for) I decided to change up the API to be something more simple that can still scale well for larger projects.

Is this still a non-keyed implementation? Will you ever be adding mix-ins? Both of these kept me from using this library prior to the current re-write.

For now, it is non-keyed. As I mentioned in some other comments I just wanted to get a beta out as I've been rewriting Moon for about a year and it's finally gotten to a semi-usable state.

A keyed implementation, single-file components (multi-file components exist with Moon CLI but I've started to like single-file components), custom DOM events, component inserts, and an official router are on my todo list. Hopefully you'll get to use the library this time :)

Very simple concepts. So easy to try. Saw the code. There are almost no type checks or null/undefined checks anywhere. Is this library used in any production application?

It’s currently in beta and although that’s no excuse for the lack of warnings I just wanted to get a beta out as I started v1 almost a year ago.

I kind of like that this feels like a vanilla JS, simple version of components. Any reasoning behind by this was created? I read the about but it was limited.

Glad you liked it. If you read some of the original Moon articles (“Introducing Moon”) you’ll find that I was frustrated with other libraries and strived to create a smaller and faster alternative.

Now I have worked on designing a new structure for web applications that I’m planning on writing further about. The view API of components in Moon closely models my vision for the future of the web. Moon’s philosophy is to have a consistent API in order to create views to display data.

I do like that you have presentation vs data separated by default. Something I wish React had. ;)

ps You should submit Moon to sites like these: http://todomvc.com/

Congratulations on the release. I know we talked about using Moon for AppShare, and I'll keep watching the progress. Thanks

Love the design of the site (or lack of it). Apparently similar to marko.js, but no bootstrap header, etc.

Looks to be the Wing css framework, by the same author:

https://kbrsh.github.io/wing/

Are you still claiming to be 14 years old?

This is what you do with your precious time on this planet?

10 months ago they apparently registered their account to cast doubt that OP was 13 years old.

A weird fixation.

OP was the one trying to convice everyone. https://news.ycombinator.com/item?id=15156363

is he not?

He created a fake account to publish his "look at me, I'm 13" tweets.

https://news.ycombinator.com/item?id=15156363

If he's 14, then he's pretty much an attention needing dude (as he submitted this moon library at least 5 times and his "I'm 13 yo" tweets at least 3 times). At the same time, he claims that he does not like to mention his age.

He's 14, give him a break, I was like that at one point until I actually figured out what 'not mentioning your age' meant (hint: pretending to be coy was not it).

Reply on news.ycombinator.com