4 ms·

oh yeah another thing: a lot of the crapiness today is from people jumping into the near-impossible _before_ the near-impossible becomes very-feasible (usually

oh yeah another thing: 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.

PaulHoule 3y ago
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.
- DanielHB 3y ago
  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: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog https://developer.mozilla.org/en-US/docs/Web/HTML/Element/di... And suddenly dozens of libraries die in agonising cleansing fire.

PaulHoule 3y ago

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.

DanielHB 3y ago
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: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog https://developer.mozilla.org/en-US/docs/Web/HTML/Element/di... And suddenly dozens of libraries die in agonising cleansing fire.