6 ms·

“Examples: Clojure, Common Lisp, HTML, Make Counter-examples: JavaScript, Ruby, React-Preact-Vue-Angular-“ OP does not give any reason as to why these are chu

“Examples: Clojure, Common Lisp, HTML, Make Counter-examples: JavaScript, Ruby, React-Preact-Vue-Angular-“ OP does not give any reason as to why these are churn and why stop them ? This makes no sense...basically to op’s point we should just never adopt new technology because it’s just a new shiny thing. This makes no sense at all.

Crinus 7y ago
I'd put JavaScript in the "Examples" section as, like HTML, any change it gets is fully backwards compatible so you do not have to play catch-up with the latest stuff just to keep your existing code working. I do not know about Ruby nor about React-Preact-Vue-Angular to judge, though based on what i've heard the latter pile does sound made up of things that expect you do waste your time ensuring your software keeps working.
- jefftk 7y ago
  Plain JS, yes. The modern JS ecosystem, however, has an enormous amount of churn. The hot way to do things in JS world five years ago is hopelessly obsolete now.
  - Crinus 7y ago
    Well, the list says "JavaScript" so i took it as plain JavaScript. If you care about avoiding churn you can stick with stuff that have proven to remain backwards compatible and plain JavaScript fits the bill.
    - vkou 7y ago
      It fits the bill for compatibility, but building anything useful in plain JavaScript is a jaunt through all seven layers of hell.
tracer4201 7y ago
He didn’t elaborate but I agree with him. I’ve seen too many examples of junior devs having to work on some small feature or enhancement, and their idea becomes rewriting the entire code base in whatever new framework of the month happens to be for the time. Yes there are plenty of reasons to adopt new technology, but you have to balance the pros and cons with keeping your business running and most importantly not disrupting your customers. At the end of the day, honestly, how many frameworks do you need to build webpages? And 95%+ certainly are not operating at a Google or Amazon scale. On a side note, I recently saw a dev spend a few days wrestling with dependency issues - he was trying to wire in Spring into a Java application and running into configuration issues with decorators. At the end of the day, this was a tiny, tiny application that periodically ingests messages from a topic and forwards their payload to an email service. These are 5-10 messages a day and the emails that are generated go to internal business customers as a courtesy and not less of a mission critical notification. It’s worth thinking about what was the business value vs the cost? The take away isn’t that you should never use new technology - rather, understand that new technology or change in general comes at a cost. Your job is to balance that cost considering several factors - code quality (cost of time spent), flexibility and extensibility, features (the stuff valuable to whatever function responsible for your pay check), cost of on going support and maintenance (operational load). Disregarding those factors and over indexing on latest and greatest is usually the wrong approach.
- cryptozeus 7y ago
  Agree with everything you said...but remember all the issues you listed are not new to junior dev and also not new particular technology. Same debugging issues were being worked on in c and c++. Your observation is correct but applies to not only to all technology but life in general.
regularfry 7y ago
Clojure is a really interesting example because it's newer than things in the "churn" list. It's an existence proof that "newness" and "churniness" don't go hand in hand. What causes "churn" isn't the tech, it's how the ecosystem around it works.

Crinus 7y ago

I'd put JavaScript in the "Examples" section as, like HTML, any change it gets is fully backwards compatible so you do not have to play catch-up with the latest stuff just to keep your existing code working. I do not know about Ruby nor about React-Preact-Vue-Angular to judge, though based on what i've heard the latter pile does sound made up of things that expect you do waste your time ensuring your software keeps working.

jefftk 7y ago
Plain JS, yes. The modern JS ecosystem, however, has an enormous amount of churn. The hot way to do things in JS world five years ago is hopelessly obsolete now.
- Crinus 7y ago
  Well, the list says "JavaScript" so i took it as plain JavaScript. If you care about avoiding churn you can stick with stuff that have proven to remain backwards compatible and plain JavaScript fits the bill.
  - vkou 7y ago
    It fits the bill for compatibility, but building anything useful in plain JavaScript is a jaunt through all seven layers of hell.

tracer4201 7y ago

He didn’t elaborate but I agree with him. I’ve seen too many examples of junior devs having to work on some small feature or enhancement, and their idea becomes rewriting the entire code base in whatever new framework of the month happens to be for the time. Yes there are plenty of reasons to adopt new technology, but you have to balance the pros and cons with keeping your business running and most importantly not disrupting your customers. At the end of the day, honestly, how many frameworks do you need to build webpages? And 95%+ certainly are not operating at a Google or Amazon scale. On a side note, I recently saw a dev spend a few days wrestling with dependency issues - he was trying to wire in Spring into a Java application and running into configuration issues with decorators. At the end of the day, this was a tiny, tiny application that periodically ingests messages from a topic and forwards their payload to an email service. These are 5-10 messages a day and the emails that are generated go to internal business customers as a courtesy and not less of a mission critical notification. It’s worth thinking about what was the business value vs the cost? The take away isn’t that you should never use new technology - rather, understand that new technology or change in general comes at a cost. Your job is to balance that cost considering several factors - code quality (cost of time spent), flexibility and extensibility, features (the stuff valuable to whatever function responsible for your pay check), cost of on going support and maintenance (operational load). Disregarding those factors and over indexing on latest and greatest is usually the wrong approach.

cryptozeus 7y ago
Agree with everything you said...but remember all the issues you listed are not new to junior dev and also not new particular technology. Same debugging issues were being worked on in c and c++. Your observation is correct but applies to not only to all technology but life in general.

regularfry 7y ago

Clojure is a really interesting example because it's newer than things in the "churn" list. It's an existence proof that "newness" and "churniness" don't go hand in hand. What causes "churn" isn't the tech, it's how the ecosystem around it works.