7 ms·

Current front end dev, here. My employer pays me to write JS, have been doing it for +4 years. I've become comfortable with the fact that JS never stops changi

Current front end dev, here. My employer pays me to write JS, have been doing it for +4 years. I've become comfortable with the fact that JS never stops changing (note the use of the word changing, not improving). I concern myself with fundamentals, not framework-flavor-of-the-month. I encourage others to focus on the same. What I am not comfortable with is the stubbornly-held strong opinions many JS devs have. Much of the time, a particular JS dev will believe their way is the one-true-way(tm) (which is a problem among a lot technologists in general). JS devs are the JS fatigue...not JS itself. I get bent when JS devs judge me for not staying up to date - JS is my 9 to 5, not my life. For all the JS devs out there who hate me right now - check out Elixir, its the new "new." FWIW, my personal projects are Spring Boot and Kotlin.

PopeDotNinja 6y ago
Let me guess... doing code reviews sucks?
- game_the0ry 6y ago
  I didn't mention code reviews, nor do code reviews have anything to do with JS.
commandlinefan 6y ago
> stubbornly-held strong opinions many JS devs have ... a problem among a lot technologists in general Hmmmm... well, I might agree, but that would depend on the opinion. There was a time when all programming was done using GOTO as the sole flow-control mechanism until a guy with a stubbornly-held strong opinion named Djikstra taught us that GOTO was considered harmful. Yet it's also the most natural way to code: a lot of people argued with him (in fact, the reason beginners don't use GOTO any more is just because it's not there, not because they've gotten more sophisticated). It's also a stubbornly-held strong opinion among many, but too few, developers, that global variables are also harmful. Unfortunately they're also the simplest, most obvious way to code, so a lot of developers default to using them. If a developer has a stubbornly-held strong opinion, I usually give them the benefit of the doubt to try to figure out why: often they have a good reason. (On the other hand, sometimes the reason is, "it's easiest", like using public static variables in Java).
- game_the0ry 6y ago
  Agreed. Well-reasoned stubborn opinions that are fleshed out through critical thinking are examples of good opinions. The stubborn opinions from fads, not so much. Those opinions try to signal - 'I am the smartest because I know the latest and greatest.'
- jacoblambda 6y ago
  The GOTO topic is an interesting one because Dijkstra inadvertently started a cult around the avoidance of GOTO. Dijkstra never intended this and one of the main reasons this occurred was because Dijkstra's original paper "A Case Against the Goto Statement" was editorialised as a letter to the author type article to speed up publication which resulted in the famous title "Goto Statement Considered Harmful". This is a topic where both him and other prominent figures such as Donald Knuth have since its publication repeatedly argued for moderation in use of the GOTO statement and against the total avoidance of GOTOs. My go to example for this is that in C and other languages that lack modern comforts such as exceptions(for better or worse) and destructors, GOTOs can largely simplify the handling of clean-up and error recovery code. Another example is longjmp which is very useful in kernel-space or bare metal programming, and in implementation details for exception handling however outside of those niches, serves no purpose. GOTO serves a very useful niche but can also make code nigh impossible to follow. Most other structured programming statements have the same threat but we have rules in place to avoid their abuse. The following cases can result in code that is just as problematic: IF/ELSEIF/ELSE: overly large, overly nested, or mutating variables. SWITCH/CASE: complicated fall-through. FOR: mutating counter variables, mutating termination condition. TRY/CATCH/FINALLY/THROW: exception hell/deep uncaught exceptions. These control flow mechanisms should definitely be preferred to GOTO in most cases but they can be just as badly abused if you aren't careful. The big difference I find is that people are taught how not to abuse these mechanisms but most material about the proper uses of GOTO is almost taboo because of the cargo cult around avoiding its use. Sorry if this doesn't really fit into the discussion but it's interesting to me how an initially very tame and rational counter-argument spawned a massive cargo cult.
  - marcosdumay 6y ago
gorpomon 6y ago
There's still a lot of magic floating around in code bases. I still see window passed into functions in the name of efficiency. You'll still see all sorts of varied opinions on html/css efficiency. It's certainly gotten better as large frameworks have stripped out the magic code, but you can find it when you update a site that was built a few years ago.
mountainboot 6y ago
Maybe I have been in a corporate bubble, but I haven't seen much churn in the past couple of years. React is everywhere, with a smattering of Vue and Angular here and there.
- chrisco255 6y ago
  Yeah JS and the ecosystem changed far more from 2010-2015 than in the last 5 years.
  - 8bitsrule 6y ago
    Some changes in JS interpreters can be invisible. I recently noticed that an algo (that had worked for ~ 8 years in multiple browsers) had stopped working (for how long? in which browsers?) It (non-rigorously) distinguished 'string integers' from 'string non-integers'. No doubt the required tightening was a benefit, but the breakage was not at all visible. Luckily it was a cosmetic (non-critical) usage.
- game_the0ry 6y ago
  I have seen a lot of churn react-land alone: * instantiating with React.createClass(), then es6 class components, with functional components and higher-order components, now react hooks * state management, with flux, then redux and mobx, and now context API * bundling with webpack or rollup * types with flow and typescript I could go on. I am sure there's more I am not even aware of.
  - chrisco255 6y ago
    Yeah, but swapping out redux for `useReducer` doesn't require you to relearn the core concepts of React. The move from `React.createClass` to `es6` was clearly driven by the JS standards themselves evolving. At any rate, you're not having to rearchitect your whole React app for any of these changes. If you're still using Redux, that's cool, it's not necessary for you to swap it out and state management was never prescribed by React in the first place.
torartc 6y ago
> What I am not comfortable with is the stubbornly-held strong opinions many JS devs have. Meanwhile having your own stubbornly held strong opinions.
- game_the0ry 6y ago
  Guilty on strong opinions, but loosely held. Example - at one point in my career, I wanted to Node all the backends and hated Java. Now I like Java. I am also starting to dig Elixir. I'm sure that will change again.
ravenstine 6y ago
> (note the use of the word changing, not improving) I find it interesting that you say that. Has JavaScript changed for the worse? That's not how I've seen it, since a lot of problems like the lack of real modules, no async/await, lack of syntactic sugar for "classes", no `for (const x of y)`, weird variable scoping, no constants, bound functions(i.e. fat arrow functions), have been solved. I can't see how JS has gotten worse. Some parts of the community are worse, perhaps. It's been years since React has been released, and people still seem to believe that React should be used for anything and is the only tool for any "serious" web development.(I'm not ragging on React itself, but the people who treat it like the new jQuery) Overall, JS devs are still trying to out-innovate each other by monkey-branching paradigms, which I think is the real churn with JS. I guess that's related to your final statement. The perceived churn of JS to me is self imposed to some extent. I've been doing Ember development exclusively for the last 4 years and haven't had a problem finding employment or contract work. If I can make a living working with what people consider a "dead" framework, then that's a sign that you don't need to chase the latest and greatest JS fad.
- wwright 6y ago
  FWIW, many people have the opinion that classes were a bad design. (I’m of the opinion that closures and anonymous objects do everything you’d need from a class, but better.) The other language improvements are definitely unanimous wins though.
- game_the0ry 6y ago
  > Has JavaScript changed for the worse? Clarification - I don't think JS has changed for the worse, but I do not think it is clear that all the changes have been for the better, both for the language and the ecosystem. I see it as a double edged sword. Take the example of handling asynchronous operations - async/await is good solution for that. But now you will be working in code bases with callbacks, promises, async/await, and possibly even generators - with generators being an example of an area that was not a clear improvement in the right direction, but an experiment now obsolete because of async/await. I'm a fan of improvement, but nowadays I try not to pick up the latest trend for concern that it might be obsolete in the near future. You demonstrate this - you picked something you like (ember) and just stuck with it. Ember solves problems, it works, no reason to refactor your ember projects to react.
hughrlomas 6y ago
As someone who has been working primarily with JS since the "First Age" of this article, I can say that from my perspective things have improved by orders of magnitude. New language features are obvious improvements. The paradigm shift from imperative UI management like jQuery to declarative UI management like React has eliminated entire categories of concerns. Almost everything you see mentioned in the "Second Age" might be easy to take for granted if you've recently arrived, but they have not always been there. While they are not perfect, to say things haven't improved is shortsighted. From the high-level view we are making major strides. It's an iterative process, where some things win out, new ideas and "flavors of the month" gain footing or wither and die. jQuery for example had competition from mootools, prototype.js, and others, but jQuery established dominance for a variety of reasons. It won mind-share by being the best implementation to solve a class of problems the community was tackling at the time.
schwartzworld 6y ago
> I concern myself with fundamentals, not framework-flavor-of-the-month. The whole framework-of-the-month thing is a meme. The overwhelming majority of companies use Angular, React or (to a lesser extent, Vue). There hasn't been a serious new framework in years, except maybe Svelte, which hasn't really caught on. > What I am not comfortable with is the stubbornly-held strong opinions many JS devs have. Much of the time, a particular JS dev will believe their way is the one-true-way(tm) (which is a problem among a lot technologists in general). so...not actually a problem with JavaScript if it's a problem among "technologists in general" > I get bent when JS devs judge me for not staying up to date - JS is my 9 to 5, not my life. I'm a professional JS dev too. I don't study it on my own time, but reserve a portion of my work time for keeping up to date with language changes. Maybe nobody is paying you to do that explicitly, but having a modern JS vocabulary could mean the difference between getting the next job or not, or how much you get paid. when I got hired at my current job it took me 2 days to start being productive because they were writing modern React and I was used to the current paradigms. I'm so tired of devs online ranting about how the problem with JS is that everybody expects them to keep learning new things. Do what you want, but keep that "JS devs are the problem" stuff to yourself. Maybe you'd be happier writing BASIC with GOTOs
rorykoehler 6y ago
Something that bothers me about working on node is that there is no consensus for basic stuff. Too much time on new projects is spent on reinventing the wheel and getting the team to agree to a standard.

PopeDotNinja 6y ago

Let me guess... doing code reviews sucks?

game_the0ry 6y ago
I didn't mention code reviews, nor do code reviews have anything to do with JS.

commandlinefan 6y ago

> stubbornly-held strong opinions many JS devs have ... a problem among a lot technologists in general Hmmmm... well, I might agree, but that would depend on the opinion. There was a time when all programming was done using GOTO as the sole flow-control mechanism until a guy with a stubbornly-held strong opinion named Djikstra taught us that GOTO was considered harmful. Yet it's also the most natural way to code: a lot of people argued with him (in fact, the reason beginners don't use GOTO any more is just because it's not there, not because they've gotten more sophisticated). It's also a stubbornly-held strong opinion among many, but too few, developers, that global variables are also harmful. Unfortunately they're also the simplest, most obvious way to code, so a lot of developers default to using them. If a developer has a stubbornly-held strong opinion, I usually give them the benefit of the doubt to try to figure out why: often they have a good reason. (On the other hand, sometimes the reason is, "it's easiest", like using public static variables in Java).

game_the0ry 6y ago
Agreed. Well-reasoned stubborn opinions that are fleshed out through critical thinking are examples of good opinions. The stubborn opinions from fads, not so much. Those opinions try to signal - 'I am the smartest because I know the latest and greatest.'
jacoblambda 6y ago
The GOTO topic is an interesting one because Dijkstra inadvertently started a cult around the avoidance of GOTO. Dijkstra never intended this and one of the main reasons this occurred was because Dijkstra's original paper "A Case Against the Goto Statement" was editorialised as a letter to the author type article to speed up publication which resulted in the famous title "Goto Statement Considered Harmful". This is a topic where both him and other prominent figures such as Donald Knuth have since its publication repeatedly argued for moderation in use of the GOTO statement and against the total avoidance of GOTOs. My go to example for this is that in C and other languages that lack modern comforts such as exceptions(for better or worse) and destructors, GOTOs can largely simplify the handling of clean-up and error recovery code. Another example is longjmp which is very useful in kernel-space or bare metal programming, and in implementation details for exception handling however outside of those niches, serves no purpose. GOTO serves a very useful niche but can also make code nigh impossible to follow. Most other structured programming statements have the same threat but we have rules in place to avoid their abuse. The following cases can result in code that is just as problematic: IF/ELSEIF/ELSE: overly large, overly nested, or mutating variables. SWITCH/CASE: complicated fall-through. FOR: mutating counter variables, mutating termination condition. TRY/CATCH/FINALLY/THROW: exception hell/deep uncaught exceptions. These control flow mechanisms should definitely be preferred to GOTO in most cases but they can be just as badly abused if you aren't careful. The big difference I find is that people are taught how not to abuse these mechanisms but most material about the proper uses of GOTO is almost taboo because of the cargo cult around avoiding its use. Sorry if this doesn't really fit into the discussion but it's interesting to me how an initially very tame and rational counter-argument spawned a massive cargo cult.
- marcosdumay 6y ago

gorpomon 6y ago

There's still a lot of magic floating around in code bases. I still see window passed into functions in the name of efficiency. You'll still see all sorts of varied opinions on html/css efficiency. It's certainly gotten better as large frameworks have stripped out the magic code, but you can find it when you update a site that was built a few years ago.

mountainboot 6y ago

Maybe I have been in a corporate bubble, but I haven't seen much churn in the past couple of years. React is everywhere, with a smattering of Vue and Angular here and there.

chrisco255 6y ago
Yeah JS and the ecosystem changed far more from 2010-2015 than in the last 5 years.
- 8bitsrule 6y ago
  Some changes in JS interpreters can be invisible. I recently noticed that an algo (that had worked for ~ 8 years in multiple browsers) had stopped working (for how long? in which browsers?) It (non-rigorously) distinguished 'string integers' from 'string non-integers'. No doubt the required tightening was a benefit, but the breakage was not at all visible. Luckily it was a cosmetic (non-critical) usage.
game_the0ry 6y ago
I have seen a lot of churn react-land alone: * instantiating with React.createClass(), then es6 class components, with functional components and higher-order components, now react hooks * state management, with flux, then redux and mobx, and now context API * bundling with webpack or rollup * types with flow and typescript I could go on. I am sure there's more I am not even aware of.
- chrisco255 6y ago
  Yeah, but swapping out redux for `useReducer` doesn't require you to relearn the core concepts of React. The move from `React.createClass` to `es6` was clearly driven by the JS standards themselves evolving. At any rate, you're not having to rearchitect your whole React app for any of these changes. If you're still using Redux, that's cool, it's not necessary for you to swap it out and state management was never prescribed by React in the first place.

torartc 6y ago

> What I am not comfortable with is the stubbornly-held strong opinions many JS devs have. Meanwhile having your own stubbornly held strong opinions.

game_the0ry 6y ago
Guilty on strong opinions, but loosely held. Example - at one point in my career, I wanted to Node all the backends and hated Java. Now I like Java. I am also starting to dig Elixir. I'm sure that will change again.

ravenstine 6y ago

> (note the use of the word changing, not improving) I find it interesting that you say that. Has JavaScript changed for the worse? That's not how I've seen it, since a lot of problems like the lack of real modules, no async/await, lack of syntactic sugar for "classes", no `for (const x of y)`, weird variable scoping, no constants, bound functions(i.e. fat arrow functions), have been solved. I can't see how JS has gotten worse. Some parts of the community are worse, perhaps. It's been years since React has been released, and people still seem to believe that React should be used for anything and is the only tool for any "serious" web development.(I'm not ragging on React itself, but the people who treat it like the new jQuery) Overall, JS devs are still trying to out-innovate each other by monkey-branching paradigms, which I think is the real churn with JS. I guess that's related to your final statement. The perceived churn of JS to me is self imposed to some extent. I've been doing Ember development exclusively for the last 4 years and haven't had a problem finding employment or contract work. If I can make a living working with what people consider a "dead" framework, then that's a sign that you don't need to chase the latest and greatest JS fad.

wwright 6y ago
FWIW, many people have the opinion that classes were a bad design. (I’m of the opinion that closures and anonymous objects do everything you’d need from a class, but better.) The other language improvements are definitely unanimous wins though.
game_the0ry 6y ago
> Has JavaScript changed for the worse? Clarification - I don't think JS has changed for the worse, but I do not think it is clear that all the changes have been for the better, both for the language and the ecosystem. I see it as a double edged sword. Take the example of handling asynchronous operations - async/await is good solution for that. But now you will be working in code bases with callbacks, promises, async/await, and possibly even generators - with generators being an example of an area that was not a clear improvement in the right direction, but an experiment now obsolete because of async/await. I'm a fan of improvement, but nowadays I try not to pick up the latest trend for concern that it might be obsolete in the near future. You demonstrate this - you picked something you like (ember) and just stuck with it. Ember solves problems, it works, no reason to refactor your ember projects to react.

hughrlomas 6y ago

As someone who has been working primarily with JS since the "First Age" of this article, I can say that from my perspective things have improved by orders of magnitude. New language features are obvious improvements. The paradigm shift from imperative UI management like jQuery to declarative UI management like React has eliminated entire categories of concerns. Almost everything you see mentioned in the "Second Age" might be easy to take for granted if you've recently arrived, but they have not always been there. While they are not perfect, to say things haven't improved is shortsighted. From the high-level view we are making major strides. It's an iterative process, where some things win out, new ideas and "flavors of the month" gain footing or wither and die. jQuery for example had competition from mootools, prototype.js, and others, but jQuery established dominance for a variety of reasons. It won mind-share by being the best implementation to solve a class of problems the community was tackling at the time.

schwartzworld 6y ago

> I concern myself with fundamentals, not framework-flavor-of-the-month. The whole framework-of-the-month thing is a meme. The overwhelming majority of companies use Angular, React or (to a lesser extent, Vue). There hasn't been a serious new framework in years, except maybe Svelte, which hasn't really caught on. > What I am not comfortable with is the stubbornly-held strong opinions many JS devs have. Much of the time, a particular JS dev will believe their way is the one-true-way(tm) (which is a problem among a lot technologists in general). so...not actually a problem with JavaScript if it's a problem among "technologists in general" > I get bent when JS devs judge me for not staying up to date - JS is my 9 to 5, not my life. I'm a professional JS dev too. I don't study it on my own time, but reserve a portion of my work time for keeping up to date with language changes. Maybe nobody is paying you to do that explicitly, but having a modern JS vocabulary could mean the difference between getting the next job or not, or how much you get paid. when I got hired at my current job it took me 2 days to start being productive because they were writing modern React and I was used to the current paradigms. I'm so tired of devs online ranting about how the problem with JS is that everybody expects them to keep learning new things. Do what you want, but keep that "JS devs are the problem" stuff to yourself. Maybe you'd be happier writing BASIC with GOTOs

rorykoehler 6y ago

Something that bothers me about working on node is that there is no consensus for basic stuff. Too much time on new projects is spent on reinventing the wheel and getting the team to agree to a standard.