Live data from Hacker News

UnsuckJS: Progressively enhance HTML with lightweight JavaScript libraries

unsuckjs.com

21–30 of 194 posts

Re: UnsuckJS: Progressively enhance HTML with lightweight JavaScript libraries

#21

The bottom row of the table is "IE11 Compatible". ...IE11 hasn't been relevant on the public-web for at least a decade now, and I'm fairly sure it's now entirely gone from corporate/enterprise situations now too, given MS' even-more-aggressive-than-usual campaign to kill it off in Feburary of this year: https://www.cnet.com/tech/services-and-software/rip-internet... ...why is that there? It's weird - it's like saying…

Not true. There are still legacy use cases where IE11 is required for support in enterprise and regulated businesses. Ending soon? Hopefully. But not gone.

Re: UnsuckJS: Progressively enhance HTML with lightweight JavaScript libraries

#22

I can do the same thing via NextJS and output pure HTML and CSS without any JS at all. Or with server components, output only the minimal JS needed. Not sure why everyone wants to write a programming language inside HTML like lit does.

A fresh install of NextJS is roughly 150MB. You realise that's mostly code that all needs to work right?

Re: UnsuckJS: Progressively enhance HTML with lightweight JavaScript libraries

#24

Earlier quoted context omitted.

The king of "use JS frameworks, output pure HTML" is Astro. ( https://astro.build/ ) It's basically an SSG where you can use a number of frameworks to write your components, and shipping any JS is explicitly opt-in.

Why Astro instead of say, Svelte?

Astro is a metaframework that among others can use Svelte for both static and interactive components. Plain Svelte without a metaframework is not suitable for normal websites with multiple pages, but Astro is.

As for Astro vs SvelteKit, I generally prefer Astro's approach to filesystem based routing (no +page etc.), I prefer it's MPA approach to the clientside routing SvelteKit and others use OOTB, I like that it's very tailored towards content and being an SSG (content collections, MD and MDX support ootb, currently experimental automatic image optimization), and the "integrations" are a huge time-saver. Some common ones you can add with `astro add`, and many others are just a quick config edit away. I recently built a pretty performant portfolio site with Astro in a single day using DecapCMS and UnoCSS, both as integrations, all the client had to do was accept the invite from Netlify Identity and start adding content to their site!

Re: UnsuckJS: Progressively enhance HTML with lightweight JavaScript libraries

#25

This is a brilliant list, I'm a particular fan of HTMX and Alpine.js. The move back towards small dependancy free JS libs, in combination with modern JS ES Modules, is absolutely brilliant. I learnt web dev back in the late 90s by doing "view source", and was still learning about new things that way well over a decade later. If we can move back towards that, by not having a build step, it will be amazing for new devs…

> I learnt web dev back in the late 90s by doing "view source", and was still learning about new things that way well over a decade later. If we can move back towards that, by not having a build step, it will be amazing for new devs starting out and learning new things.

Same here, and I couldn't agree more. Had minified library soup with dynamic page content been the norm back then it would've been much harder to get started, and there's a high chance I would've just given up somewhere in the process.

Having a build step also increases activation energy and friction which impedes the sort of in-the-moment tinkering that often sparks projects.

Re: UnsuckJS: Progressively enhance HTML with lightweight JavaScript libraries

#26

Earlier quoted context omitted.

The king of "use JS frameworks, output pure HTML" is Astro. ( https://astro.build/ ) It's basically an SSG where you can use a number of frameworks to write your components, and shipping any JS is explicitly opt-in.

Why Astro instead of say, Svelte?

No advantage if you just want to use Svelte when SvelteKit does everything Astro does and more while having less dependencies.

Re: UnsuckJS: Progressively enhance HTML with lightweight JavaScript libraries

#27

Earlier quoted context omitted.

Yes! I don't think Mithril gets enough attention. It's my go to JS framework when I need more than Vanilla JS but don't need something like React.

Why would you ever need React over Mithril?

Colleagues, ecosystem

Re: UnsuckJS: Progressively enhance HTML with lightweight JavaScript libraries

#28

Earlier quoted context omitted.

Why Astro instead of say, Svelte?

No advantage if you just want to use Svelte when SvelteKit does everything Astro does and more while having less dependencies.

Well, dependency count is not the metric on which I base my tech decisions on. After all, you could do everything Svelte does with VanillaJS.

I just prefer the DX of Astro and MPA routing instead of client-side.

Re: UnsuckJS: Progressively enhance HTML with lightweight JavaScript libraries

#29
post #5

You can do a lot with Django templates. Sprinkle in any of these and I find it unlikely you'll be reaching for React. Although if you have lots of React experience I am a believer in "use what you know". Tool familiarity > trimming dependencies

Django templates are nice, but fall flat if you want to do anything remotely dynamic with your model. The fact that you need to define custom template tags for things as simple as getting an attribute from a dict in your model is a real pain point.

Re: UnsuckJS: Progressively enhance HTML with lightweight JavaScript libraries

#30

I can do the same thing via NextJS and output pure HTML and CSS without any JS at all. Or with server components, output only the minimal JS needed. Not sure why everyone wants to write a programming language inside HTML like lit does.

A fresh install of NextJS is roughly 150MB. You realise that's mostly code that all needs to work right?

That's all on the backend so it doesn't really matter to me as long as no JS is sent on the frontend. For the benefits NextJS gives me, like TypeScript, I'm fine with that.
Post reply on HN