8 ms·

What is old is new again. I've been a software engineer for over 30 years and have dealt with companies always trying to jump on the next bandwagon. One comp

What is old is new again. I've been a software engineer for over 30 years and have dealt with companies always trying to jump on the next bandwagon. One company I worked with tried to move our entire monolith application, which was well architected and worked fine, over to a microservices-based architecture and the result was an unstable, complex mess. Sometimes, if it's not broke, don't try to "fix" it. I can say the same regarding a lot of what is going on in the JavaScript ecosystem, where people are trying to replicate stuff that works fine in other languages in JavaScript. Mostly because they are only familiar with JavaScript and don't realize this stuff already exists and doesn't need to be in JavaScript.

erikpukinskis 7y ago
Agree with your last point. And as someone who really liked old school callback/prototype/closure based JavaScript, I can say not only would these people have been better off using a better language, they also ruined JavaScript for the things it was great at.
- kizer 7y ago
  You can still do all that in JS, novel syntactic sugar aside.
  - austincheney 7y ago
    He/She cannot do that, at least at their employer, because people would throw up at the sight of the code and cry until its rewritten. As an example slip some DOM methods into your code and watch people go into convulsions like an angry zombie on cocaine.
    - ritchiea 7y ago
      There are very real reasons not to use DOM methods assuming you're using a front end framework. Not only is the coding style more imperative than say React, but frontend frameworks have been designed to efficiently update the DOM and have diffing algorithms that can check for necessary state changes. Is there really a compelling reason for writing your own DOM manipulation in a sizeable frontend codebase in 2020?
      - austincheney 7y ago
        > Is there really a compelling reason for writing your own DOM manipulation in a sizeable frontend codebase in 2020? It is several orders of magnitude faster. It’s also how I prefer to code because managing state isn’t challenging and I am not hopelessly paralyzed by imperative code.
      - pepper_sauce 7y ago
        Maybe they don't want to force their users to download several MB of framework libraries in order to use their website. DOM manipulation is perfectly fine for interacting with styled documents, the web's forté. If your website amounts to a set of configuration forms and a blog then you probably don't need React.
  - erikpukinskis 7y ago
    You can turn a bar into a dance club, and I can still drink there. But it’s a little academic to suggest that. That said, I’m am quite free to choose not to install npm packages that use Babel or Webpack, and I that’s what I choose when I have a choice. Certainly don’t have that choice at my work.
thrower123 7y ago
I can't imagine your level of cynicism. I've only been at this for ten years, and the number of times I've seen the wheel come full circle and old ideas come back into vogue, the problems with them rediscovered, reactions to those problems, and then the thing that preceded them again take precedence is somewhat depressing. At best I feel like we are grinding ahead a few inches each cycle.
- tylerjwilk00 7y ago
  It's like the movie Benjamin Button but with a case of amnesia every three years.
  - thrower123 7y ago
    Sometimes it feels more like Memento
- baq 7y ago
  Same boat, same feeling.
MockObject 7y ago
It used to be that people wrote Fortran in any language. Now they're rewriting Java in every language.
- pjmlp 7y ago
  The bad reputation that enterprise Java gets, comes from enterprise C and C++ codebases. https://en.wikipedia.org/wiki/Structured_systems_analysis_and_design_method https://en.wikipedia.org/wiki/Structured_systems_analysis_an... https://en.wikipedia.org/wiki/Booch_method https://en.wikipedia.org/wiki/Booch_method Any language that gets into enterprise architect hands, with projects spread around multiple development sites with several consulting agencies, gets their FactoryFactories and such.
  - js8 7y ago
    No, Java has its own share of problems that it didn't inherit from anywhere. No custom value types, no operator overloading and the distaste for AOT compilation, to name a few. Also culture of code generation instead of using some kind of macro system.
    - pjmlp 7y ago
      Custom value types will arrive, that is the point of project Valhalla. C and Go also don't do operator overloading. Code generation was a thing in C and C++ during the 90's. Borland C++ 1.0 came with a macro library (BIDS), which was later replaced by a new template based version in Borland C++ 2.0. And the Go culture of //go:generate goes beyond anything that Java has had on its almost 30 years of existence. AOT compilation exists since the early 2000's. The only distaste is that most developers don't want to pay for their tools, so they rather used the free beer JDK from Sun instead third party vendors. So only big corporations got to buy the JDKs from IBM, Oracle, ExcelsiorJET, Aonix,.... However now AOT free beer exists on OpenJDK, OpenJ9, GraalVM and although not strictly Java, Android.
    - bernawil 7y ago
      It's like a museum of problems. Waves of solutions that became problems after. The culture of code generation before the culture of XML configuration.
davnicwil 7y ago
> people are trying to replicate stuff that works fine in other languages in JavaScript. Mostly because they are only familiar with JavaScript and don't realize this stuff already exists and doesn't need to be in JavaScript. Do you have a concrete example to illustate this, and what issues it causes? On the surface I'm not sure I agree, if what you're saying is people wanting a certain feature should switch languages to get it rather than build it into the language they already use.
- 0x445442 7y ago
  What new problem was Nodejs trying to solve and why does it exist?
  - davnicwil 7y ago
    Well, indeed, Node is a good example of the point I'm making - it provided a full environment for writing programs in JS outside the browser. There were a plethora of other languages/runtimes available for writing such programs, but Node made this available to people who already knew & liked using JS without having to switch to and/or learn a new language.
endorphone 7y ago
"What is old is new again." It isn't really, though. This is Some Guy's Opinion™. There are many Some Guy's, and there are countless anti-monolith articles being penned at this moment (probably). People have different experiences with different groups and different tech stacks and different needs. Results may vary. Just to give my own Some Guy opinion, people fail with so-called microservices when it's not really microservices but instead is a monolith with artificial walls (in the same way that firms do waterfall but pretend that they're agile by having incredibly frequent "scrums" that are nothing but status meetings). When you actually divided into lots of different projects and teams and they each get to construct their own internal world so long as they provide the appropriate robust and documented external API, it can be absolutely liberating. For some projects.
- 0x445442 7y ago
  Your next to last sentence is spot on but it requires well defined interfaces and engineering which is orthogonal to middle management’s desire to commodities development.
mrtksn 7y ago
I am fine with that, I miss the simplicity of PHP and Delphi sometimes.
PopeDotNinja 7y ago
> Sometimes, if it's not broke, don't try to "fix" it. I'm going to interpret this as "if your monolith is broke, breaking it up into microservices won't fix it"
- owenmarshall 7y ago
  A implies B does not mean B implies A. Sometimes a microservice architecture is the best way to fix your problems. Sometimes it’s the worst. But you’ll only be able to tell after your monolith is, indeed, truly good and busted. Just never start with it. That’s crazy.

erikpukinskis 7y ago

Agree with your last point. And as someone who really liked old school callback/prototype/closure based JavaScript, I can say not only would these people have been better off using a better language, they also ruined JavaScript for the things it was great at.

kizer 7y ago
You can still do all that in JS, novel syntactic sugar aside.
- austincheney 7y ago
  He/She cannot do that, at least at their employer, because people would throw up at the sight of the code and cry until its rewritten. As an example slip some DOM methods into your code and watch people go into convulsions like an angry zombie on cocaine.
  - ritchiea 7y ago
    There are very real reasons not to use DOM methods assuming you're using a front end framework. Not only is the coding style more imperative than say React, but frontend frameworks have been designed to efficiently update the DOM and have diffing algorithms that can check for necessary state changes. Is there really a compelling reason for writing your own DOM manipulation in a sizeable frontend codebase in 2020?
    - austincheney 7y ago
      > Is there really a compelling reason for writing your own DOM manipulation in a sizeable frontend codebase in 2020? It is several orders of magnitude faster. It’s also how I prefer to code because managing state isn’t challenging and I am not hopelessly paralyzed by imperative code.
    - pepper_sauce 7y ago
      Maybe they don't want to force their users to download several MB of framework libraries in order to use their website. DOM manipulation is perfectly fine for interacting with styled documents, the web's forté. If your website amounts to a set of configuration forms and a blog then you probably don't need React.
- erikpukinskis 7y ago
  You can turn a bar into a dance club, and I can still drink there. But it’s a little academic to suggest that. That said, I’m am quite free to choose not to install npm packages that use Babel or Webpack, and I that’s what I choose when I have a choice. Certainly don’t have that choice at my work.

thrower123 7y ago

I can't imagine your level of cynicism. I've only been at this for ten years, and the number of times I've seen the wheel come full circle and old ideas come back into vogue, the problems with them rediscovered, reactions to those problems, and then the thing that preceded them again take precedence is somewhat depressing. At best I feel like we are grinding ahead a few inches each cycle.

tylerjwilk00 7y ago
It's like the movie Benjamin Button but with a case of amnesia every three years.
- thrower123 7y ago
  Sometimes it feels more like Memento
baq 7y ago
Same boat, same feeling.

MockObject 7y ago

It used to be that people wrote Fortran in any language. Now they're rewriting Java in every language.

pjmlp 7y ago
The bad reputation that enterprise Java gets, comes from enterprise C and C++ codebases. https://en.wikipedia.org/wiki/Structured_systems_analysis_and_design_method https://en.wikipedia.org/wiki/Structured_systems_analysis_an... https://en.wikipedia.org/wiki/Booch_method https://en.wikipedia.org/wiki/Booch_method Any language that gets into enterprise architect hands, with projects spread around multiple development sites with several consulting agencies, gets their FactoryFactories and such.
- js8 7y ago
  No, Java has its own share of problems that it didn't inherit from anywhere. No custom value types, no operator overloading and the distaste for AOT compilation, to name a few. Also culture of code generation instead of using some kind of macro system.
  - pjmlp 7y ago
    Custom value types will arrive, that is the point of project Valhalla. C and Go also don't do operator overloading. Code generation was a thing in C and C++ during the 90's. Borland C++ 1.0 came with a macro library (BIDS), which was later replaced by a new template based version in Borland C++ 2.0. And the Go culture of //go:generate goes beyond anything that Java has had on its almost 30 years of existence. AOT compilation exists since the early 2000's. The only distaste is that most developers don't want to pay for their tools, so they rather used the free beer JDK from Sun instead third party vendors. So only big corporations got to buy the JDKs from IBM, Oracle, ExcelsiorJET, Aonix,.... However now AOT free beer exists on OpenJDK, OpenJ9, GraalVM and although not strictly Java, Android.
  - bernawil 7y ago
    It's like a museum of problems. Waves of solutions that became problems after. The culture of code generation before the culture of XML configuration.

davnicwil 7y ago

> people are trying to replicate stuff that works fine in other languages in JavaScript. Mostly because they are only familiar with JavaScript and don't realize this stuff already exists and doesn't need to be in JavaScript. Do you have a concrete example to illustate this, and what issues it causes? On the surface I'm not sure I agree, if what you're saying is people wanting a certain feature should switch languages to get it rather than build it into the language they already use.

0x445442 7y ago
What new problem was Nodejs trying to solve and why does it exist?
- davnicwil 7y ago
  Well, indeed, Node is a good example of the point I'm making - it provided a full environment for writing programs in JS outside the browser. There were a plethora of other languages/runtimes available for writing such programs, but Node made this available to people who already knew & liked using JS without having to switch to and/or learn a new language.

endorphone 7y ago

"What is old is new again." It isn't really, though. This is Some Guy's Opinion™. There are many Some Guy's, and there are countless anti-monolith articles being penned at this moment (probably). People have different experiences with different groups and different tech stacks and different needs. Results may vary. Just to give my own Some Guy opinion, people fail with so-called microservices when it's not really microservices but instead is a monolith with artificial walls (in the same way that firms do waterfall but pretend that they're agile by having incredibly frequent "scrums" that are nothing but status meetings). When you actually divided into lots of different projects and teams and they each get to construct their own internal world so long as they provide the appropriate robust and documented external API, it can be absolutely liberating. For some projects.

0x445442 7y ago
Your next to last sentence is spot on but it requires well defined interfaces and engineering which is orthogonal to middle management’s desire to commodities development.

mrtksn 7y ago

I am fine with that, I miss the simplicity of PHP and Delphi sometimes.

PopeDotNinja 7y ago

> Sometimes, if it's not broke, don't try to "fix" it. I'm going to interpret this as "if your monolith is broke, breaking it up into microservices won't fix it"

owenmarshall 7y ago
A implies B does not mean B implies A. Sometimes a microservice architecture is the best way to fix your problems. Sometimes it’s the worst. But you’ll only be able to tell after your monolith is, indeed, truly good and busted. Just never start with it. That’s crazy.