Readit NewsUnsurprisingly the idea did not take off, but I did find the XML/XSLT combination to be very interesting.
PHP as a language? Definitely getting better but still not great. Doesn't support async, the stdlib is awful, data structures are quite rudimentary (no tuple, no list, no map, just a weird array type mixing maps and lists), the old extension system sucks.
But the ecosystem? Damn. I see many people here saying that Typescript is definitely the mature choice for the backend. Honestly, I wanted to believe it, but I disagree. The level of productivity with Laravel is absolutely insane. You have everything you need out of the box and you can launch something so fast it's almost unreal.
Typescript doesn't have that. Maybe it's because of a different mentality in this ecosystem (you should build your blocks yourself), but nothing comes close. The closest would be Adonisjs but it doesn't seem to gain traction.
You don't choose a language to build your web project. You choose a stack. A framework. I definitely prefer python but Django has way less features than Laravel and I don't really enjoy using it. Typescript on the backend was a thing I wanted to believe in (because sharing types between the front and back is a great idea), but I feel like I have to reinvent the wheel, or at least choose 20 different wheels to do something quite simple.
Is Ruby such a great language, or do people just love being productive with Rails? It seems to me that the usage of Ruby without Rails is quite low (I could be wrong).
People choose and stick with stacks, not just languages. And I couldn't find something equivalent to Laravel elsewhere. Give me an equally productive stack and I'll happily drop PHP.
The things that held PHP up in the early days, especially it being just dead simple to deploy, are not as big a deal in 2025 as they were in 2005. Shared hosting, while it still definitely exists, is kind of a dying model. Most modern dev I see these days even in PHP is nginx/PHP-FPM and containers, which is really not that terribly different from any other web framework. Even Wordpress, these days I recommend anyone who truly wants to go down that path to find a hosted Wordpress provider rather than trying to do it themselves.
Personally? I would never start a greenfield project now using just PHP. I don't know many people who would.
But PHP + Composer + Laravel? Laravel did for PHP what Rails did for Ruby, and what React/Vue/etc did for JS. Composer gave PHP real package management. It cannot be understated how important it was to have a framework and package manager to take care of all of the thoroughly unpleasant parts. That way you can focus on building the app, not reimplementing things you've done so many time before.
The core tech is tuned for performance, using local gridded files instead of a traditional database or response caching. This efficiency is what allows it to stay free.
You can try it here: https://open-meteo.com
I switched to Open Meteo a few months ago when the previous API I was using quit working. It's been rock solid and such a nice user experience compared to everything else I tried.
XUL was deeply unpleasant to use and maintain, and I do not miss it at all. We eventually ended up rewriting it as a standard webapp. It made the writers a bit slower, but they adapted eventually.
That is why the netbook boom died. Because while they promised to make cheap Linux devices that anybody could use none of them actually delivered on it.
In fact the whole thing was a fiasco.
The classic Linux problem can be described as "9 clicks to shit". Meaning that a Linux desktop looks, on the initial viewing, as something that is actually usable and modern, but once you start clicking around things start going bad. Going bad quickly.
A major problem cause of the problem is "linux is about choice" mentality.
Another problem is that programmers specialize at being good at programming, but things like documentation and UI testing are their own disciplines that are separate and distinct in a lot of meaningful ways. So, in attempt to make up for this, they leave configuration and details up to user choice. It is effectively pawning off the last stages of development onto the end user, who are generally most ill-equipped to make technical decisions on software they are not familiar with.
Instead of presenting something that "just works" users are presented with a myriad of choices and options that they have to make decisions about before ever actually being able to use the software.
Having lots of choices in applications, widget libraries, desktops, ways to install software, init systems, etc etc... results in very significant complexity as it all has to work together.
And complexity breeds bugs.
So each and every user experience ends up being its own unique things. There is no "standard configuration" no "supported configuration" and no "documented configuration".
The end result is that each user is forced to find ways to make the desktop work for their specific use case. Essentially finding a magic combination of things that isn't broken for what they specifically want. The desktop will still be full of buggy behavior, but just not in the way that that particular user cares about.
This creates a extraordinary of frustration and friction when time comes to doing the things that the desktop is actually intended for... which is getting actual work done.
This isn't a problem for a certain class of highly technical users that love technical minutia and configuring things. Knowing how to carve a working system out of a OS riddled with historical artifacts and highly technical choices is a badge of honor for many people.
But this isn't how most people want to do things.
Netbook boom tried to fix this in certain ways, but all that ended up happening is that each little corporation tried to do their own thing and then abandoned it when they realized there was no money to be made and they really lacked the resources and expertise to make it work.
Even having decent UIs is a problem for many Linux apps and many are often deeply unpleasant to use day-to-day. This is one thing that has started to slowly get better in the last decade or so, but I can always tell what applications were designed by programmers and which ones have had at least some UI work done on them.
Also, accepting feedback from users on UI improvements often gets either ignored or de-prioritized in favor of adding new features. It's very frustrating to see an otherwise really fantastic application with a lot of neat functionality hamstrung by a bad UI.
Ended up setting it up as a virtual thermostat along with a Zigbee temperature sensor and letting HA manage the the whole thing. After a few months of hacking and tweaking, it works pretty well!
But, there were a few problems with this approach:
* The IR code to turn on and turn off were the same code (which makes sense if you look at the unit, there's just an on-off toggle button)
* No temperature control. On the heater itself, you can adjust the temperature as well as a high/medium/low setting. The remote didn't have these settings, so I couldn't capture them using an IR receiver sensor. Thankfully, these settings persist when the unit is off so I just set them once and called it good enough. And I eventually got around the need for this by setting up the virtual thermostat with a Zigbee temperature sensor in the room.
But the biggest problem is that I had no way to know if the unit was actually ON.
The codes sometimes wouldn't work unless the IR blaster was pointed directly at the unit, and even then they will sometimes randomly fail. I ended up plugging it into a Zigbee plug with power monitoring, so I could tell from the power draw if it was on, and try to re-send the commands a few times if it failed to turn on.
Overall, it was kind of a fun way to make a dumb device smart, but what OOP is doing is way cooler.
I help administer a somewhat popular railroading forum. We've had some of these AI crawlers hammering the site to the point that it became unusable to actual human beings. You design your architecture around certain assumptions, and one of those was definitely not "traffic quintuples."
We've ended up blocking lots of them, but it's a neverending game of whack-a-mole.