Hacker News Reader

Comment by mozey | Hacker News Reader

> by wrapping a vanilla lib to a component or an action, you’ve essentially created basic Svelte version of that lib

This is the key to making framework churn go away. The DX of using vanilla JavaScript is getting better every day. And is a much better experience than it was a decade ago.

> Islands architecture and partial hydration can help you render static HTML with just a small portion of JavaScript for those components who need it

I'm doing this with Hugo for rendering the static parts, and htmx for loading hydrated partials. The HATEOAS approach simplifies state management in the application. There is no client side "routing", just links and the back button.

In addition to vanilla libs, I include one "app.js" bundle. This file is created with esbuild and linted with deno. My "business logic" can be written in TypeScript in VSCode with the Deno extension and LSP server.

View on HN

This is all fun and games until you work on a platform that requires dynamically loaded modules, error boundaries and suspense (or another form of components loading their own data) and then the no-nonsense approach falls flat.

It is easy to put your nose up towards bloated frameworks when you’re doing small (static) stuff but as soon as you need the bloat you’re just reinventing a wobbly wheel without one.

There’s always an air of disdain against front end frameworks on HN but people often project their own not-needing-a-framework on the tool itself.

I work on a huge angular project and I can’t help but see svelte as a toy in comparison. Must be nice when everything just falls into place.

What are you missing in Svelte?

Maybe it's because angular is like dropping a nuke to kill a spider?

That comparison makes assumptions about the size of the problem OP is dealing with. What makes you think it's spider-sized?

The point is more that a nuke is unnecessary in any case.

> dynamically loaded modules, error boundaries

In an MPA, modules https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guid... can be included on the pages that require them with a script tag. Errors (and new features) are limited to a specific page, and the rest of the site remains unchanged.

> suspense (or another form of components loading their own data)

The htmx lib https://htmx.org/ mostly takes care of this: "gives you access to AJAX, CSS Transitions, WebSockets and Server Sent Events directly in HTML". The hx-boost tag can also be used for progressive enhancement.

> as soon as you need the bloat you’re just reinventing a wobbly wheel without one

When building a rich client, using a framework could be productive. For example a photo/video editor app. For a news site and CMS I would probably stick to the approach I've described above.

doesn't the csp issue in htmx basically make it a non-starter for most applications? maybe that's been fixed somehow..

The hx-disable attribute can be used to disable htmx for parts of the DOM that load user generated content, is that what you're referring to? https://htmx.org/docs/#security

Reply on news.ycombinator.com