If rapid iteration is more important than performance or cost then you can more easily have a monolithic-ish build system that creates the client and the server from a single code base, or with shared code between them.
If you are trying to upgrade frontenders to be fullstack it’s an easier entry point.
Sometimes the performance characteristics of node actually is useful for serverless since a cold start and a hot start are not very different, closer to a fixed cost just to run a script when compared to something like dotnet which has slow cold starts but fast hot starts. Which is also why it sucks for most server code but on occasion this can be a useful characteristic.
If you want to do serverside rendering with client side hydration then it can be handy to implement the display logic once and run on both the client and the server (eg server side rendering react or vue etc)
Those are a handful of decent reasons but broadly speaking agree, it’s not the best choice if you care about cost and the benefits in the specific cases above are either rare or short lived.
Except really for SSRing with client hydrarion, that’s really the slam dunk case where it’s the more often than not correct choice due to the advantages of not duplicating logic.
The real reason why I often use server side JS is that it’s just faster to write in the first instance if I need to spin something up real quick or for infrequently invoked code where performance and cost don’t really matter. Of course for anything serious it’s a bad choice.
Js isn’t the only options for making full stack apps though. For example, I’ve built lots of apps using Clojure and ClojureScript getting the same benefits, but using a much better language. There are a few languages nowadays that compile to Js, but have much cleaner semantics. I kind of see Js the same way as assembly nowadays, to me it’s a compile target.
Another option nowadays is to use something like HTMX and just treat the frontend as a dumb client that simply renders the UI and collects input. This works fine unless the app has a lot of interactivity, which is majority of sites out there. HTMX also has the advantage of having the whole state in one place, and avoids the need for all the plumbing to ship data to the client via AJAX or GQL.
Yeah I would never use vanilla JS unless forced to these days. Always Typescript if I’m doing anything JS related that isn’t completely trivial.
As for HTMX, it looks fun but I would consider that kind of fancy and fresh framework more appropriate for hobby projects or a rapid iteration proof of concept and not for production. For a start it’s just fresh and that alone means you can’t really use it yet except for more trivial cases since you need to be assured that the tool will be able to scale with your needs and it just hasn’t been proven for that yet.
Secondly if you need to be able to scale a team then you need to either be willing to pay to train people in a new framework (and there are a constant stream of cool new frameworks so training should be conservative), or you need to be able to hire for it easily and to hire for it easily it should be a widely used framework with a deep of talent available.
Finally it lacks type safety, at least so far as I can see, and so I wouldn’t want to use it for anything more complex than a storefront.
I can totally see that being a fun tool to use for a hobby project and maybe in two to five years we will all be using it just like we are all using react and vue today but there’s value in being conservative in these choices when you’re looking for scalability, long term maintainability, and the ability to assemble a team.
And finally it’s not the first js in html framework. It’s been done before and hasn’t really caught on. Maybe HTMX will be different, im not saying it won’t be the one to crack that nut because it very well might be the future who knows, but I would want to see it’s approach to be proven before selecting it since in the past js in html has tended to hit a wall. Like you can often do some really cool shit with minimal code and you fall in love but then you hit some use case that requires more complex logic and bam you find yourself either resorting to traditional JS anyway or even worse you are left stuck.
These are general remarks on why fancy fresh isn’t necessarily the best. I haven’t used HTMX so it’s possible it will be the next big thing. Eventually something will replace React / Vue / Svelte for sure and maybe it’s HTMX.
But that’s the rationale for considering for a hobbyist tool or a rapid prototyping tool rather than a production ready framework.
Today for anything that really needs to scale and where SSR is desired i would almost certainly be choosing Vue or React or maybe Svelte. And if I was feeling adventurous I might use Qwik since it’s not a radical departure from those others, being a lot of the best of Svelte with some cool new ideas.
These things move in cycles of course and clearly we need to start moving on from Vue and React soon since SSR is an afterthought in their design. But that needs to be balanced against a healthy conservativism if the product needs longer term scale and maintenance.
I think the more immediate path forward is to get much better server side runtimes such as bun and smarter caching and bundling techniques. Bun or some other very snappy and optimized server side js engine, using html templating more than jsx components, with very smart webpack bundling and extensive caching using an islands or micro frontends architecture for progressive enhancement is a more conservative choice that can achieve a lot.
Maybe something like HTMX will be a paradigm shift. It will happen soon enough of course. But I wouldn’t throw away a decade of tooling and development in those less sexy frameworks too easily. Not when there are less radical changes we can make to achieve dramatically better results that are still on the table that don’t require the adoption of unproven and not widely used frameworks.
Sorry I’ve written a lot here xD but to add one more comment, for server side code dotnet is making huge strides and modern dotnet core is blazing fast now. Sure it’s not necessarily the fastest but it’s nonetheless really fast now and it comes with DECADES of proven use, a massive community, and tooling that is second to none. If I didn’t want to use server side JS it would take a very fancy framework indeed to convince me to forgo the decades of proven reliability and development that is available to me there. Plus I can say with a very high degree of certainty that dotnet will still be around in 5-10 and probably even 20 years from now while HTMX has a high chance of disappearing to another fresh faced sexy framework in the near future.
My apologies if this was too long or repetitive :)
HTMX isn’t really all that fresh as it’s basically the same thing as hotwire in Rails that’s been around for a long time now and this approach has been successfully used for lots of real world applications. This tool has very much been proven, and the approach is well understood along with its strengths and weaknesses compared to SPA style apps.
HTMX is not a framework either, it’s literally just a way to update the DOM on the page dynamically. The whole point of HTMX is that all the logic lives on the server, and the server simply sends back the HTML that needs to be updated on the page.
I’ve also never had any problems working with teams or hiring using niche technology. As I’ve mentioned, I primarily work with Clojure which is a niche language, and it’s just not a real problem in practice. In fact, I’d be very suspicious of working with people who aren’t capable of learning a new language or a library. Learning things and figuring out problems is the core competence of a software developer, and if they’re not able to learn new things I’d be very suspicious of working with them.
HTMX also has nothing to do with type safety because it’s a protocol for hinting what pieces of the DOM the client needs to update when in HTTP responses. I have absolutely no idea what you’re trying to say regarding type safety here. Again, HTMX is not a js framework, it’s a light weight library for patching in HTML into the browser DOM. That’s all it does.
And I really have no idea why you keep referring to HTMX as a hobbyist tool. It’s a widely used tool that’s used by large companies to make real world apps. It might be a new thing to you, but it’s certainly not a shiny new thing that hasn’t been used in anger.
The comparison between .NET and HTMX is also nonsensical given that you could use HTMX with a .NET backend just fine. Again, HTMX is a tiny library that just patches things into your DOM. It’s not a frameworks, it’s not a language, it’s not a runtime. It’s just an extension on top of HTTP requests.
The advantage of HTMX is precisely that you don’t need a frontend framework, and you can just keep all your state on the server resulting in a much simpler application. The main disadvantage of HTMX is that the state lives on the server. If you’re in a scenario where the UI has a lot of interactivity, or where you want to do horizontal scaling on the backend, that’s where SPA would be a better fit.
If rapid iteration is more important than performance or cost then you can more easily have a monolithic-ish build system that creates the client and the server from a single code base, or with shared code between them.
If you are trying to upgrade frontenders to be fullstack it’s an easier entry point.
Sometimes the performance characteristics of node actually is useful for serverless since a cold start and a hot start are not very different, closer to a fixed cost just to run a script when compared to something like dotnet which has slow cold starts but fast hot starts. Which is also why it sucks for most server code but on occasion this can be a useful characteristic.
If you want to do serverside rendering with client side hydration then it can be handy to implement the display logic once and run on both the client and the server (eg server side rendering react or vue etc)
Those are a handful of decent reasons but broadly speaking agree, it’s not the best choice if you care about cost and the benefits in the specific cases above are either rare or short lived.
Except really for SSRing with client hydrarion, that’s really the slam dunk case where it’s the more often than not correct choice due to the advantages of not duplicating logic.
The real reason why I often use server side JS is that it’s just faster to write in the first instance if I need to spin something up real quick or for infrequently invoked code where performance and cost don’t really matter. Of course for anything serious it’s a bad choice.
Js isn’t the only options for making full stack apps though. For example, I’ve built lots of apps using Clojure and ClojureScript getting the same benefits, but using a much better language. There are a few languages nowadays that compile to Js, but have much cleaner semantics. I kind of see Js the same way as assembly nowadays, to me it’s a compile target.
Another option nowadays is to use something like HTMX and just treat the frontend as a dumb client that simply renders the UI and collects input. This works fine unless the app has a lot of interactivity, which is majority of sites out there. HTMX also has the advantage of having the whole state in one place, and avoids the need for all the plumbing to ship data to the client via AJAX or GQL.
Yeah I would never use vanilla JS unless forced to these days. Always Typescript if I’m doing anything JS related that isn’t completely trivial.
As for HTMX, it looks fun but I would consider that kind of fancy and fresh framework more appropriate for hobby projects or a rapid iteration proof of concept and not for production. For a start it’s just fresh and that alone means you can’t really use it yet except for more trivial cases since you need to be assured that the tool will be able to scale with your needs and it just hasn’t been proven for that yet.
Secondly if you need to be able to scale a team then you need to either be willing to pay to train people in a new framework (and there are a constant stream of cool new frameworks so training should be conservative), or you need to be able to hire for it easily and to hire for it easily it should be a widely used framework with a deep of talent available.
Finally it lacks type safety, at least so far as I can see, and so I wouldn’t want to use it for anything more complex than a storefront.
I can totally see that being a fun tool to use for a hobby project and maybe in two to five years we will all be using it just like we are all using react and vue today but there’s value in being conservative in these choices when you’re looking for scalability, long term maintainability, and the ability to assemble a team.
And finally it’s not the first js in html framework. It’s been done before and hasn’t really caught on. Maybe HTMX will be different, im not saying it won’t be the one to crack that nut because it very well might be the future who knows, but I would want to see it’s approach to be proven before selecting it since in the past js in html has tended to hit a wall. Like you can often do some really cool shit with minimal code and you fall in love but then you hit some use case that requires more complex logic and bam you find yourself either resorting to traditional JS anyway or even worse you are left stuck.
These are general remarks on why fancy fresh isn’t necessarily the best. I haven’t used HTMX so it’s possible it will be the next big thing. Eventually something will replace React / Vue / Svelte for sure and maybe it’s HTMX.
But that’s the rationale for considering for a hobbyist tool or a rapid prototyping tool rather than a production ready framework.
Today for anything that really needs to scale and where SSR is desired i would almost certainly be choosing Vue or React or maybe Svelte. And if I was feeling adventurous I might use Qwik since it’s not a radical departure from those others, being a lot of the best of Svelte with some cool new ideas.
These things move in cycles of course and clearly we need to start moving on from Vue and React soon since SSR is an afterthought in their design. But that needs to be balanced against a healthy conservativism if the product needs longer term scale and maintenance.
I think the more immediate path forward is to get much better server side runtimes such as bun and smarter caching and bundling techniques. Bun or some other very snappy and optimized server side js engine, using html templating more than jsx components, with very smart webpack bundling and extensive caching using an islands or micro frontends architecture for progressive enhancement is a more conservative choice that can achieve a lot.
Maybe something like HTMX will be a paradigm shift. It will happen soon enough of course. But I wouldn’t throw away a decade of tooling and development in those less sexy frameworks too easily. Not when there are less radical changes we can make to achieve dramatically better results that are still on the table that don’t require the adoption of unproven and not widely used frameworks.
Sorry I’ve written a lot here xD but to add one more comment, for server side code dotnet is making huge strides and modern dotnet core is blazing fast now. Sure it’s not necessarily the fastest but it’s nonetheless really fast now and it comes with DECADES of proven use, a massive community, and tooling that is second to none. If I didn’t want to use server side JS it would take a very fancy framework indeed to convince me to forgo the decades of proven reliability and development that is available to me there. Plus I can say with a very high degree of certainty that dotnet will still be around in 5-10 and probably even 20 years from now while HTMX has a high chance of disappearing to another fresh faced sexy framework in the near future.
My apologies if this was too long or repetitive :)
HTMX isn’t really all that fresh as it’s basically the same thing as hotwire in Rails that’s been around for a long time now and this approach has been successfully used for lots of real world applications. This tool has very much been proven, and the approach is well understood along with its strengths and weaknesses compared to SPA style apps.
HTMX is not a framework either, it’s literally just a way to update the DOM on the page dynamically. The whole point of HTMX is that all the logic lives on the server, and the server simply sends back the HTML that needs to be updated on the page.
I’ve also never had any problems working with teams or hiring using niche technology. As I’ve mentioned, I primarily work with Clojure which is a niche language, and it’s just not a real problem in practice. In fact, I’d be very suspicious of working with people who aren’t capable of learning a new language or a library. Learning things and figuring out problems is the core competence of a software developer, and if they’re not able to learn new things I’d be very suspicious of working with them.
HTMX also has nothing to do with type safety because it’s a protocol for hinting what pieces of the DOM the client needs to update when in HTTP responses. I have absolutely no idea what you’re trying to say regarding type safety here. Again, HTMX is not a js framework, it’s a light weight library for patching in HTML into the browser DOM. That’s all it does.
And I really have no idea why you keep referring to HTMX as a hobbyist tool. It’s a widely used tool that’s used by large companies to make real world apps. It might be a new thing to you, but it’s certainly not a shiny new thing that hasn’t been used in anger.
The comparison between .NET and HTMX is also nonsensical given that you could use HTMX with a .NET backend just fine. Again, HTMX is a tiny library that just patches things into your DOM. It’s not a frameworks, it’s not a language, it’s not a runtime. It’s just an extension on top of HTTP requests.
The advantage of HTMX is precisely that you don’t need a frontend framework, and you can just keep all your state on the server resulting in a much simpler application. The main disadvantage of HTMX is that the state lives on the server. If you’re in a scenario where the UI has a lot of interactivity, or where you want to do horizontal scaling on the backend, that’s where SPA would be a better fit.