Show HN: Simpler web dev with Htmx, SQLite and TypeScript | Hacker News Reader

Show HN: Simpler web dev with Htmx, SQLite and TypeScript

plainweb.dev

15 pointsjoseferben14 comments

i'm building this minimalistic framework mostly for myself. it's really just a project template + a tiny library that adds file based routes to express and persistent task queues.

i wanted something that:

1. is a single long-running process to deploy and manage (thanks sqlite!)

2. has type-safe database queries and type-safe server rendered React-like `.tsx` components

3. addresses 80% of common full-stack concerns like emails, task queues and routing

4. doesn't have a frontend build process

curious to hear what you think!

Open articleView on HN

This looks really good!

> 4. doesn't have a frontend build process

Is it entirely server-side and then it's all htmx? Is there a way to also hook client-only TS/components for more complex/interactive stuff? Or is that out of scope entirely?

thank you!

yes, it's server-side with htmx at the moment. anything client-side that has a build process is entirely out of scope as i think that's a major source of complexity.

i'm considering embracing alpine.js for when htmx is not enough, just need to make sure the alpine directives are type-safe.

i think it's exciting what astro, hono or fresh are doing with islands of interactivity but plainweb tries to be even more minimalistic.

ditch typescript and Im more with you.. you'll never convince me that something that compiles to js is "simplicity".

would you say running bun or deno would be simpler since compilation doesn’t happen in “user land”?

4. doesn't have a frontend build process

I'm curious about how does that work? TypeScript isn't supported in the browser nor is JSX.

JSX components (.tsx) are rendered server-side, it's all just GET/POST with optional HTMX

So the frontend is built in the server on every request. That's the opposite of not having a frontend build process

strictly speaking there is a simple build process on the server since plainweb uses node + tsx (the esbuild wrapper, not the markup) instead of something like bun or deno that supports typescript natively.

plainweb avoids build processes that bundle js that runs in the browser.

Alright. I don't think it is the smartest engineering to avoids "building js" by "building html from js". But good luck with that!

If Node is your backend then JS is what you need to use. Whether directly or via Typescript.

JS is just the language. Avoiding JS on the front end is more about avoiding front end code, state management, mutations, a11y issues, frameworks etc. rather than the JS language itself!

It also means avoiding using available tools in a well tested OS that is a browser like service workers, WebRTC, etc. Not knowing how to use them efficiently isn't a feature.

It is a developer time tradeoff. If your app is mainly forms and not that interactive a framework like this would be OK. Internal crud tools would be an example. But you can’t use it for everything (you can’t use any framework for everything!)

Looks great. Going to give it a try for sure.

awesome, let me know how it goes!

Reply on news.ycombinator.com