Hacker News Reader

Comment by twii | Hacker News Reader

Omg, so this guy thinks he knows why I'm hating Javascript? Well, it's definitely not because of the lack of types, or because without Prettier my code looks shit, neither would it be the lack of E6/ES7 features since I'm using Coffeescript 2. No, I hate Javascript especially for it's conitnuously changing ecosystem being forced upon you. You named Dan Abramov? Ah, the guy who deprecated almost all flux in favor of his own idea (Redux), or by deprecating React Mixins, because he thinks Mixins are bad, Higher Order Components is the new holy grail?

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, and the author of this article is just making it worse.

I also hate Javascript for all those people reading this that think I don't understand it yet, and are going to explain me how great ES6/ES7, Promises, and/or Typescript are. Please don't.

View on HN

> Ah, the guy who deprecated almost all flux in favor of his own idea (Redux), or by deprecating React Mixins, because he thinks Mixins are bad, Higher Order Components is the new holy grail?

How dare the man spend hours and months creating something others ended up finding so valuable they discarded their own things.

If you really prefer the bug-inducing mess that were mixins, you can still use React.createClass (with full mixin support) by using the react-create-class module: https://yarnpkg.com/en/package/create-react-class

Which, by the way, is maintained by the same people you are so upset with. For changing their mind about the API of something they gave you for free.

> 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.

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.

> 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.

But think of all the sweet conference talks you can give after inventing the latest new shiny woodworking tool!

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.

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.

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.

> 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.

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.

You sound quite fatigued! Here's what I suggest:

- Uninstall webpack for a month

- Download the few libraries that you can't live without

  * Put them in a script tag

- Disconnect from HN and Twitter. Better yet, the internet all together.

- Finish whatever you're working on in peace, and save Abramov & friends from your thoughts about how inconvenient technological progress is for you.

You've conflated needless churn with progress.

They're not the same thing.

You've somehow managed to put down the hard work of community leaders from your hind-sight high horse, and at the same time, disown responsibility for the choice of library/language your software was built on. Implying the fault is on them for doing their best to push the community forward, rather than on you for shipping software built on presumably new, unproven, and highly volatile foundations. Impressive, sir.

I guess we just disagree on what constitutes pushing the community forward.

I don't write javascript software, I merely have to experience the pain of using it.

Dan created Redux as a proof of concept experiment for a conference talk. I'm sure he did actually want people to use it, but based on comments he's made, he definitely had no idea it would became the de-facto standard state management tool for React apps. Frankly, he's spent more time telling people _not_ to use Redux if it doesn't fit their use cases than actually trying to advertise the library.

> because without Prettier my code looks shit

Prettier is a cool tool, but it's pretty trivial to press enter and tab every once and a while to format your own code.

Well, if you don't like learning then you can still use DHTML like it's 2003

You don't have to use any of the gobs of new JS syntax, libearies, frameworks, techniques, packagers etc that come out on a regular basis. Just keep that in mind when you're reading about them and realize you can decide for yourself what to adopt after careful evaluation.

Exception being if you work on a team that has agreed to adopt something new together. If you're of a different opinion and lost the debate you pretty much have two options at that point!

Huh? Why is this a problem? Just use what you like, all the old techniques still work, you could use jquery if you like, nobody's stopping you.

If your only reason to hate a language is that it's making improvements (that you can't/won't keep up with), it would seem that language is doing something right

It's not that it's improving, it's that it's changing in every direction at light speed, and if you say went on holiday for a month offline when you come back the odds that you find the syntax and the ecosystem substantially different is very high. And whether all or most of these changes are indeed improving anything is doubtful. I personally can't follow JS anymore, it's a storm of not-so-news from every direction.

Since ES6/2015 the changes have been pretty minimal, so I disagree with your assertion. Since 2015 I find that async functions is probably the most alien addition... and the handful of others that are significant are mostly ignored or very natural extensions.

The shift from callbacks to promises is kind of alien, but frankly that was started well before 2015 even. The .babelrc I use for node projects is pretty simple as well, here's one I use for an AWS Lambda build...

    {
      "presets": [
        [
          "env",
          { "loose": true, "targets": { "node": "6.10.3" } }
        ]
      ],
      "plugins": [
        "syntax-dynamic-import",
        "syntax-object-rest-spread",
        "syntax-async-generators",
        "transform-class-properties",
        "transform-decorators-legacy",
        "transform-object-rest-spread",
        "transform-async-to-generator"
      ]
    }

So that's literally 3 things that aren't in spec yet, and a couple that work around the runtime not having them. Most of what's going in is already in, or relatively well established and on the way.

Now, you do have to include a lot more if you want IE11 support, but hey, that's a different thing. I'm not sure what exactly you're having a trouble wrapping your head around.

Reply on news.ycombinator.com