Our great sponsors
-
-
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
css-scope-inline
🌘 Scope your inline style tags in pure vanilla CSS! Only 16 lines. No build. No dependencies.
-
-
htmf
A minimalist partial html swapping library similar to HTMX and other libraries which create an MPA app and enhances it with a focus on HTML forms.
I have used this approach for internal tools and it has been great. It makes it much easier for one person to build the whole app, frontend and backend, and makes ongoing maintenance much easier.
I am working on https://github.com/claceio/clace which takes this no build approach and makes it easy to build portable applications, using Starlark running in go to configure the backend.
I agree in principle that HTML is the best option for a good user-experience, but it quickly breaks down in terms of developer-experience and maintainability. However, we don't need to compromise on either by using a solution like Qwik[1]. Where the page progressively becomes more interactive with JavaScript, and doing as much work as possible on the server beforehand.
1. https://qwik.builder.io/
I like this. I share a philosophy similar to this: hew close to the grain of the material. It's heartening to see articles like this. I've created many expressions of my ideas on this in code over the years: Brutal.JS, VanillaView, Bang/Good.html and I recently created one that is even simpler and I'm very happy with. It's similar to a unification of these ideas with Custom Elements. You can check it out here: https://github.com/00000o1/-
I built something recently with the same ideas in mind: https://github.com/sethkimmel3/tailgate. It allows people to build generative-AI applications without any of the complication of setting up a backend, and in the simplest cases only requires adding HTML attributes.
I originally learned to code with HTML, CSS, and JS, and I think it's still the easiest way to experience the magic of shipping a working application to others. We should keep encouraging more patterns and tooling that lower the barriers of entry to those just starting out.
> We use static-tailwind, a version with no build step, in development.
https://github.com/tonyennis145/dumb-tailwind/
Is it this? A 3.9 MB CSS file?
You can log in via GitHub OAuth (also implemented with HTML tags).
The source is here, that's all of it, there is no custom backend logic: https://github.com/Saasufy/chat-app
I published this article on Template Animation (aka DOM Templating) 12 years ago:
https://benkoworks.com/your-templating-engine-sucks-and-ever...
It fits nicely with this goal. My colleagues and I created a tool that allows HTML developers to work in HTML by compiling HTML using a Chrome extension, and then allowing developers to compile the same in their code platform of choice and operate on the DOM:
https://github.com/iaindooley/Fragmentify
https://github.com/iaindooley/fragmentify-js
Even if you're doing a SPA you can use this same method, by sending updates over the wire and doing the processing on the server. We created a standalone package that facilitated that by loading the initial page from the server then transparently allowing the server to send just the changes to the page and having them applied on the client side:
https://github.com/dgrinton/remote-standalone
The combination of "remote" and "fragmentify" and Template Animation/DOM Templating, in my opinion, would be a tremendous "retreat to move forward" in web development technologies.
I published this article on Template Animation (aka DOM Templating) 12 years ago:
https://benkoworks.com/your-templating-engine-sucks-and-ever...
It fits nicely with this goal. My colleagues and I created a tool that allows HTML developers to work in HTML by compiling HTML using a Chrome extension, and then allowing developers to compile the same in their code platform of choice and operate on the DOM:
https://github.com/iaindooley/Fragmentify
https://github.com/iaindooley/fragmentify-js
Even if you're doing a SPA you can use this same method, by sending updates over the wire and doing the processing on the server. We created a standalone package that facilitated that by loading the initial page from the server then transparently allowing the server to send just the changes to the page and having them applied on the client side:
https://github.com/dgrinton/remote-standalone
The combination of "remote" and "fragmentify" and Template Animation/DOM Templating, in my opinion, would be a tremendous "retreat to move forward" in web development technologies.
I published this article on Template Animation (aka DOM Templating) 12 years ago:
https://benkoworks.com/your-templating-engine-sucks-and-ever...
It fits nicely with this goal. My colleagues and I created a tool that allows HTML developers to work in HTML by compiling HTML using a Chrome extension, and then allowing developers to compile the same in their code platform of choice and operate on the DOM:
https://github.com/iaindooley/Fragmentify
https://github.com/iaindooley/fragmentify-js
Even if you're doing a SPA you can use this same method, by sending updates over the wire and doing the processing on the server. We created a standalone package that facilitated that by loading the initial page from the server then transparently allowing the server to send just the changes to the page and having them applied on the client side:
https://github.com/dgrinton/remote-standalone
The combination of "remote" and "fragmentify" and Template Animation/DOM Templating, in my opinion, would be a tremendous "retreat to move forward" in web development technologies.
Edit: There is a proposal to extend JavaScript with type annotations, which would allow ("a reasonably large subset") of TypeScript to run directly in the browser. Yay!
https://github.com/tc39/proposal-type-annotations
I've successfully used this pattern (HTMX hypermedia style) to create an offline-first web app SPA[^1]. One of the pages is pretty dynamic and I wasn't sure if I would need a traditional front end library to work with it. But, nope, hypermedia to the win, it worked fine without a front end framework.
To build it I used my own library called HTMF[^2]. I started out using mpa-enhancer[^3] but found that that pattern is a little to janky sometimes. I think reloading a page every time on every interaction uses too many resources for a browser especially when you use a phone that doesn't have as much power as a laptop.
But overall I find the pattern very easy to use and keeps the complexity down.
I think some of the issues with traditional SPAs is that they have a lot of state and state is nonlinear in complexity. But using templating systems makes the complexity more linear in nature.
Also, I find libraries like React to be overly complex for what it does, see above. The way React works is just odd and counter intuitive. All for problems that are easy to solve. I do think there are places for a React-like library is needed but those are for websites that are inherently highly state-based. But most websites aren't state-based even ones that appear to be state-based at first.
The websites I work on are usually just forms and forms are pretty powerful and can get you a long ways before you need to go outside of that paradigm.
[^1]: https://github.com/jon49/Soccer
[^2]: https://github.com/jon49/htmf
[^3]: https://github.com/jon49/mpa-enhancer
I've successfully used this pattern (HTMX hypermedia style) to create an offline-first web app SPA[^1]. One of the pages is pretty dynamic and I wasn't sure if I would need a traditional front end library to work with it. But, nope, hypermedia to the win, it worked fine without a front end framework.
To build it I used my own library called HTMF[^2]. I started out using mpa-enhancer[^3] but found that that pattern is a little to janky sometimes. I think reloading a page every time on every interaction uses too many resources for a browser especially when you use a phone that doesn't have as much power as a laptop.
But overall I find the pattern very easy to use and keeps the complexity down.
I think some of the issues with traditional SPAs is that they have a lot of state and state is nonlinear in complexity. But using templating systems makes the complexity more linear in nature.
Also, I find libraries like React to be overly complex for what it does, see above. The way React works is just odd and counter intuitive. All for problems that are easy to solve. I do think there are places for a React-like library is needed but those are for websites that are inherently highly state-based. But most websites aren't state-based even ones that appear to be state-based at first.
The websites I work on are usually just forms and forms are pretty powerful and can get you a long ways before you need to go outside of that paradigm.
[^1]: https://github.com/jon49/Soccer
[^2]: https://github.com/jon49/htmf
[^3]: https://github.com/jon49/mpa-enhancer