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.

Astro is pretty nice too, I was going to write my blog with it but I liked the instant page transitions that NextJS provides out of the box for which I couldn't find a suitable solution in Astro.

Astro is adding (optional) client-side routing. I’m excited about that.

Doesn’t NextJS do that with client-side JS though?

I recently moved from Gatsby, which did that — and the transitions sure are instantaneous — to Astro, which outputs plain HTML pages. Each navigation is a request to the server. Yeah, they take a touch longer. But the response is tiny.

You could always `preload`?

I tried preload, it doesn't work as well as with NextJS which, yes, uses client side JS. But critically, the pages still work without JS if one so chooses. It's progressive enhancement which Astro does not yet have.

Could you explain a bit what you do like/don't like about Gatsby compared to Astro?

I used to use Gatsby, but the non standard plugin system as well as forcing GraphQL (I use GQL in my own projects but it's just not necessary for a blog site for example, which Gatsby markets itself as being for) put me off Gatsby and onto NextJS, especially when NextJS introduced their static site rendering features. Now with server components, there doesn't seem to be a real need to use Gatsby anymore.

Gatsby felt like it had grown in to a monster. Astro was a lot simpler which suits my needs and, frankly, skill.

I worry that Astro is adding too many features and trying to become Gatsby. No thanks!

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!

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.

How is Lit's use of JS in templates any different than JSX? Both use JS for expressions and control-flow.

JSX is expensive than JS, because JSX first needs to become JS, then other things happen

That doesn't speak to this comment:

> Not sure why everyone wants to write a programming language inside HTML like lit does

When that's exactly what the OP's suggestion of React does.

There are a bunch of server side apps that turn JSX into static HTML with no JS. It’s just a template language that compiles into JS but you can do anything with it you could do with other template languages.

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.

In that case why not just SSR lit on the backend and send that? It sounds like an unfair criticism otherwise

It's easy to add interactivity to a NextJS site when you need it.

Likewise with Lit, but that is besides the criticism that he was making earlier

I have the full React framework and ecosystem if I so choose to use it. For example, I could use something like react-three-fiber to add 3D or Framer Motion to add animations yet fall back to not having those when JS is disabled. Sure you could do the same in Lit but those libraries aren't present or as robust as in React.

NextJS sends all JS to the frontend even if it's static and server rendered. It renders once on the server, sends a React+JS bundle to the client, and re-renders the whole page on the client (which is exactly the same). As far as I could tell, there's no mechanism for Next.JS to say "this isn't dynamic" and send only HTML content. If there's a setting I missed, feel free to let me know.

> It renders once on the server, sends a React+JS bundle to the client, and re-renders the whole page on the client (which is exactly the same)

The new paradigm in Next.js is to have "server components" by default, which only render static HTML on the server side; and opt-in to "client components", which render on both server and client.

> With Server Components, the initial page load is faster, and the client-side JavaScript bundle size is reduced. The base client-side runtime is cacheable and predictable in size, and does not increase as your application grows. Additional JavaScript is only added as client-side interactivity is used in your application through Client Components.

https://nextjs.org/docs/getting-started/react-essentials#ser...

Next doesn't ship 150MB of JavaScript to browsers...

An installation of chrome is roughly 1,500mb. You realize that's mostly code that all needs to work right?

Yeah and an operating system has 10s of millions of lines of code. Does that mean everything else comes without a cost? Also point here is you got options for a much lighter framework, which you bluntly missed.

They probably didn't miss it, more likely haven't been impacted by the sheer number of dependencies in Next js. I know I haven't.

chrome and nextjs do not share a use case. Whereas chrome is a web browser nextjs is a framework for building web applications.

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

Really??

And work it does!

You can use lit components within Next, or within anything really. If you’re building a single app, use what you’re comfortable with. At my job, we’re often creating components that need to be used within an increasing number of frameworks because every client is using something different. Having a custom element instead of needing to load React on every client’s website is huge.

Interesting, at the workplaces I've been at, we only used React, nothing else, in order to make the code-sharing problem much easier, as well as not have developers learning many different frameworks just to get work done.

But wouldn’t you be happier if each and every component on the page paid the price of a full templating system?

No?

Oh yeah, I forgot that Web Components are a terrible idea that are only marginally successful because they can claim to be a “standard” when they’re not any more standard than any other JavaScript.

I honestly don't know how WCs got through the standards process successfully, they're so bad.

The answer is that they're from ~2013: before React etc. taught us how to make SPAs. It was an early attempt, so it sucks. JS is best when it "paves the cowpath" and takes something we could already do slowly in browser and gives us a better native API for same thing, like querySelector or IntersectionObserver or how there was no built in way to parse a query string before URLSearchParams. Anytime JS goes first, the API is crap, like the DOM Node APIs themselves.

You only "pay" for as many template systems as you use, not one for every component, and modern template systems are far smaller than the major frameworks.

Each independent script you import is another load blocker. You could have scripts A and B both import template C, but then you're slowing things down even more, and no "HTTP2 push!" is not the answer.