Hacker News Reader

Comment by novocantico | Hacker News Reader

Thanks for taking some interest in my project. It came from being frustrated with the state of SSGs over the past 10 years. I mostly just make static websites, and I wanted something that was simple and intuitive to me, and JSX seemed like a great fit. But I got very tired of the disproportionately scaled complexity of JSX frameworks like React. Long story short, I made an SSG that just renders JSX as strings. It was natural to extend that to the browser to just render JSX as DOM elements. And in a few cases (mostly layout) it lends well to shared components. Overall I'm happy with what I came up with, although some of it is admittedly a little hacky, and IDE support isn't as good as it could be.

[edit] Oh also, this solution works really well for SEO. That's another problem I didn't find solved well in other JSX frameworks.

View on HN

Just curious, have you seen Astro? I feel like it's the perfect SSG, but maybe you have some reservations that VanillaJSX solves.

I'm a big fan of Astro, though I could see it being a bit more of an adjustment for JSX users than Svelte users since Astro's syntax was originally based on Svelte.

That said, JSX can be used easily with Astro as long as you get used to at least a bit of The `.astro` syntax for wrapper components and pages/layouts.

For all "have you tried ___" questions, the answer is the same. I've been trying all these new techs for the past 10-15 years, regularly, as soon as they come out, for the first few years with much with excitement, and later with disillusionment and less regularity.

Another user below said

> We've recently moved one service from next to Astro and it was just removing a ton of boilerplate and 'dance around' code.

And I get why it happens. When you first try out a new framework, you allow yourself to learn and add its inherent complexity, knowingly and intentionally. You say to yourself, "it's part of the dream, it's going to work out; there's a vision, just trust the process." This is true with literally all frameworks.

But they never deliver. The complexity is never worth it, and in the end, the intentionally added complexity is always intentionally and gladly removed when it becomes clear that it was unnecessary complexity. This is what I am glad to have learned so thoroughly that I no longer try to learn new frameworks when I initially see its complexity, imagine adopting it in view of my experience, and recognize that its almost always not worth it.

Look at the code on vanillajsx.com. Besides JSX and types, it's plain JavaScript and DOM manipulation. Translating it to document.createElement would add almost no lines of code. There's no unnecessary complexity. That's the whole point of the site. The simplicity of discovering and removing unnecessary complexity is wonderful and refreshing, and I think a lot of people agree.

I think you're misunderstanding the poster you quoted. They're indicating a positive experience with Astro.

> We've recently moved one service from next to Astro and it was just removing a ton of boilerplate and 'dance around' code.

---

> And I get why it happens. When you first try out a new framework, you allow yourself to learn and add its inherent complexity, knowingly and intentionally. You say to yourself, "it's part of the dream, it's going to work out; there's a vision, just trust the process." This is true with literally all frameworks.

I am quite picky and have strong opinions. I've used Astro for more than a year and still love it. There is complexity (especially if you use SSR), but for the use case of "I just want a static site" it is wonderful.

> Look at the code on vanillajsx.com. Besides JSX and types, it's plain JavaScript and DOM manipulation. Translating it to document.createElement would add almost no lines of code. There's no unnecessary complexity. That's the whole point of the site. The simplicity of discovering and removing unnecessary complexity is wonderful and refreshing, and I think a lot of people agree.

I don't disagree, but this doesn't replace what you might want for SSG. For one, this requires JS on the client. Astro compiles to static HTML despite using JSX-like syntax.

As an example, here's my Astro site and source code:

* https://sjer.red/

* https://github.com/shepherdjerred/sjer.red

My framework (imlib[1]) is actually more of a framework akin to Astro than what's showcased on vanillajsx.com, which itself is built with imlib.

It just runs your code in a node.js process, and translates your JSX expressions into jsx() calls. On the node.js side[2], jsx() returns a string from its tag/attrs/children. On the browser side[3], jsx() returns DOM elements.

Combined with a little bit of architecture, it becomes something extremely well suited to creating static sites. I guess SSG is an outdated term now, maybe it's a framework? Or a platform?

In any case, it seems to do something similar to Astro, but in a significantly simpler way. The only "bundle" it needs in the browser is /@imlib/jsx-browser.js [4] which in itself is just jsx-dom.ts (its impl is overridable by the "framework" user). And on the node.js side, it's implemented as a very small "vm" of sorts [5].

I'm not against Astro, I just get all the same benefit people here are saying Astro has, but with orders of magnitude more simplicity imo.

I've used imlib to make a relatively large website [6], in fact imlib was developed as this website and extracted from it over the past year. I have absolutely no difficulty breaking down my site into various reusable and encapsulated JSX components, both on the ssg-side and the browser-side. Development time is lightning fast. IDE support is essentially automatic. The site loads instantaneously in the static parts, and as quickly as reasonable in the dynamic parts.

[1] https://github.com/sdegutis/imlib

[2] https://github.com/sdegutis/imlib/blob/main/src/jsx-strings....

[3] https://github.com/sdegutis/imlib/blob/main/src/jsx-dom.ts

[4] https://vanillajsx.com/@imlib/jsx-browser.js

[5] https://github.com/sdegutis/imlib/blob/main/src/runtime.ts

[6] https://github.com/sdegutis/immaculatalibrary.com

Thanks for taking the time to clarify & not getting hostile :)

I'll look into imlib a little more.

I like your thinking. Things have gotten far more complex than they need to be. We've been piling abstractions on top of abstractions for too long and there needs to be a culling. If we get rid something that we really did need, that's better than the alternative. It's best now to ditch it all and see what we really need.

So, I take it you haven't tried Astro then?

SSG?

Static site generator, apparently

astro is nearly, if not as, "complex" as react, no?

As person who has been doing “react” since 2016 I would say that it removes so much of the “react” complex BS that I am surprised it is not x100 times more popular.

We’ve recently moved one service from next to Astro and it was just removing a ton of boilerplate and “dance around” code.

That’s how I felt going from Astro to Sveltekit, but that’s a shorter distance to travel.

Oh, but you are moving out of React. And svelto IMO is waaay friendlier and "sane" than "typical" react. Svelte reactive model (observables and computed) are very friendly and simple to use.

It doesn't really make sense to compare React to a static site generator.

Love the idea. FYI, on your demo page, the todo app is 404. And you might want to spell out static site generator instead of saying "SSG" on your docs. I didn't know what SSG was, even though I've used static site generators. I had to ask the AI.

A JSX for Django server side would be cool.

Not exactly JSX, but I came across a package django-cotton[https://github.com/wrabit/django-cotton], that is html syntax first components.

How would you envision this working?

not the hero we deserve but the villain we need

Have you looked into lit-html?

Coming from Vue I was really surprised it does a lot of what Vue templating does, including attaching events, with just vanilla JS templates. And when you use VSCode lit extension, you get syntax highlighting and full type checking inside the templates.

I learned about lit-html after a tweet from Marc Grabanski, where he said he used lit-html with vanillajs, not Lit.

After some experimenting I found it works great and it seems like you are trying to solve something very similar.

When you use the lit-html template package you can do basically evetything that is described in the Templates chapter

https://lit.dev/docs/templates/overview/

... without all the other abstraction of components that are part of lit-element.

https://lit.dev/docs/libraries/standalone-templates/#renderi...

Large WASM payload on your site could be optimized.

What I’m seeing here is not new. It’s this vanilla pattern but with enough back support to leave off the framing and get the syntax highlighting:

Var button = html(’<button>im a button</button>’);

The html() function is trivial, but it just doesn’t feel like real programming to do this, even though there’s nothing else to it in the end.

Tagged template literals for html view templating is what I LOVE about Lit and lit-html. It’s JavaScript you can run natively in browser, no server or pre processor/build step necessary.

Downvote me but tell me why. The example is using .onclick, .textContent, etc in a completely vanilla way. I'm just pointing out you can get all the way vanilla and it still works. What's the issue?

lolinder explained it well in here

He did, and he pointed out the point is just IDE support so it has typing and autocomplete and syntax highlighting. Thanks, we agree!

Reply on news.ycombinator.com