4 ms·

> If I am looking for a job as a Javasript developer at the moment it is not about my coding skills, it is about my willingness to adopt all those hyped technol

by pluma 9y ago

> If I am looking for a job as a Javasript developer at the moment it is not about my coding skills, it is about my willingness to adopt all those hyped technologies If you're looking for a job as a developer I hope it's always about your ability to adopt to changes and new technologies. Because that's what distinguishes a developer from somebody's "nephew who's really good with computers" and is willing to work for scraps. Any formal education worth its salt is about giving you that ability rather than just teaching you the status quo. If you want a stable ecosystem that doesn't change, try specializing in legacy technologies. There's still a ton of software written in languages that are well past their prime and large companies will pay good money for people willing and capable of working on that. Maybe you should stay away from JavaScript for the next 20 years and come back when people consider it quaint and archaic and don't try to apply new ideas to it anymore. This isn't hyperbole, this is an honest suggestion.

blub 9y ago
Sure, but adapting as a JS developer is mostly about relearning how to do the same thing using different libraries and frameworks. As an embedded developer I am able to build upon my existing knowledge and am deepening my skills in embedded, Linux, C++, etc. I'm not learning new programming languages and operating systems every couple of months. And this is how it should be, otherwise you'll end up being always average, no matter how much you learn.
- slfnflctd 9y ago
  > relearning how to do the same thing using different libraries and frameworks This is hell to me, such nausea-inducing inefficiency. I feel like I'm wasting my time and cluttering my brain needlessly in those scenarios and it drives me mad. What if you were a woodworker and every few months all the tools and equipment in your shop changed in various subtle ways? It makes very little sense to me in the long run. True mastery depends upon some amount of consistency in your environment. It's the only way you can build on what you knew before (because it didn't change when you weren't looking) to do more complex and interesting things.
  - snerbles 9y ago
    But think of all the sweet conference talks you can give after inventing the latest new shiny woodworking tool!
- pluma 9y ago
  Direct DOM manipulation. Event delegation. MVC. MVP. MVVM. Component trees. These aren't libraries, they're not unique to JS. I've been doing frontend development since the 1990s and in many cases I could still solve the same problems very similarly to how I solved them 10 years ago (except I would probably forego jQuery and use the web APIs directly thanks to widespread browser support). The reason I instead spent my time learning Backbone and Knockout and Angular and React is that the kind of problems I'm solving has changed over the years. Your characterization is also hyperbolic. You don't learn an entirely new way to do exactly the same thing and throw all the old knowledge away. Learning Backbone informed how I used Knockout, learning Knockout helped me better understand Angular, having used Angular I know what problems to avoid in React. All of it helped me build intuitions about possible caveats when looking at new tools and libraries. I mostly don't write Angular code anymore. I haven't touched Knockout in years now. My contact with Backbone is also fairly minimal these days. But learning each of them made it easier both to learn new things in general and to understand other libraries better. Also, React is the odd one out here. To fully understand Angular (1.x that is), I had to learn about its internals and unique concepts and terminology that are mostly orthogonal to my application but vital to avoid certain mistakes. With Backbone and Knockout the overhead was smaller but a lot of the effort in gaining proficiency was spent learning their quirks and idioms. With React there was some of that initially but all effort beyond that went into language features that come in handy outside of React and concepts that are useful beyond React or JavaScript.
- tracker1 9y ago
  When wasn't it like this.. raw js, NN4 DOM, IE4 DOM, W3C DOM, Prototype.js, mootools, jQuery, extjs, etc. C/C++ also haven't sat still either, there are always new hotness in any language. For a language that interacts with UI asynchronously, JS has moved in a direction that tends to make it easier to user, even if it changes in the common use case. I remember the bad old days in the mid-late 90's, I'll take today's JS ecosystem.
Daishiman 9y ago
Dude, Django and Rails have basically improved in their tech while staying conceptually sound and approachable. This is a cop-out. You pretty much have to relearn the JS environment every other year. It's a colossal waste of time that only junior people would be willing to tolerate for a marginal (if any) productivity gain.
- pluma 9y ago
  > Django and Rails Django's deprecation policy is practically the same as React's, except React provides codemods for every release, allowing you to automate code migrations. And if you think Rails hasn't changed, you've probably not been using it long enough to remember the early drama. Not to mention Django's Python 2/3 conundrum (also class-based views). Heck, Django's development on top of Python's is aptly comparable to e.g. React's on top of ES.
  - Daishiman 9y ago
    So what? React is one library in the ginormous pile of tiny little dependencies that come with any JS project that's large enough, and those don't have the same policy and are subject to the incessant churn of the ecosystem. I've been using pretty much the exact same packages for a 5-year-old Django project with no need to migrate needlessly. I've had to migrate JS apps that were just one year old and tiny, and the amount of pain was far larger than upgrading a 50k LOC Django project.

by pluma 9y ago

blub 9y ago

Sure, but adapting as a JS developer is mostly about relearning how to do the same thing using different libraries and frameworks. As an embedded developer I am able to build upon my existing knowledge and am deepening my skills in embedded, Linux, C++, etc. I'm not learning new programming languages and operating systems every couple of months. And this is how it should be, otherwise you'll end up being always average, no matter how much you learn.

slfnflctd 9y ago
> relearning how to do the same thing using different libraries and frameworks This is hell to me, such nausea-inducing inefficiency. I feel like I'm wasting my time and cluttering my brain needlessly in those scenarios and it drives me mad. What if you were a woodworker and every few months all the tools and equipment in your shop changed in various subtle ways? It makes very little sense to me in the long run. True mastery depends upon some amount of consistency in your environment. It's the only way you can build on what you knew before (because it didn't change when you weren't looking) to do more complex and interesting things.
- snerbles 9y ago
  But think of all the sweet conference talks you can give after inventing the latest new shiny woodworking tool!
pluma 9y ago
Direct DOM manipulation. Event delegation. MVC. MVP. MVVM. Component trees. These aren't libraries, they're not unique to JS. I've been doing frontend development since the 1990s and in many cases I could still solve the same problems very similarly to how I solved them 10 years ago (except I would probably forego jQuery and use the web APIs directly thanks to widespread browser support). The reason I instead spent my time learning Backbone and Knockout and Angular and React is that the kind of problems I'm solving has changed over the years. Your characterization is also hyperbolic. You don't learn an entirely new way to do exactly the same thing and throw all the old knowledge away. Learning Backbone informed how I used Knockout, learning Knockout helped me better understand Angular, having used Angular I know what problems to avoid in React. All of it helped me build intuitions about possible caveats when looking at new tools and libraries. I mostly don't write Angular code anymore. I haven't touched Knockout in years now. My contact with Backbone is also fairly minimal these days. But learning each of them made it easier both to learn new things in general and to understand other libraries better. Also, React is the odd one out here. To fully understand Angular (1.x that is), I had to learn about its internals and unique concepts and terminology that are mostly orthogonal to my application but vital to avoid certain mistakes. With Backbone and Knockout the overhead was smaller but a lot of the effort in gaining proficiency was spent learning their quirks and idioms. With React there was some of that initially but all effort beyond that went into language features that come in handy outside of React and concepts that are useful beyond React or JavaScript.
tracker1 9y ago
When wasn't it like this.. raw js, NN4 DOM, IE4 DOM, W3C DOM, Prototype.js, mootools, jQuery, extjs, etc. C/C++ also haven't sat still either, there are always new hotness in any language. For a language that interacts with UI asynchronously, JS has moved in a direction that tends to make it easier to user, even if it changes in the common use case. I remember the bad old days in the mid-late 90's, I'll take today's JS ecosystem.

Daishiman 9y ago

Dude, Django and Rails have basically improved in their tech while staying conceptually sound and approachable. This is a cop-out. You pretty much have to relearn the JS environment every other year. It's a colossal waste of time that only junior people would be willing to tolerate for a marginal (if any) productivity gain.

pluma 9y ago
> Django and Rails Django's deprecation policy is practically the same as React's, except React provides codemods for every release, allowing you to automate code migrations. And if you think Rails hasn't changed, you've probably not been using it long enough to remember the early drama. Not to mention Django's Python 2/3 conundrum (also class-based views). Heck, Django's development on top of Python's is aptly comparable to e.g. React's on top of ES.
- Daishiman 9y ago
  So what? React is one library in the ginormous pile of tiny little dependencies that come with any JS project that's large enough, and those don't have the same policy and are subject to the incessant churn of the ecosystem. I've been using pretty much the exact same packages for a 5-year-old Django project with no need to migrate needlessly. I've had to migrate JS apps that were just one year old and tiny, and the amount of pain was far larger than upgrading a 50k LOC Django project.