Hacker News Reader

Comment by gingerb | Hacker News Reader

This is the reason why I still enjoy to write in C, there is simply no need to change your entire codebase because some dude came up with a new "miracle".

I do full-stack javascript for my income, but have reached the point of not enjoying coding anymore because of this continuous change of ideas forced upon me. Why do I need to change from React.createClass to ES6 classes, from ESxx to Typescript or Flow, from React to Vue, from callbacks to Promises, from Flux to Redux, or from any idea to the next hyped idea?

When will people start to realise that this new method or technology they're implementing is deprecated already?

There is no end to this and I actually hate it as it destroys my passion for coding. I code to create things, not to continuously change what's created already and works fine.

As soon as I find a cool C job I'll definitely leave this mad house.

View on HN

> I do full-stack javascript for my income, but have reached the point of not enjoying coding anymore because of this continuous change of ideas forced upon me. Why do I need to change from React.createClass to ES6 classes, from ESxx to Typescript or Flow, from React to Vue, from callbacks to Promises, from Flux to Redux, or from any idea to the next hyped idea?

Who's forcing you to do this? All of these old things still work. If your team/job are forcing you to do this, then why is the problem not with them, rather than the language/ecosystem?

> All of these old things still work.

The old things likely have bugs. And most libraries don't spend a lot of time patching old versions (why should they, it's free software). The longer time passes the less and less likely there will be bug/security patches. So if you want to own those bugs/security issues, sure, stay behind to avoid the cost of upgrading.

"The old things likely have bugs" Do you even have experience with React? It sounds like you don't. Because there's no "bugs" with using createClass or proptypes, it's simply been split out into a separate package that you can still use if you want.

Lol love how I get downvotes for stating facts

There are "enterprise type" libraries for JavaScript developers that move slower & focus on stability over performance or productivity increases. Some are backed by a company that offers paid support. While I haven't used it, I've heard good things about Telerik.

Where can we learn more about these "enterprise type" libraries?

JavaScript is a young language. It's been around for 21 years.

C has been around for 45 years.

I'm sure things will be relatively stable 24 years from now in terms of web development, but then there will be a new medium for writing code with massive churn in commonly-used libraries and techniques.

A need to learn new things in a young language will never die.

Even C++, which is "only" 34 years old is experiencing massive changes to its syntax and common practices.

It's impressive how most of the progress in the JS land is essentially adding the features most of the other languages have already had for years (or - at least had done them properly in the first place).

And I do understand why - it's just quite pathetic to see all of that being done for no practical reason.

It's also incredibly frustrating that every step that is rediscovered that other languages just have is then subject to endless fragmentation over trivial differences that are put forward as core philosophical concerns. I know this is not unique to the JS ecosystem but it's definitely a lot worse than I've seen in the past.

Which past are you talking about? Before the last years progresses, to make your javascript working on multiple browser your only choice was to lock you learning huge frameworks and toolkits like jquery and dojo, or spend hours during your weekends to get a project working on multiple platforms.

Those times were painful, now it’s much much better.

Yeah, I don't think these people worked on code that targeted IE6-8. Horrible times.

I've been writing production JavaScript since 1999. Writing compatible JS used to be a horrible pain, now everything about writing and maintaining your JS is the pain and browsers by comparison are highly forgiving.

Thanks for sharing! This is a viewpoint that I've never encountered before as only having entered the game in the last 3 years.

I'm talking more ecosystem than core language changes. Though of course, core language changes are part of the build and tooling ecosystem because of everyone constantly wanting to write code that is years ahead of what browsers are actually supporting. Build and package management tooling, frameworks etc.

Sure, Haskell & OCaml have had a lot of these features for years, but they can hardly be called "most languages". Other languages are also in the progress of adding similar features (C++, for example) or aren't getting them (C).

Javascript has more library churn, but the alternative is being stuck on something like BOOST. ugh.

Let's be clear: JavaScript tries to be both a platform and a programming language.

People hate it because there's no practical reason why we're forced to use JavaScript in order to program - and most of the people who are productive are probably using some sort of variation on ECMAScript that makes it bearable anyway.

> Let's be clear: JavaScript tries to be both a platform and a programming language.

I'm not sure how you came to this conclusion. JavaScript is the common language for two major platforms (browsers, Node.js) and many smaller ones (Cocos2d, enyo JS, Espruino, GNOME Shell, Kinoma XS6, NativeScript, Weex, etc.).

Um what?

- browsers: used since the 90s because there's no other alternative

- node.js: created because JS is used in browsers and it's easier to write code in a single language for browsers and servers

- Cocos2d: you're clearly lying as the only place where JS is mentioned is Cocos2d-html, as there's again - no alternative

- enyo JS: again, used clearly due to the fact that modern - browsers are available for all of the modern platforms

- Weex, NativeScript: typical "native app" libraries which use a webkit pane for most of the rendering, again - javascript here is circumstantial since you can't choose anything else

- GNOME Shell, Kinoma XS6: OK. These are the only ones that make any sort of a strong point in your message; but as far as it goes - modern linux distros are moving to Python for systems programming anyway. So learning JS here is a miss.

On one hand, I absolutely agree. The amount of change that happens for the sake of nothing more than change is laughable theme in front-end development.

And if it's not for changes sake it becomes some weird squabble over how to best handle X, and we wind up with numerous ways to do so. At that point we have to take a bet as to which approach we think will be supported and pushed forward in the future (i.e. promises? generators? callbacks? async/await?). If we're right? Great. If we're wrong. Well, let's hope the libs we're using keep support for the way we've written our code.

On the other hand, it does finally seem like React has one the shake out of front-end frameworks. While it's ever changing, it does seem like it's longevity will be far greater than most front-end frameworks of the past. And it does solve a lot of the BS that one would deal with if they didn't have a framework to leverage.

But yeah.. The danger with front-end development is how fast the knowledge depreciates.

edit: by danger, I more mean difficulty of keeping up with.

"Why do I need to change from React.createClass to ES6 classes, from ESxx to Typescript or Flow, from React to Vue, from callbacks to Promises, from Flux to Redux, or from any idea to the next hyped idea?"

There are good reasons for those changes. As you are a full stack JS developer, I'd recommend you dig deeper and find out why. It might alleviate your frustration.

The GP's frustration is not with any individual change, it's the treadmill of changes that makes every refactor/rewrite an exercise in treading water.

Reply on news.ycombinator.com