Show HN: Simpler web dev with Htmx, SQLite and TypeScript(plainweb.dev)
plainweb.dev
Show HN: Simpler web dev with Htmx, SQLite and TypeScript
https://www.plainweb.dev/
14 comments
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?
> 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.
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.
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.
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!
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!)
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!