Web Development Is Getting Too Complex, and It May Be Our Fault
smashingmagazine.com
smashingmagazine.com
There are so many things today that were effectively impossible (or MUCH harder) only a few years ago, for example flexbox in CSS is complex, but it makes centering divs and complex page layouts feasible.
You as a developer or organisation kinda need to use the near-impossible stack to stay relevant, even if your task in of itself is not near-impossible. Because : - Increased standards from your users, because other products are on the near-impossible scale - Hirability for your devs, otherwise they leave - Hirability for your company otherwise they can't find people
But there are things like standards, frameworks, tools, managed services, increased hardware power, documentation/community that also reduces the complexity. But it does seem that complexity grows faster than these other things can reduce it, in part because of the leaky-abstraction problem.
And this is not a frontend problem, happens with backend all the time as well. Microservices and queues and k8 and so on. Even in embedded systems with linux becoming more prevalent compared to raw micro-controllers and 7-segment displays.
The crappiness people keep getting pissed of about today is about the near-impossible being done when it doesn't need to be done to achieve a task.
a lot of the crapiness today is from people jumping into the near-impossible _before_ the near-impossible becomes very-feasible (usually through better standards). Software can stick around for years or decades and I see so many codebases with archeological layers of abandoned coding patterns, software tools and so on.
For example, I see all this server-side rendering JS stuff going on at the moment and I am very, very unwilling to push code out that uses it. Even within NextJS they are deprecating APIs all the time and keeping up with it is exhausting and I don't even know if NextJS is going to become the de-facto standard for the next 10 years (for a while AngularJS seemed like it was going to become the SPA standard). Or maybe SSR will go out of fashion because people don't really need it, who knows.
People write a lot of form applications in React and many people complain that this is overkill and that HTML 5 forms plus an old-school back end like we used to write in 1999 is enough. My problem with it there is the tension between controlled and uncontrolled forms; I use controlled forms a lot because I know how to make them do anything but I think there's a market for a really disciplined approach to uncontrolled forms. Or maybe we just need a richer language for forms.
Back in 2006 or so I was already writing Javascript applications that were a lot like Figma in that you could edit graphical displays of information simultaneously with a lot of users. Back then there was not await/async and not a lot of information about how you update an app like that. In my mind though React lacks the disciplined approach of updating applications state based on user inputs and information coming from the network. I've yet to see a framework for that that I really like.
Some of these competing implementations are meant to make very complex forms feasible, but they are not standard. Being not standard makes the cognitive load a lot higher to bring them into your project. People might not know the lib you use, they might argue it is overkill, they might want to swap it out for their own pet library, since it is not widely used it might have more bugs...
So what we actually need is better raw base elements in HTML. For forms, more powerful elements/attributes that allow you to keep them non-controlled in React. If they were better we wouldn't need so much tooling on top of it and applications would behave more similarly to each other. In short, better standardisation means less cognitive load.
There is a reason why JS is getting so popular in backend and mobile apps. It is because it is _less_ cognitive load for your team because your web frontend already needs to use it.
Now replace Forms with DatePickers, (Multi)Select, Menus, Popups, etc. Popups are actually becoming standard though:
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/di...
And suddenly dozens of libraries die in agonising cleansing fire.
I'm starting to learn Nextjs, React and Svelte, but there's sooooooo much to figure out.
I don't envy someone new trying to figure out what to do though.
which you can visit in a web browser or with a VR headset.
This is based on A-Frame
https://aframe.io/docs/1.5.0/introduction/
which like HTMX on drugs: you bring some Javascript in from unpkg, React and three.js are under the hood, but you don't need webpack or any of that. It defines new HTML elements similar to the elements of VRML, but it implements a real entity-component-system framework like Unity so it can accomplish most of what you see in a 3-d game. It seems to me to be very simple for something that gives me so much power.