So you're creating some front end stuff? Here is a cruel fact for you! That awesome JavaScript you just wrote? In five years it probably won't be there, or no longer be needed.
Not that there is nothing wrong with it. The thing with JavaScript is that it keeps on evolving and the nature of code is to change. A well written code is boring and easy to replace when needs change. It might not always be replaced with a better solution, but it will be replaced as long as the project remains actively developed.
In comparison HTML is very different. With HTML you need to end up with a solid structure and foundation, it needs to be accessible and good for search engines. There are only limited ways you can go with it. JavaScript and thus ARIA enhanced HTML gives a bit more variety and possibilities, but most often you really don't want to reinvent a thing if HTML and standards provide a working solution.
Once you've written HTML that works for the use case for everyone you shouldn't have a need to change it, because change risks breaking it for some user.
The sad thing of these times is that in many tools HTML/DOM has been abstracted behind hard-to-see layers and most of your focus is on JavaScript code instead, which may also be abstracted to something different such as components and JSX.
Maybe the next project should be written with HTML and CSS being more visible, not hidden behind layers of JavaScript components.
Top comments (3)
Is that really such a bad thing? Are we not dependant on getting new projects? Isn't there value in the progress that is made in js and similar fast moving technologies?
I agree that the pace of js and web is a little over the top and most applications would probably work just as well with the technologies from 10 years ago, but having an envirement that is moving forward has it's good sites for sure :D
If you're working on projects that don't need further development then those are irrelevant to the point. In that kind of setting you use whatever you want to get it done fast, and to meet whatever the requirements. And I guess when working on continuous stream of projects you do want things to change constantly to spice it up.
Working on long term projects that continue as long as you can imagine are a bit different story. One of the issues with front end code is that you really want there to be as little of it as possible, and writing it from a JS-centric perspective results to a lot of code that shouldn't be in the front end. This code has maintenance and performance worries and when development continues for multiple years it really starts to hurt. It would be much better to not create the problem in the first place by greatly diminishing use of JS on the browser side.
When you say it like that, I can see the problem/frustration more clearly :D