420stalin69 [he/him]

deleted by creator

1. Duck typing
2. Typescript

Sugangeese nuts

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.

My ADHD interests: intensely researching a topic that has no prospect of financial reward and wanting to talk about it to people who don’t care

Boiling water feels really fucking hot which is why Celsius makes more sense

VPNs are much cheaper than Netflix, torrents don’t have ads, it’s always perfect quality, and the content catalog is excellent.

There was that hot Somali who was Tik Tokking himself while boarding a cargo ship.

But he was enforcing a blockade enacted by his government within Yemeni territorial waters so unfortunately it wasn’t piracy.

array.whomst(element => element === needle)

You do not gotta give it to them

Think about what you just said for a second.

If the price doubles and the profit margin remains the same, that exactly means that the price is inelastic.

Which is directly synonymous with saying the price is not subject to supply and demand pressure because that would imply elasticity.

You pointed to price inelasticity as proof of price elasticity. God fucking damn.

It makes the already-wealthy owners of the extraction license wealthier and nothing more than that you [edit personal insult removed because I didn’t realize this wasn’t Hexbear, disculpe]

Yeah ok that’s fair, even in a transformed world there is still a need for some cars you’re right.

My point was more that a world in which we simply exchange fords for Tesla’s is still a fucked world but you make a fair counter point.

Not really. At all. Like they’re barely even a bandaid.

The issue is a car weighs a couple of tons and it’s being used to move a person who weighs around 100kg.

It’s massively inefficient use of energy.

Even in some fantasy world where the energy used to charge the batteries is all renewable - not even close to reality but let’s pretend - all that lithium and other precious earths are still an environmental disaster.

The answer is mass transit and lower mass vehicles. A lifestyle change is actually required and the thing is it wouldn’t even make people less happy, just that change is so fucking scary for some reason.

Walkable cities are a dream lifestyle and an electric scooter in a walkable city is outstanding. Fuck urban sprawl.

Spend 42 hours making a professional quality message queue and entity component system then shelve the project because you got bored.

They’re not wrong.

Apple has a better stance on data privacy than google because their profit model is being a premium consumer device whereas googles profit model is being a provider of ads.

Apple’s incentives are closer to the consumer since they want to make the consumer happy while googles incentives are aligned with the trackers because that improves ad revenue.

This changes the DNA of the OS.

Plus the integration of googles data insecure services with android mean that as a matter of actual reality then discussing the security of android really means discussing the data security of those integrated services. It’s unavoidable.

Don’t trust either of course but I simply do have more confidence my apple data isn’t being exploited as much as my google data simply because Apple doesn’t stand as much to gain and stands more to lose from being embarrassed on the issue.

And pointing to custom android roms that replace google services with FOSS alternatives is a technically correct but still wrong answer to this because it doesn’t reflect the reality of the overwhelming majority of android users.

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.

20 years of software engineering and you too will have a 10-20% chance of knowing how to exit vim.

Unlike your Java program amirite.

The benefit of java is that you didn’t write the security holes in your software.