I never said that PHP was universally used, just that it has answers to most problems.
jQuery has become obsolete these days because the problems it solves have largely been solved by additions to JS, but the interactivity of websites has continued to increase and browsers have yet to catch up to that. Frameworks like React actively fight against the browser rather than work with it by maintaining its own DOM state and constantly creating copies of state for every re-render of a component, along with a bunch of other magic. That's a lot of unnecessary loopholes just to make up for JS's lack of features when it comes to writing reactive UI.
People like to hate on PHP, but PHP provides you with all the tools you need to write a fully working backend, where as JS provides you with half-assed solutions for writing frontend, which is why we have 1000 frameworks and we still can't agree on how to write frontend code. Seriously, we don't even have a convention for writing a simple reusable component with vanilla JS, everyone makes up their own thing. Web components were supposed to be that, but they're a good example of what I meant by "half-assed", because they're ugly, verbose, clunky, don't really solve the right problems, and nobody likes writing them.
Because it's been trendy to introduce a new unintuitive syntax with every new CSS feature.
I am genuinely afraid for the future of CSS as it is becoming increasingly more complex, meanwhile most people haven't been able to properly utilize or understand it for the last decade even without all of that additional complexity.
Remember when we used to be called "web developers"? We then became "software engineers", but forgot the meaning of the word engineer:
> Engineering is the practice of using natural science, mathematics, and the engineering design process to solve technical problems, increase efficiency and productivity, and improve systems.
We don't increase efficiency or improve systems, we just build garbage on top of garbage. Imagine if a structural engineer did the same and built new floors on top of shaky floors. Our buildings would be collapsing on a daily basis.
I get the potential appeal in having a single language do all things, but in practice the front-end and back-end have vastly different jobs and different capabilities, so I see no issue in them being different languages and letting them utilize their strengths. Not to mention the vast amount of complexity you need to involve at some point in order to bring a language to a side it wasn't meant to be in.
I'd love to, but I don't really have a choice at the moment.
Maybe I'm just at the wrong place at the wrong time, but as a software engineer I don't feel like I'm doing any actual engineering and solving meaningful problems, just spaghetti gluing random frameworks, packages and services together. The only problems I get to solve are those caused by the quirks of all these incompatible things being forced to work together. It's draining.
> People have a right to build substitutes and replacements -- I believe in the "Let a hundred flowers bloom" philosopy.
It's a blessing and a curse. Look at package managers, they more or less all do the same thing, with one primary job of "go download some binary so I can run it", yet there's so many to choose from. Every time you read some Linux guide they have to list 7 different ways of installing the same package. It's stupid, probably even more so for the maintainers of those packages because they have to distribute their package 7 different ways. At least I'm glad systemd has mostly become the standard, so you don't have to also see 7 different ways of creating a service.
> `ctx.Value` is an `any -> any` kv store that does not come with any documentation, type checking for which key and value should be available.
On a similar note, this is also why I highly dislike struct tags. They're string magic that should be used sparingly, yet we've integrated them into data parsing, validation, type definitions and who knows what else just to avoid a bit of verbosity.
Huh, I've heard about this for a while but for some reason thought it was strictly regarding phones, maybe because they've been making the biggest headlines about it. Looking forward to it then.
It's not my area of expertise so I might just be delusional here, but from my understanding phones are difficult to make waterproof if they had replaceable batteries because they require a massive lid that spans across the entire phone while having a limited amount of thickness to work with and also because they have some expectations about the depth at which they remain waterproof. You don't necessarily have these constraints with a toothbrush. You can have a small opening at the bottom where you insert a tall battery and have plenty of height left to make a waterproof hatch. You're also unlikely to submerge your toothbrush in more than 50cm of water, like in the event of dropping it in the bathtub.
> Also, anecdotally, I’ve never had a sonicare toothbrush battery die. They still last weeks after many many years of use.
Sure, these exist too, though it doesn't reflect the majority of items which cheap out on all components, including batteries.
I'm not denying that there are some trade-offs, but I'm also not strictly speaking about phones here. Think electric toothbrushes, trimmers, Bluetooth speakers and the other endless amounts of electric things with rechargeable batteries that don't have the space constraints of a phone.
This is a step in the right direction but still doesn't address my biggest concern with e-waste - the battery.
Because almost none of the electronics you buy come with a replaceable battery, the second you buy something and use it on a regular basis it's destined to die and be thrown out within the next 4-8ish years due to the battery degrading and becoming increasingly more dangerous to keep around. Something that might be in perfect working condition and could be used for another 10 years has to be thrown out because of one single component.
I understand that batteries come in all shapes, sizes, capacities, yada yada, but imagine if we had standard rechargeable batteries like we have standard non-rechargeable batteries and things were built in a way where you could easily replace batteries like we could on phones a decade ago. You would double or triple the lifespan of a ton of things.
And it'll continue to get worse because JS devs love coming up with their own abstractions over everything and piling complexity. You don't write JS, you write TS. You don't write HTML, you write JSX. You don't write CSS, you write Tailwind. And of course, React has its own compiler as of recently. Now you have to figure out in what order to run these parsers, bundle everything together including your hundreds of dependencies, minimize, obfuscate, tree shake, and whatever else fairy dust magic you want to sprinkle on top. Meanwhile, the default build tool of choice changes about once every 2 years, and now you also have a choice of runtime - node vs bun vs deno. Can't wait to see what the next revolutionary idea would be to contribute to this madness.
Of course it's not required but when you start pushing the boundaries of a language with the goal of achieving a clean interface, obscure features you wouldn't normally resort to become appealing. I dislike all of the magic around Laravel's Eloquent ORM - model relationships, query builder, abuse of ForwardsCalls trait, etc, but at the same time I can appreciate how "clean" it all looks once it's put together.
> what used to be a complex blob of floats is now a simple grid layout.
And what used to be relatively simple static layouts designed for a 4:3 screen are now layouts that must accommodate a screen of any arbitrary aspect ratio and physical size. This means that most of your components will now have at least 2 layout states, one for desktop and one for mobile, usually horizontal and vertical respectively, accomplished by switching random layout related properties on and off. Arguably anything related to CSS layout comes with a ton of quirks and flex/grid are no exception. It's those quirks that put most people off CSS, because they're sometimes far from intuitive, hard to debug, and are just things you have to know.
> Declaratively describe your UI, React paints it. That's it. No app state management.
"that's it" does not paint the full picture. Yes, UI = function(state) is very convenient but the way React implements it inverts the problem. Now instead of having to figure out ways of updating everything you have to go through numerous hoops to get only the things you need to update.
> the matchmaker shuffles the queue to avoid the same players being matched together repeatedly
This is actually something I hate about multiplayer games with matchmaking nowadays. I made the majority of my childhood friends only because we stayed on the same server and played together for hours on end. I don't think it's a stretch to say that a key reason for why we play multiplayer rather than single player games is to socialize. This has become increasingly more difficult when you just get a new set of people every 10-30 minutes.
As someone who's struggled with starting projects from scratch multiple times over and not releasing anything for many years because it was never good enough, half-assing is not the mindset that helped me start shipping things. Rather, it was gaining an understanding about which parts of my code don't need to be perfect right now and also realizing that practically nothing is perfect the first time you do it.
I now leave a bunch of TODOs in my code as a reminder to myself that yes, this isn't the best it can be, I'll come back and make it better when it becomes a bottleneck, but for the time being 80% of something is better than 100% of nothing. This way I'm able to move on and continue doing meaningful work rather than wasting time obsessing over minute details that almost nobody else would care about.
I've been using Go's html/template for the last couple of months and all I can say is that it's still very much a toy. It's fine for basic loops and conditionals but anything beyond that is extremely limited and having proper reusable components is a constant fight against limitations, specifically because of the lack of being able to pass multiple arguments to a template. I wish the Go team had gone with something more akin to PugJS[1], which in contrast is very rich in features, flexible and dare I say fun to build components and pages with.
jQuery has become obsolete these days because the problems it solves have largely been solved by additions to JS, but the interactivity of websites has continued to increase and browsers have yet to catch up to that. Frameworks like React actively fight against the browser rather than work with it by maintaining its own DOM state and constantly creating copies of state for every re-render of a component, along with a bunch of other magic. That's a lot of unnecessary loopholes just to make up for JS's lack of features when it comes to writing reactive UI.