The messaging and available options are definitely more complex. But there are very good simple paths available to you once you know about them. You can still always directly write html, css, and js, and if you have a big complex app that needs it all of the frameworks are actually very good and have very easy ways to get up and running and deploy.
I don't envy someone new trying to figure out what to do though.
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.
I've been developing websites since the 90's and if there's one thing I've learned it's that all these vogue frameworks are just bling, sort of like Yahoo's home page, and bling while nice is not an effective substitute for lack of substance.
I don't people quite grasp that the evolving complexity is a consequence of people making the impossible possible. When someone achieves the impossible other people soon want to do it as well and tools come around to supporting those previously-impossible use cases.
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.
What I find amazing about React is what a comfortable way it is to create and use "widgets" like you'd see in a desktop application. It, as well as similar frameworks like Vue and Svelte don't have a real strategy to manage the global state of an application.
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.
Complex Forms are a solved problem within React, but it is not _standard_ so there are tons of competing implementations (from hand-rolling your own and relying mostly to a bunch of libraries that manage all sorts of things for you like touched state, validation and submission)
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:
And this is why most "non-web-developer" still end up using Wordpress for everything they need to do, because it's still the easier way to reach a working result.
I'm starting to learn Nextjs, React and Svelte, but there's sooooooo much to figure out.
15 comments
[ 3.2 ms ] story [ 49.1 ms ] threadI don't envy someone new trying to figure out what to do though.
https://gen5.info/xr/mars4/
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.
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.