4 ms·

Some scattered thoughts: Just today, I built a complex order editing form in vanilla Javascript with AJAX. It's over 900 lines of Javascript where half of the

Some scattered thoughts: Just today, I built a complex order editing form in vanilla Javascript with AJAX. It's over 900 lines of Javascript where half of the code is state management boilerplate, painstakingly ensuring the correct effects are run when the user changes an order line's quantity or picks another product. We currently can't use libraries with our stack, so it was necessary to write it like this, but it made me yearn for the frameworks. The frontend landscape isn't more complex than it needs to be, it's as complex as we need it to be. We take many things for granted in our modern stack. Sure, Javascript has come very far in many areas, but it also lacks many things that are regularly needed and the tooling covers for that. Things like state management, functional composition of layout and form validation are things that Javascript simply doesn't (and probably shouldn't) provide, and that's why we have libraries/frameworks for those. I see many people bashing on Redux in the comments section. Redux can be overkill if you're writing a single-page (like, actually one page) website, but as soon as you need to manage user credentials and state that needs to be persisted across many pages (think shopping cart), Redux becomes indispensable for me. Sure, you can use something like useReducer, but it doesn't really compare once you add redux-toolkit to the equation. I agree with the general sentiment about the npm ecosystem. Like with anything else, taking "don't reinvent the wheel" to the extreme causes chaos because the entire world is not a monorepo and we have to rely not breaking one another (which fails often). My rule of thumb for whether I should reach for an npm package is "can I write this correctly and with tests in an afternoon?". Things like arbitrary-precision decimals fail that test, but many others simply go into utils.js. To summarize my thoughts and make myself a bit more coherent: The frontend tooling is as complex as we need it to be. Evaluate what you need and build your stack with that. Don't join any cargo cults, both for and against framework use.

aka878 4y ago
“We currently can't use libraries with our stack” Interesting. Could you share the reason?
- trashburger 4y ago
  I misspoke, meant we can't use frameworks. We have Webpack setup, but the HTML is currently Django templates, and the project right now has too tight a deadline to reshape the frontend into something that more conventional frontend frameworks expect.
wildrhythms 4y ago
I agree with all of this. We are building web 'applications' now, not just websites. Users expect interactivity i.e. state management, animations, modals, dialog boxes... We have moved all of the UI patterns from the operating system into the browser, for better or for worse (probably worse). We have made front-end developers today what used to be Winforms devs, JavaFX/Swing devs, Cocoa devs... but without the basic OS UI frameworks they could build on top of before. Never mind the limitations front-end devs still have to deal with- like being asked to theme a <select> god help you!
sibeliuss 4y ago
Exactly. Things are just complex, and who wants to wire up a form library from scratch? All of the tools out there now (assuming you know which to choose) have made our lives easier, and (vastly) less bug ridden, then ever before. It's hard to know what to choose, but the domain itself is necessarily complicated.
JoeyJoJoJr 4y ago
I think it is a problem that the frameworks smooth over many issues around working with web standards, which means that less successful patterns emerge around working directly with the DOM. I suspect that amongst all of the patterns, frameworks, and learnings gained from the Nodejs era of web dev, there exists a far more cohesive and scalable way to build front-end app directly on web standards, but this mode of development can’t compete with the shear number of developers working on solutions layers above the standard platform. These solutions have an allure because they have more elegant workflows for very immediate problems (I need to update the DOM based on this state change) but the unstandardised nature of these solutions don’t really help the ecosystem advance to its potential.

aka878 4y ago

“We currently can't use libraries with our stack” Interesting. Could you share the reason?

trashburger 4y ago
I misspoke, meant we can't use frameworks. We have Webpack setup, but the HTML is currently Django templates, and the project right now has too tight a deadline to reshape the frontend into something that more conventional frontend frameworks expect.

wildrhythms 4y ago

I agree with all of this. We are building web 'applications' now, not just websites. Users expect interactivity i.e. state management, animations, modals, dialog boxes... We have moved all of the UI patterns from the operating system into the browser, for better or for worse (probably worse). We have made front-end developers today what used to be Winforms devs, JavaFX/Swing devs, Cocoa devs... but without the basic OS UI frameworks they could build on top of before. Never mind the limitations front-end devs still have to deal with- like being asked to theme a <select> god help you!

sibeliuss 4y ago

Exactly. Things are just complex, and who wants to wire up a form library from scratch? All of the tools out there now (assuming you know which to choose) have made our lives easier, and (vastly) less bug ridden, then ever before. It's hard to know what to choose, but the domain itself is necessarily complicated.

JoeyJoJoJr 4y ago

I think it is a problem that the frameworks smooth over many issues around working with web standards, which means that less successful patterns emerge around working directly with the DOM. I suspect that amongst all of the patterns, frameworks, and learnings gained from the Nodejs era of web dev, there exists a far more cohesive and scalable way to build front-end app directly on web standards, but this mode of development can’t compete with the shear number of developers working on solutions layers above the standard platform. These solutions have an allure because they have more elegant workflows for very immediate problems (I need to update the DOM based on this state change) but the unstandardised nature of these solutions don’t really help the ecosystem advance to its potential.