Today I started a rebuild of my website as a technical exercise.
1 working day in, and I haven't written a single line of actual html.
Do a search for "require" on npm. There are 90,000 npm packages. There's "require-dir", and "require-directory" then "require-all". Some are shims for require on the frontend, rather than for the backend.
Every other build tool has its own ecosystem of tools that shim around an existing tool. And then webpack's packages notoriously pollute the package global namespace (-loader, and slightly better -webpack-plugin).
Main problem is both the blessing and the curse of Javascript (and slightly mirrors the ongoing popularity of PHP) - there're so many resources available that it's so damn easy to get in. And it's so tempting to build YAJF/J, and even more so nowadays. And as the author mentions - there's very little community curation.
For someone who doesn't sit in the frontend stack everyday, it's quite frankly madness. It's like playing chess with a hydra. The author has problems with the React startup cost - I think it's a problem plaguing the entire js stack.
I once tried Yeoman. Angular was the hottest thing ever and I was recommended to use Yeoman to set up a template project. The damn thing downloaded 30000 files into my project. It took a while, but nothing I really noticed until I saw dropbox working for 40 minutes. I just can't take some projects seriously after that.
Anyway, compare your problems and effort to things like this:
If you're not a front end developer, then why is it a technical exercise to learn all this stuff? Personally, I don't want to learn things that will be obsolete in a few years.
I also rebuilt my website as a technical exercise, but I'm doing it in raw HTML, CSS, and JS. Literally with vim and shell scripts to build it.
I know it can meet the requirements of a personal website, and many other kinds of sites. It probably takes a little longer, but I know it's going to work in 5 years, and I will know how to maintain it.
And I will have more foundational knowledge. Things have changed a lot with HTML and CSS. I learned how to use HTML5 onHashChange. And I did my own "CSS reset" without using any libraries. I wrote my own table sorter with raw DOM manipulation.
I think you need this knowledge to help you use the framework correctly anyway.
>>If you're not a front end developer, then why is it a technical exercise to learn all this stuff?
There are many reasons. For one thing, a lot of developers are "full-stack" and don't have the luxury of focusing on just the front-end or the back-end. For another, learning new tools, frameworks and methodologies will make you a better overall developer.
>>Personally, I don't want to learn things that will be obsolete in a few years.
Better not work in web development then. It's probably the fastest moving subfield in software and there's no guarantee that what you're learning today won't be obsolete in a few years. So your best bet is to learn as much as you can, rather than putting all your eggs in one basket that you think will last a long time.
Yeah, professional web dev is not for me, though it seems I'm not the only one lamenting the state of affairs. It seems that it's not just the frameworks that are thrown away in 3 years, but sometimes the products built with them too!
I think learning new "frameworks and methodologies" only makes you a better developer to the degree that they are well thought-out. It seems like a lot of JavaScript stuff is basically still in a state of flux, where people are experimenting and figuring things out.
I spent a lot of time learning Python, C++, C, R, bash, OCaml, and HTML/CSS/JavaScript. All those things have lasting value, and I expect to be using them in 5 years, and probably most of them in 20 years.
I would say jQuery has lasting value, since it has an elegant data-driven / document-driven model. I look a new things to understand if they have lasting value. React does seem principled to me, and I was interested in playing with it, although these threads have what dampened the enthusiasm.
I am using HTML/CSS/JS to display statistics and visualizations, and it works perfectly for that. In any case, I do think there is a problem where a lot of front end devs don't actually understand the abstractions the browser presents. It's basically the same problem as Python or Ruby programmers not understanding what syscalls are and writing horrifically slow code.
1 working day in, and I haven't written a single line of actual html.
Do a search for "require" on npm. There are 90,000 npm packages. There's "require-dir", and "require-directory" then "require-all". Some are shims for require on the frontend, rather than for the backend.
Every other build tool has its own ecosystem of tools that shim around an existing tool. And then webpack's packages notoriously pollute the package global namespace (-loader, and slightly better -webpack-plugin).
Main problem is both the blessing and the curse of Javascript (and slightly mirrors the ongoing popularity of PHP) - there're so many resources available that it's so damn easy to get in. And it's so tempting to build YAJF/J, and even more so nowadays. And as the author mentions - there's very little community curation.
For someone who doesn't sit in the frontend stack everyday, it's quite frankly madness. It's like playing chess with a hydra. The author has problems with the React startup cost - I think it's a problem plaguing the entire js stack.