7 ms·

Why developers need to be able to identify technologies with staying power

96 points by axiomdata316 8y ago

EduardoBautista 8y ago
This is why I choose Ember as my framework of choice. It's been there since Backbone, since Angular, and now React. React, in my opinion, is filled with "best practices" where they choose complex solutions to simple problems. The dependency hell is also ridiculous in React. I would like to see how many of these apps are having issues upgrading to the latest versions of their dependencies in 5 years.
- noir_lord 8y ago
  It's also why I chose Vue over React. In terms of capabilities they are fairly similar but the the existence of an official router and official state management store means that the "things that can break in horrible ways" surface is reduced. I stuck with KnockoutJS for a long time because they had (for a JavaScript project) incredible backwards compatibility and stability. I've been programming long enough that "the new hotness" is of much lower interest than "what capability does it give me I don't have and will I still be able to build/deploy this in 3 years if I need to". Also if something seems amazing I'll wait a year, if it was amazing it'll still be amazing in a year and I'll have 365 days of other people smacking their heads on the not amazing parts.
  - projectramo 8y ago
    The knockout documentation is a thing of beauty. One should start with the framework for that reason alone.
  - Kiro 8y ago
    What's the official state management?
    - lhorie 8y ago
      vuex
- izelnakri 8y ago
  It will take few years for people to realize, but Ember.js is the silver bullet for building web applications.
  - projectramo 8y ago
    Why do you say that? Someone else I know also has a soft spot for Ember though from my vantage point (dabbled in them all), they all seem quite similar. (Them being Ember, Backbone, Angular).
projectramo 8y ago
Here is the thing: what prevents me from learning a new technology is not that I don't get the "big picture" concept which inspired it. Cognitive load-wise, these concepts aren't difficult to grasp in the abstract. What slows me down is the little implementation detail that is causing this weird bug that I just don't understand. And if it is a new technology, then stack overflow doesn't have the answer. So, to take the example the author gives, when Rails was new, its not that I didn't understand the MVC framework and how the roles were different. I didn't understand that RVM had to be set to a default ruby version every time I restarted the console.
- sharadov 8y ago
  You nailed it, I'll pick up the technology, but then get stuck in some silly bug which I can't find the solution to and abandon it after getting frustrated.
  - DanielBMarkham 8y ago
    But that's actually the work: getting stuck, sticking with it, and reasoning your way out of being stuck. That's programming. Fair enough if you avoid certain situations because this is where you end up -- I do the same thing -- but the work is the work whether it's a new language or some oddball patch/upgrade that made things act funky in ways they didn't before.
    - dmortin 8y ago
      There is a difference between learning a system and getting stuck on some configuration detail. It's very frustrating when you want to understand a system and you're stuck with some error which is not your fault, but it's some bug in the new technology and instead of learning the technology you spend time with hunting some configuration bug. That won't help you learning the technology, because that bug will be fixed in some configuration script and later users won't even encounter it, because the tooling will generate the proper scripts for the first time. So it's often not that kind of knowledge which proves to be useful later, but some implementation detail which you won't ever encounter again.
acconrad 8y ago
> For example, Object Oriented Programming became Functional Programming What? No it didn't. An imperative language is the opposite of a declarative language. OP might want to edit this one.
- bunderbunder 8y ago
  Indeed. Right there alongside acknolwedging OCaml (albeit capitalized incorrectly) as a functional language, no less.
- rpowers 8y ago
  It is pretty clear that the author meant OOP -> FP with respect to popularity and NOT literally transformed from one to the other.
stupidcar 8y ago
Stuff like this is what puts me off React: https://reactjs.org/blog/2018/03/29/react-v-16-3.html https://reactjs.org/blog/2018/03/29/react-v-16-3.html https://reactjs.org/blog/2018/06/07/you-probably-dont-need-derived-state.html https://reactjs.org/blog/2018/06/07/you-probably-dont-need-d... It's at v16, and they're still making major changes to the basic component lifecycle, deprecating things, and then almost immediately having to write articles to teach against anti-patterns that already arisen in the new APIs! A programming model that is so unintuitive people still cannot use it right, even after so many years, does not seem like a great bet to me.
- djstein 8y ago
  I'm not sure if you actually have ever used React but every single major version update is non breaking. The topics discussed in the link provided are discussing how an internal library is being updated (Context API) and how these functions are being depreciated in version 17 (https://reactjs.org/blog/2018/03/27/update-on-async-rendering.html https://reactjs.org/blog/2018/03/27/update-on-async-renderin...). The above depreciations are functions that typically should not be used in a v16 React application anyway! Using them typically means there lies a bug in your props updating logic.
  - flukus 8y ago
    > I'm not sure if you actually have ever used React but every single major version update is non breaking. That would be fine if they were making major releases every 2+ years, when you release a major version on average of 3 times a year it's incredibly unstable. A typical upgrade will be jumping several versions.
    - gr__or 8y ago
      A major version change of React is different from a major version change in Angular. I upgraded several React apps of variying sizes from 14 to 17 over time and none of these upgrades took more than an hour. Don't get confused by the version labeling scheme.
- 8y ago
bsenftner 8y ago
One can nit pick some of his points, but the general essay is right on point. Developers need to understand what they are building on top of to be able to navigate non-trivial problems. I found this article from Saturday worth the read, as it explains what Docker actually is, and why no one needs it: http://catern.com/posts/docker.html http://catern.com/posts/docker.html. The same goes for everyone working in the cloud; I've build my own clusters to compare the effort and expense (rather than just accept the marketing line) and running one's own servers, from one to hundreds, is exponentially more cost effective than any cloud service. People are not doing their homework, and the herd mentality owns the entire tech industry.
- galois198 8y ago
  Please could you elaborate on the cloud vs on-premise comparison? Are you including the initial on-prem costs of buying the hardware?
  - bsenftner 8y ago
    Yep. The expense of the cloud is crazy; in most corporate situations the expense of purchasing the same servers used by the cloud service is 1/4 your monthly cloud bill. The markup is unethically high, so they've brainwashed an entire generation of young developers and their equality naive CTOs that this is anything other than a swindle. Running a server is child's play, people. Don't believe the hype!
    - mmt 8y ago
      People may have a strong reaction to the word "crazy", but I'm not sure what else to call it, other than "mass delusion" or "mass hallucination". I've done this analysis for (mostly small-scale) companies for about 10 years, and, every time, the cost of using public cloud computing has been 2x-10x of running ones own servers for 3 years. I've only had one exception, where the incremental cost of compute was 1:1, if the servers were placed in more expensive space near the other servers in the existing datacenter. Data transfer costs made cloud more expensive, of course. > Running a server is child's play, people. I'd say that's a bit of a hyperbole, but I agree that the incremental expertise (and time/effort) required to deal with hardware over cloud, is far from the prohibitve headache it's made out to be.
GuB-42 8y ago
That's called experience. This is the reason why senior developers are normally paid more and make the important decisions. And what the article tells is that you should actually get interested in what you are doing, if you want to become experienced and not just old. That should be common sense, but I guess it is worth repeating from time to time. However, if you don't have 30 years of experience, ranging from coding on a C64 to modern JS frameworks, the Lindy effect (older technology tends to stay longer) is a good shortcut.
- swsieber 8y ago
  To build upon your comment: It's not because older technology is inherently better, but it's because if older technology is still relevant, it's survived the "will it be relevant in the future" test once before.
- mgrennan 8y ago
  As a person with 40+ years experence (Yes I started with a 4004) I aggee. Change is constend and the advancement of more and more complex systems is inevitable. Most of these is good but some with issues. The quote "A sufictly advanced technology is indistinguishable from magic" describes an ADVANCED tech. I believe it is the speed we are developing the tech that is the problem. We are more often then not ignoring the wisdom of senior developers.
- flukus 8y ago
  > That's called experience. This is the reason why senior developers are normally paid more and make the important decisions. The problem is we obtain that "senior" title long before we have this experience. Then when it's finally deserved (the 10+ year mark) the pressure starts mounting to move into architecture/management roles. And let's not forget the "old man can't keep up" that's always been rampant. The industry as a whole seems to consider experience as a liability.
mgrennan 8y ago
I have developed a term for this. EARLY ADOPTER TECH DEBT.
- ak39 8y ago
  Early Adopter Margin Call
blackrock 8y ago
Which technology stack would you recommend going forward? And why? Node.js? Vue.js? React? Angular? Elm? I can't keep up with the Javascript tower of babel anymore. And what happened to Django? Nobody seems to talk about it anymore.
- iamcasen 8y ago
  Django is by far the best full-stack MVC solution IMO. It is well known in python communities, and python is growing in popularity year over year. As for your javascript questions: React is the answer. Not just because it has the considerable resources of Facebook backing it, but because at it's core, the idea is extremely sound and well tested, going back 30 or more years. Vue.js has similar principles and might also be a good choice, but what you need to look out for is the community surrounding it, and whether it will eventually be unsupported. Node.js is great in the backend, but doesn't have quite as many mature frameworks like Django. If you're down to build things from bare metal using some libraries like Express.js or Koa.js, then you'll enjoy Node.js. Typescript and Flow have also made Node more attractive.
- deltron3030 8y ago
  > Which technology stack would you recommend going forward? And why? With React you have the most options and biggest community, including ways to shoot yourself in the foot. It's preferred by full stack JS guys who also use node, so it could be great if you're a startup and can hire somebody who can do everything. Angular is popular with enterprises who know what they need (a stable environment at scale with strict rules), who have a high budget for hiring specialists, the whole framework is more complex. Vue sits in between Angular and React, but more geared towards smaller businesses and their needs. It's very popular with PHP devs, and full stack devs who don't use JS exclusively. The main advantage is peace of mind, knowing that everything works well togehter. Elm is very opinionated, but also very different from those other frameworks. In React or Vue you start thinking of components, in Elm you think about functionality, and create components as they emerge from patterns, potentially leading to a more cohesive and elegant result. But that's not how designers used to work. Bridging the gap between designers and devs, and how they currently work, is the main advantage of React and Vue imo. Web designers (like graphic designers) are used to think in whole pages, or layouts, and break things down from there (top-down). React and Vue and the component first paradigm is a compromise, where devs aren't degraded into only doing the implemetation, and designers aren't degraded into doing the styling only. It still respects both roles. Elm is basically the next level for designers, or designers who like to code. It's how design that left the analog world behind could be.
IloveHN84 8y ago
This obviously is a problem of new languages/high dynamical frameworks.. Why this isn't happening for languages such as C, C++, Java? Sure, new standards are kicking in, but you can still program using old standard, it will continue (more or less) to work. Why do JS developers follow overhyped frameworks? I do not understand.. the few times I've programmed in JavaScript, I've always used jQuery: it might be old school, but it does its job well and bootstrap is still using it too.
mabynogy 8y ago
"A trailblazzer doesn't follow a trail" as Terry Davis says.

96 points by axiomdata316 8y ago

This is why I choose Ember as my framework of choice. It's been there since Backbone, since Angular, and now React. React, in my opinion, is filled with "best practices" where they choose complex solutions to simple problems. The dependency hell is also ridiculous in React. I would like to see how many of these apps are having issues upgrading to the latest versions of their dependencies in 5 years.

noir_lord 8y ago
It's also why I chose Vue over React. In terms of capabilities they are fairly similar but the the existence of an official router and official state management store means that the "things that can break in horrible ways" surface is reduced. I stuck with KnockoutJS for a long time because they had (for a JavaScript project) incredible backwards compatibility and stability. I've been programming long enough that "the new hotness" is of much lower interest than "what capability does it give me I don't have and will I still be able to build/deploy this in 3 years if I need to". Also if something seems amazing I'll wait a year, if it was amazing it'll still be amazing in a year and I'll have 365 days of other people smacking their heads on the not amazing parts.
- projectramo 8y ago
  The knockout documentation is a thing of beauty. One should start with the framework for that reason alone.
- Kiro 8y ago
  What's the official state management?
  - lhorie 8y ago
    vuex
izelnakri 8y ago
It will take few years for people to realize, but Ember.js is the silver bullet for building web applications.
- projectramo 8y ago
  Why do you say that? Someone else I know also has a soft spot for Ember though from my vantage point (dabbled in them all), they all seem quite similar. (Them being Ember, Backbone, Angular).

projectramo 8y ago

Here is the thing: what prevents me from learning a new technology is not that I don't get the "big picture" concept which inspired it. Cognitive load-wise, these concepts aren't difficult to grasp in the abstract. What slows me down is the little implementation detail that is causing this weird bug that I just don't understand. And if it is a new technology, then stack overflow doesn't have the answer. So, to take the example the author gives, when Rails was new, its not that I didn't understand the MVC framework and how the roles were different. I didn't understand that RVM had to be set to a default ruby version every time I restarted the console.

sharadov 8y ago
You nailed it, I'll pick up the technology, but then get stuck in some silly bug which I can't find the solution to and abandon it after getting frustrated.
- DanielBMarkham 8y ago
  But that's actually the work: getting stuck, sticking with it, and reasoning your way out of being stuck. That's programming. Fair enough if you avoid certain situations because this is where you end up -- I do the same thing -- but the work is the work whether it's a new language or some oddball patch/upgrade that made things act funky in ways they didn't before.
  - dmortin 8y ago
    There is a difference between learning a system and getting stuck on some configuration detail. It's very frustrating when you want to understand a system and you're stuck with some error which is not your fault, but it's some bug in the new technology and instead of learning the technology you spend time with hunting some configuration bug. That won't help you learning the technology, because that bug will be fixed in some configuration script and later users won't even encounter it, because the tooling will generate the proper scripts for the first time. So it's often not that kind of knowledge which proves to be useful later, but some implementation detail which you won't ever encounter again.

acconrad 8y ago

> For example, Object Oriented Programming became Functional Programming What? No it didn't. An imperative language is the opposite of a declarative language. OP might want to edit this one.

bunderbunder 8y ago
Indeed. Right there alongside acknolwedging OCaml (albeit capitalized incorrectly) as a functional language, no less.
rpowers 8y ago
It is pretty clear that the author meant OOP -> FP with respect to popularity and NOT literally transformed from one to the other.

stupidcar 8y ago

Stuff like this is what puts me off React: https://reactjs.org/blog/2018/03/29/react-v-16-3.html https://reactjs.org/blog/2018/03/29/react-v-16-3.html https://reactjs.org/blog/2018/06/07/you-probably-dont-need-derived-state.html https://reactjs.org/blog/2018/06/07/you-probably-dont-need-d... It's at v16, and they're still making major changes to the basic component lifecycle, deprecating things, and then almost immediately having to write articles to teach against anti-patterns that already arisen in the new APIs! A programming model that is so unintuitive people still cannot use it right, even after so many years, does not seem like a great bet to me.

djstein 8y ago
I'm not sure if you actually have ever used React but every single major version update is non breaking. The topics discussed in the link provided are discussing how an internal library is being updated (Context API) and how these functions are being depreciated in version 17 (https://reactjs.org/blog/2018/03/27/update-on-async-rendering.html https://reactjs.org/blog/2018/03/27/update-on-async-renderin...). The above depreciations are functions that typically should not be used in a v16 React application anyway! Using them typically means there lies a bug in your props updating logic.
- flukus 8y ago
  > I'm not sure if you actually have ever used React but every single major version update is non breaking. That would be fine if they were making major releases every 2+ years, when you release a major version on average of 3 times a year it's incredibly unstable. A typical upgrade will be jumping several versions.
  - gr__or 8y ago
    A major version change of React is different from a major version change in Angular. I upgraded several React apps of variying sizes from 14 to 17 over time and none of these upgrades took more than an hour. Don't get confused by the version labeling scheme.
8y ago

bsenftner 8y ago

One can nit pick some of his points, but the general essay is right on point. Developers need to understand what they are building on top of to be able to navigate non-trivial problems. I found this article from Saturday worth the read, as it explains what Docker actually is, and why no one needs it: http://catern.com/posts/docker.html http://catern.com/posts/docker.html. The same goes for everyone working in the cloud; I've build my own clusters to compare the effort and expense (rather than just accept the marketing line) and running one's own servers, from one to hundreds, is exponentially more cost effective than any cloud service. People are not doing their homework, and the herd mentality owns the entire tech industry.

galois198 8y ago
Please could you elaborate on the cloud vs on-premise comparison? Are you including the initial on-prem costs of buying the hardware?
- bsenftner 8y ago
  Yep. The expense of the cloud is crazy; in most corporate situations the expense of purchasing the same servers used by the cloud service is 1/4 your monthly cloud bill. The markup is unethically high, so they've brainwashed an entire generation of young developers and their equality naive CTOs that this is anything other than a swindle. Running a server is child's play, people. Don't believe the hype!
  - mmt 8y ago
    People may have a strong reaction to the word "crazy", but I'm not sure what else to call it, other than "mass delusion" or "mass hallucination". I've done this analysis for (mostly small-scale) companies for about 10 years, and, every time, the cost of using public cloud computing has been 2x-10x of running ones own servers for 3 years. I've only had one exception, where the incremental cost of compute was 1:1, if the servers were placed in more expensive space near the other servers in the existing datacenter. Data transfer costs made cloud more expensive, of course. > Running a server is child's play, people. I'd say that's a bit of a hyperbole, but I agree that the incremental expertise (and time/effort) required to deal with hardware over cloud, is far from the prohibitve headache it's made out to be.

GuB-42 8y ago

That's called experience. This is the reason why senior developers are normally paid more and make the important decisions. And what the article tells is that you should actually get interested in what you are doing, if you want to become experienced and not just old. That should be common sense, but I guess it is worth repeating from time to time. However, if you don't have 30 years of experience, ranging from coding on a C64 to modern JS frameworks, the Lindy effect (older technology tends to stay longer) is a good shortcut.

swsieber 8y ago
To build upon your comment: It's not because older technology is inherently better, but it's because if older technology is still relevant, it's survived the "will it be relevant in the future" test once before.
mgrennan 8y ago
As a person with 40+ years experence (Yes I started with a 4004) I aggee. Change is constend and the advancement of more and more complex systems is inevitable. Most of these is good but some with issues. The quote "A sufictly advanced technology is indistinguishable from magic" describes an ADVANCED tech. I believe it is the speed we are developing the tech that is the problem. We are more often then not ignoring the wisdom of senior developers.
flukus 8y ago
> That's called experience. This is the reason why senior developers are normally paid more and make the important decisions. The problem is we obtain that "senior" title long before we have this experience. Then when it's finally deserved (the 10+ year mark) the pressure starts mounting to move into architecture/management roles. And let's not forget the "old man can't keep up" that's always been rampant. The industry as a whole seems to consider experience as a liability.

mgrennan 8y ago

I have developed a term for this. EARLY ADOPTER TECH DEBT.

ak39 8y ago
Early Adopter Margin Call

blackrock 8y ago

Which technology stack would you recommend going forward? And why? Node.js? Vue.js? React? Angular? Elm? I can't keep up with the Javascript tower of babel anymore. And what happened to Django? Nobody seems to talk about it anymore.

iamcasen 8y ago
Django is by far the best full-stack MVC solution IMO. It is well known in python communities, and python is growing in popularity year over year. As for your javascript questions: React is the answer. Not just because it has the considerable resources of Facebook backing it, but because at it's core, the idea is extremely sound and well tested, going back 30 or more years. Vue.js has similar principles and might also be a good choice, but what you need to look out for is the community surrounding it, and whether it will eventually be unsupported. Node.js is great in the backend, but doesn't have quite as many mature frameworks like Django. If you're down to build things from bare metal using some libraries like Express.js or Koa.js, then you'll enjoy Node.js. Typescript and Flow have also made Node more attractive.
deltron3030 8y ago
> Which technology stack would you recommend going forward? And why? With React you have the most options and biggest community, including ways to shoot yourself in the foot. It's preferred by full stack JS guys who also use node, so it could be great if you're a startup and can hire somebody who can do everything. Angular is popular with enterprises who know what they need (a stable environment at scale with strict rules), who have a high budget for hiring specialists, the whole framework is more complex. Vue sits in between Angular and React, but more geared towards smaller businesses and their needs. It's very popular with PHP devs, and full stack devs who don't use JS exclusively. The main advantage is peace of mind, knowing that everything works well togehter. Elm is very opinionated, but also very different from those other frameworks. In React or Vue you start thinking of components, in Elm you think about functionality, and create components as they emerge from patterns, potentially leading to a more cohesive and elegant result. But that's not how designers used to work. Bridging the gap between designers and devs, and how they currently work, is the main advantage of React and Vue imo. Web designers (like graphic designers) are used to think in whole pages, or layouts, and break things down from there (top-down). React and Vue and the component first paradigm is a compromise, where devs aren't degraded into only doing the implemetation, and designers aren't degraded into doing the styling only. It still respects both roles. Elm is basically the next level for designers, or designers who like to code. It's how design that left the analog world behind could be.

IloveHN84 8y ago

This obviously is a problem of new languages/high dynamical frameworks.. Why this isn't happening for languages such as C, C++, Java? Sure, new standards are kicking in, but you can still program using old standard, it will continue (more or less) to work. Why do JS developers follow overhyped frameworks? I do not understand.. the few times I've programmed in JavaScript, I've always used jQuery: it might be old school, but it does its job well and bootstrap is still using it too.

mabynogy 8y ago

"A trailblazzer doesn't follow a trail" as Terry Davis says.