It’s connected with the questions around occupational licensing of programmers, unions, and similar structures which would not be so much about getting paid more but about getting quality up, squashing bullshit, and getting our quality of life up.

Without a cohesive community, mutual respect, and recognition of a shared body of knowledge, we don’t have the solidarity to make it happen.

As for Laravel, I’d say people were making complex applications (Ebay, Amazon, Yahoo) in 1999 —- Google Maps were better than Mapquest, which drew each image with a cgi-bin, but many SPA applications are form handling applications that could have been implemented with the IBM 360 and 3270 terminal.

The OG web was missing a few things. Forms were usually written on one HTML page and received by a separate cgi-script. To redraw the form in case of errors you need one script that draws the form and draws the response and a router that choose which one to draw. You need two handfuls of helper functions, for instance

   <? draw_select($options,$selected_options,$attributes) ?>

to make forms which can be populated based on what’s already in your database. People never wrote down “the 15 helper functions” because they were too busy writing frameworks like Laravel and Ruby-on-Rails that did 20x more than you really needed. So the knowledge to build the form applications we were building in 1999 is lost like the knowledge of how the pyramids were built.

As for performance, web sites today really are bloated, it’s not just the ads and trackers, it’s shocking how big the <head/> of documents get when you are including three copies of the metadata. If you are just drawing a form and nothing else, it’s amazing how fast you can redraw the whole page —- if you are able to delete the junk, old school apps can be as fast as desktop apps on the LAN and still be snappy over mobile.

▲ wredcoll 4 days ago | parent [-]

> The OG web was missing a few things. Forms were usually written on one HTML page and received by a separate cgi-script. To redraw the form in case of errors you need one script that draws the form and draws the response and a router that choose which one to draw

Yes, I was there, I wrote and used these pages. It sucked. Things are better now.

> So the knowledge to build the form applications we were building in 1999 is lost like the knowledge of how the pyramids were built.

Building a form with zero user affordances is not difficult. It just isn't good.

We absolutely know how the pyramids were built. You get a whole bunch of humans to move a very large amount of stone and then stack it up in a big pile. The reason nobody builds pyramids today is because we have better alternatives.

▲

PaulHoule 4 days ago | parent [-]

I've been in a happy place with React with some projects.

I've worked on some where it was valid choice but boy the annoyances, like not being able to test your components because you're on an old version of React where your test framework can never know when the last render happened because you depend on a large number of components which don't believe they'd run on the current react but probably would if you could just vendorize 30 or so packages and patch their package.json files.

Or depending on a test framework that refuses to look up components by class, id or selector because they want to force you to use aria, even when it doesn't make sense such as in three.js.

Or depending on a routing framework that doesn't get maintained, instead they've been through 7 incompatible versions of it which leaves me thinking that they didn't ever believe in what they were doing.

Or having to understand the internals of 5 CSS frameworks (including JS-heavy frameworks like Emotion) to handle all the components you've sucked in and still understand raw CSS through-and-through to fill the gaps.

I worked on one system which was frankly experimental at a startup that was doing two week sprints building a tool called "Themis" for building ML training sets. The thing was that we were always having to add new tasks and between Docker and an overengineered back end and front end it took 20 minutes to go from source code to being able to interact with the thing, so it took a 20 person team and lots of coordination between FE and BE engineers to do the simplest things.

I sketched out an alternative called "Nemesis" which grew into an HTMX-based system where it takes one programmer an hour to code a task and there is no build, and between Flask and the 15-or-so helpers it is easy. I've hacked it to be an RSS reader, an image sorter, and several other centaurs:

https://mastodon.social/@UP8/114887102728039235

this feels like a desktop app when I am on the LAN and loads well under a second on a mobile hotspot the first time and every time. The key is that the tasks are nearly completely independent of each other, there are no builds and no dependencies, so writing a new task can't break old tasks. That system has plenty of screens that use d3.js for awesome visualizations and if I wanted to make a task that did something complicated which would really deserve React or Svelte or something I could do it, again, without breaking the the other tasks.

	▲	wredcoll 4 days ago \| parent [-]
		> I sketched out an alternative called "Nemesis" which grew into an HTMX-based system where it takes one programmer an hour to code a task and there is no build, and between Flask and the 15-or-so helpers it is easy My argument here is basically creating that is really, really hard, and there's no framework or library that will make it easy. React and friends are a mess because they're dealing with hard problems, kinda like systemd or kubernetes. Writing code that lives entirely inside the machine is a lot easier than having to interface with the messy real world.