HN Explorer

Show HN: Simpler web dev with Htmx, SQLite and TypeScript (plainweb.dev)

15 points by joseferben ↗ HN
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!

14 comments

[ 2.5 ms ] story [ 44.5 ms ] thread
stagas
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?

joseferben
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.

meiraleal
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.

joseferben
JSX components (.tsx) are rendered server-side, it's all just GET/POST with optional HTMX
meiraleal
So the frontend is built in the server on every request. That's the opposite of not having a frontend build process
joseferben
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.

meiraleal
Alright. I don't think it is the smartest engineering to avoids "building js" by "building html from js". But good luck with that!
langcss
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!

meiraleal
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.
langcss
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!)
platic
Looks great. Going to give it a try for sure.
russdpale
ditch typescript and Im more with you.. you'll never convince me that something that compiles to js is "simplicity".
joseferben
would you say running bun or deno would be simpler since compilation doesn’t happen in “user land”?