420stalin69 [he/him]

A study just came out that was posted in Hexbear showing at least 15% of Reddit content is corporate botting so we should just have some fun with LLMs and AstroTurf it instead like everyone else is doing

deleted by creator

1. Duck typing
2. 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.

If the public are paying for it, then it becomes a subsidy.

And good luck getting the US government to require the code to be GPLed. That’s even less likely to happen than a public subsidy for OSS at all.

They typically do the opposite and require “commercialization” to ensure the benefit of the publicly-funded technology is captured by their donors.

This is how it basically works in biotech, for example. Government grants to study the medicine and then when the scientists actually find something important it becomes a “public-private partnership” often without even a royalty for the public let alone making it a public good.

That’s not how government funding works in a modern democracy, unfortunately. It would amount to a cash transfer to big tech to make the public pay their R&D costs.

So a public subsidy for big tech to get free code?

Isn’t assessing the issue on the issue tracker “listening to input” though?

Your options are

• do it yourself and create a pull request
• make a suggestion to the devs on the issue tracker, who have every right to reject it
• start a discussion here if you believe a feature is important enough to have public debate

That seems like a lot of options for listening to input to me.

What exactly is missing that you want to see? How could you add what you see is missing?

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.

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.

Implying Spotify pays artists a fair fee.

Fuck, and I cannot emphasize this enough, them