420stalin69 [he/him]
- 0 Posts
- 9 Comments
- Duck typing
- Typescript
Don’t forget refinement where you describe your plan to add the “height: 80pt” rule (literally what the client wants), and then poker planning where you say it will be 1 point and the lead dev says 3 points and the other dev asks what is a point anyway leading to a time consuming discussion, and then the task gets scheduled for not next sprint but the sprint after, and then you do it and push your code, make a pull request, then during code review it is suggested you use tailwind instead but your project isn’t using tailwind because it’s some legacy PHP monster started by a junior who was just learning PHP, so now there’s a POC to consider using tailwind meanwhile the lead dev (who has a background in QA) designs a reusable “height engine” which uses rabbitmq to alert all worker nodes (there’s only one) about any changes to the height rules in mongodb. The height engine doesn’t include units so you have to hardcode if the client is expecting rem or pt. The product owner asks you in sprint review why this ended up taking a week when you said 1 point initially and the team agreed on 3. A team decision is made that all future CSS rule changes require a POC prior to implementation.
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 :)
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.