For a certain kind of application HTMX is a convenient way to work. It lets you write a webapp the way you did in 1999 except you can update pages partially. Here is a screenshot of an my HTMX-powered RSS reader
This is a research project, but it's a research project by an applications programmer so it has to be solid. Yet I have to be able to change anything when I want to do it and if I used the "standard model" I'd have to change both the back end and the front end when adding a new task but this way I can add a new form once and add it to the rotation, pop it up in a modal, split it out on another page, etc. If this was a big production system with lots of people tagging things I could roll out new tasks by rolling out new forms and not force reloading of a front end.
I use it together with other client-side Javascript, for instance with D3.js for highly customized charts and visualizations.
A major time saver is that it skips the Javascript build. When I make I change I reboot a Python server and it comes up in 1.6s.
Hey! I'm also building an HTMX-powered RSS reader, although it's more a side project than a research project. Good luck, it's been lots of fun for me so far!
I've also found the productivity of a "strong" decoupling from frontend and backend to be super satisfying.
Suppose you want to add a ‘plug-in’ such as a new social media share button: often this is going to involve front and back end changes. In my RSS reader this could be a python package with declared entry points so the application could read it, enabling a few more http endpoints and also adding templates to extension points.
In a ‘standard model’ application you need to have an npm package and a Python package and corresponding extension mechanisms on both sides. You can probably make a system that wraps an npm package inside a Python package or maybe the other way around but it will be a struggle.
(The architecture of my current system was inspired by a system I worked in that not only used Scala, Typescript and Python but also Docker such that builds took 20 minutes! They could afford to do that on a venture capitalist’s dime but I can’t.)
You don't have to build JavaScript; it runs natively in the browser. In fact, the only time when you would have to consider a dedicated build step is if you were using something like TypeScript, or if you wish to use external modules.
In the case of external modules, check out ES6's import syntax. You can import from a URL just like it's an NPM module. I believe a few CDNs are designed to facilitate this use-case too.
That's how I use D3.js. But for the React programs I work on at work we are already committed to a build process, there are bits of Typescript, SCSS, and for production at least tree-shaking and minimization seem a most for something with that many moving parts.
https://mastodon.social/@UP8/110432673973724419
This is a research project, but it's a research project by an applications programmer so it has to be solid. Yet I have to be able to change anything when I want to do it and if I used the "standard model" I'd have to change both the back end and the front end when adding a new task but this way I can add a new form once and add it to the rotation, pop it up in a modal, split it out on another page, etc. If this was a big production system with lots of people tagging things I could roll out new tasks by rolling out new forms and not force reloading of a front end.
I use it together with other client-side Javascript, for instance with D3.js for highly customized charts and visualizations.
A major time saver is that it skips the Javascript build. When I make I change I reboot a Python server and it comes up in 1.6s.