4 ms·

I don't quite get the frustration. Learn one set of tools really well. Make sure it's here to stay, mature, and has a large community. My fav is Nextjs, but it

I don't quite get the frustration. Learn one set of tools really well. Make sure it's here to stay, mature, and has a large community. My fav is Nextjs, but it could be anything. Make sure it comes with everything you need, including a CLI to set up your project. Stay as close as possible to what the stack gives you. Don't build on top of it, unless you're willing to upgrade constantly. Avoid configuring your build system yourself, unless the framework gives you clearly defined escape hatches. (Like Next does.) Learn the underlying fundamentals. Learn about algos and data structures. That will be relevant forever. Most importantly, ignore these "20 state management libraries you should learn in 2021" articles. They are poison. And nobody cares.

richeyryan 6y ago
Surely this line of thinking has the potential to lead to "I know NextJS best so every problem looks like a NextJS problem" ? If you limit yourself to the surface area of one tool, you become reliant on the authors of that tool to solve the problems you need solved. Then if that tool declines for some reason you have to look for another tool that solves all the same set of problems for you. Not to mention you'll probably find your job opportunities limited if you're all in on one tool. I think you are spot on when you say learn the underlying fundamentals but that should be extended to the web platform. Learn how to manage state outside of your favorite library. Learn how to cache your assets and HTTP responses using service workers. Learn the general ideas behind MVVM views so you can look at another library, get the gist and get going. My best lecturer in college told us that he wasn't teaching us specific algorithms or MVC or the DOM APIs. He was teaching us how to learn. That there are common patterns and fundamentals and "new" things are usually similar to existing things in some way. Usually when I see some new frontend library, I see a concept that has been recycled or stolen from some other library and presented as new. I don't believe there is much novel work being done put out there. Even stuff that qualifies as somewhat novel like Svelte is really just a refinement of the road React started us down. It probably takes a bit of work, and sometimes luck, to figure out what's transient and whats important universal stuff but once you start looking at things that way, it makes it a lot easier to appraise the new stuff and figure out if its worth your time or not. Then if you need to solve a problem its not about how NextJS can be twisted to fit it but just taking the components you need and assembling them in a way that makes sense. Maybe this approach just requires more learning than is reasonable for most people, I don't know. I personally like learning, seeing what makes things tick and how everything fits together.
- gherkinnn 6y ago
  Yes, you are right. I might have phrased it without looking at it over a longer term.
mattmanser 6y ago
Are you too young to have missed the mootools > jquery > handlebar > mustache > backbone > knockout > angular > react years? Or have you already forgotten that what is "here to stay, mature, and has a large community" seems to change every few years in javascript?
- Klonoar 6y ago
  To be fair, you could have gone through those years with an every-other approach: I know I basically did - Very late MooTools (almost none) - jQuery - Backbone - React It's not like these projects shift community blessing that quickly; it might feel like it, but these things in reality are well supported past their "peak" for at least a year or so. Your projects will still work. If you have enough of a handle on vanilla JS, these changes weren't really too obstructive. I think that's probably the most important message for the JS community here: change can be fine, good, even - but change doesn't need to happen at warpspeed.
alephu5 6y ago
On the frontend I try to stick to react as much as possible, for SPAs of course but also static-sites through Gatsby or mobile applications with react-native. This isn't through devotion, I just find it easy to work with and do what I want to do, plus the wealth of high-quality components that I can just pull in is a major bonus. Maybe it's because I lack skill but I struggle with raw browser languages. I fight with CSS and it the end it always looks and feels clunky, and HTML doesn't offer any solutions for component reuse. I've worked with pug to get consistent interfaces, but it's still a bit clunky. Funnily enough I don't mind raw DOM manipulation with JS or using jQuery but overall am still more productive with react. Regarding the state management solutions (and hype generally) I think it's worthwhile being aware that they exist. My suggestion is to know what they're for but resist the urge to just "try them out" even if a potential use-case arises. When you're tearing your hair out trying to do something using your current toolbox, consider the appropriate technologies in your reading list (mobX, redux, kubernetes, etc.) and try them out on your toughest problem. Going the opposite direction is recommended too, remove redux/MobX where a simple useState passed down from the parent will do.

richeyryan 6y ago

Surely this line of thinking has the potential to lead to "I know NextJS best so every problem looks like a NextJS problem" ? If you limit yourself to the surface area of one tool, you become reliant on the authors of that tool to solve the problems you need solved. Then if that tool declines for some reason you have to look for another tool that solves all the same set of problems for you. Not to mention you'll probably find your job opportunities limited if you're all in on one tool. I think you are spot on when you say learn the underlying fundamentals but that should be extended to the web platform. Learn how to manage state outside of your favorite library. Learn how to cache your assets and HTTP responses using service workers. Learn the general ideas behind MVVM views so you can look at another library, get the gist and get going. My best lecturer in college told us that he wasn't teaching us specific algorithms or MVC or the DOM APIs. He was teaching us how to learn. That there are common patterns and fundamentals and "new" things are usually similar to existing things in some way. Usually when I see some new frontend library, I see a concept that has been recycled or stolen from some other library and presented as new. I don't believe there is much novel work being done put out there. Even stuff that qualifies as somewhat novel like Svelte is really just a refinement of the road React started us down. It probably takes a bit of work, and sometimes luck, to figure out what's transient and whats important universal stuff but once you start looking at things that way, it makes it a lot easier to appraise the new stuff and figure out if its worth your time or not. Then if you need to solve a problem its not about how NextJS can be twisted to fit it but just taking the components you need and assembling them in a way that makes sense. Maybe this approach just requires more learning than is reasonable for most people, I don't know. I personally like learning, seeing what makes things tick and how everything fits together.

gherkinnn 6y ago
Yes, you are right. I might have phrased it without looking at it over a longer term.

mattmanser 6y ago

Are you too young to have missed the mootools > jquery > handlebar > mustache > backbone > knockout > angular > react years? Or have you already forgotten that what is "here to stay, mature, and has a large community" seems to change every few years in javascript?

Klonoar 6y ago
To be fair, you could have gone through those years with an every-other approach: I know I basically did - Very late MooTools (almost none) - jQuery - Backbone - React It's not like these projects shift community blessing that quickly; it might feel like it, but these things in reality are well supported past their "peak" for at least a year or so. Your projects will still work. If you have enough of a handle on vanilla JS, these changes weren't really too obstructive. I think that's probably the most important message for the JS community here: change can be fine, good, even - but change doesn't need to happen at warpspeed.

alephu5 6y ago

On the frontend I try to stick to react as much as possible, for SPAs of course but also static-sites through Gatsby or mobile applications with react-native. This isn't through devotion, I just find it easy to work with and do what I want to do, plus the wealth of high-quality components that I can just pull in is a major bonus. Maybe it's because I lack skill but I struggle with raw browser languages. I fight with CSS and it the end it always looks and feels clunky, and HTML doesn't offer any solutions for component reuse. I've worked with pug to get consistent interfaces, but it's still a bit clunky. Funnily enough I don't mind raw DOM manipulation with JS or using jQuery but overall am still more productive with react. Regarding the state management solutions (and hype generally) I think it's worthwhile being aware that they exist. My suggestion is to know what they're for but resist the urge to just "try them out" even if a potential use-case arises. When you're tearing your hair out trying to do something using your current toolbox, consider the appropriate technologies in your reading list (mobX, redux, kubernetes, etc.) and try them out on your toughest problem. Going the opposite direction is recommended too, remove redux/MobX where a simple useState passed down from the parent will do.