5 ms·

Sorry but I find font-end development pretty stable. Having to learn a new library every 3-4 years (because of a new job, generally) is it really a big deal?

Sorry but I find font-end development pretty stable. Having to learn a new library every 3-4 years (because of a new job, generally) is it really a big deal? In my career I also had to learn Java, PHP, C#, Node.js, bash, batch, Python… Build apps with Spring, CakePHP, Symfony 1 & 2, ASP.NET MVC 3 & 4… Query database with Hibernate, Entity Framework, Linq SQL… Handle dependencies with Maven, Nugget… Store data in Postgres, MySQL, SQL Server, Mongo, Redis, Redshift… Host on OVH, Digital Ocean, Heroku, AWS… Learn REST and GraphQL, SVN and Git, Linux and Windows Server, Vagrant and Docker… And according to HN, what's really hype right now is Rust, Go, FoundationDB, Kubernetes, and so on… Any idea why back-end development is so unstable? :)

guessmyname 8y ago
I think the title is referring to the ecosystem and not the technology. • How many frameworks for Java, Python, Bash, etc did you have to learn? • Did you switch from Redis to X because the former was deprecated N months later? • Are OVH, Heroku, AWS updates getting in the way of your development process? Learning a technology by itself like Node.js is not a problem, the problem is that front-end development nowadays requires so many small and fragile tools just to build a web application compared to the number of tools that you would need in another language like C# where the most recognized libraries are several times more stable and change with much less frequency. Mentioning things like database engines, cloud platforms and version control tools is out of the scope of the discussion because they are encapsulated tools, and at least the ones that you mentioned (before you updated your comment) have a very low release rate, and to my opinion are very-very stable in comparison with the JavaScript ecosystem. > Having to learn a new library every 3-4 years (usually when starting a new job) is it really a big deal? Yes, it is. > In my career I also had to learn … Not for the same project and/or development cycle, but surprise me if I that's the case. > And according to HN, what's really hype right now is Rust, Go, FoundationDB, Kubernetes, and so on People stick to them and that's it, I don't know any serious company changing their tech stack every N months just because they are trendy on HN. Several years later they may switch to a new tech stack because the project requirements have changed but not because the author of one of the thousand libraries that you are importing decided to carelessly modify a feature that another dozen libraries use, consequently breaking not just your code but also many others. Or, in another scenario, your package manager doesn't betray you by destroying all your file system during a careless upgrade [1]. > Learn REST and GraphQL, SVN and Git, Linux and Windows Server, Vagrant and Docker You are missing the point entirely… We are talking about how "unstable" front-end development is, not how many tools you have to learn. If I could learn 10-20 tools for front-end development and be certain that they will not drastically change in a year or so, or at least get deprecated, then — and only then — I would not have to worry so much about available updates via the main and (unfortunately) only package manager that the JavaScript community have. [1] https://github.com/npm/npm/issues/19883 https://github.com/npm/npm/issues/19883
- tracker1 8y ago
  I've only seen one issue in React that affected me.. when they started requiring PascalCase for component names with JSX. Everything else has been really nice. I glommed onto Redux and thunks pretty early on, and have been wrapping around fetch about as long. I used Bootstrap for a long time, and progressed to material-ui with very little disconnect. Those have been my personal preferences for several years, and they haven't changed THAT much in terms of usage. Now that's nothing like I've seen with say Angular, Angular2-6 (including the long, painful Angular 2 beta cycle). I've also seen tooling evolve, and some of that painful... Webpack and Babel have changed a lot. create-react-app doesn't solve it all, but helps abstract some of it. Node has had growing pains and is finally fairly stable for those developing/adapting native code to run in node. I haven't really had to re-learn anything for a project as it's progressed any more than I did 15 years ago on the backend.
  - acemarke 8y ago
    The JSX transform has, as far as I know, _always_ required PascalCase for component names. That's how it distinguishes between "this tag name is actually a variable pointing to a component" and "this tag name should be turned into a string".
    - tracker1 8y ago
      Nope.. early on, you could use any local variable... there was a whitelist of html elements... they did a cleanup that required the PascalCase and defaulted to html element render for anything else. It was around 0.10 or so, iirc.
Doctor_Fegg 8y ago
> Having to learn a new library every 3-4 years (because of a new job, generally) is it really a big deal? _If_ frontend development is all you do, then no, it isn't. One of the good things about the internet is that it's possible for a lone wolf to build and ship something amazing. One person can understand enough of the full stack, from HTML/CSS through JS to a serverside language and basic server administration, to build something great, unfunded. The constant churn in frontend development makes that increasingly difficult. If you find a useful library for your backend code, great, just 'gem install' it (or pip or whatever). Useful JS library for your frontend code? You've got to learn the packaging technology du jour just to be able to install it. In two years' time this'll be different, and you'll have to get to grips with another complex web of tiny little components that fit together in ways you don't fully understand. Whereas your backend (for me, Ruby+Postgres) is still essentially the same it's always been, and just as great. Indie full-stack developers can no longer keep up with frontend development, and I think that's a great loss.
- Cthulhu_ 8y ago
  I've recently gone back to do some Java development after idk, five years of front-end and mobile, and the tooling and frameworks are still the same. A bit more polished maybe, but, Java, Spring, Gradle, bit of Hibernate (urgh), bit of Jackson magic, not much has changed since then, so it was pretty easy to get back up to speed in that area.
- Raphmedia 8y ago
  > Indie full-stack developers can no longer keep up with frontend development, and I think that's a great loss. Who exactly? Did you ever hear a front-end developer say that or are you building a strawman? There's nothing stopping anyone from building a simple jQuery powered website. There's nothing stopping anyone from building an app with Angular 1 either. Hell, you can even download .zip files on GitHub, unarchive them in a folder and start using them in your projects. Complex build system are only a way to streamline development when you get to a certain level of projects output.
  - lolsal 8y ago
NullPrefix 8y ago
>Store data in Postgres, MySQL, SQL Server >British English, American English, Australian English
janoc 8y ago
If all you do is developing applications that don't need to be maintained for 10 years or longer (as many business applications do), then you are fine. Otherwise you are horribly screwed if you try to buy in into the current HTML-based fronted development.
christophilus 8y ago
Did you read the article? Here's a snippet from the beginning: > Do front end technologies actually change that quickly? > In the sense of major view technologies, probably not... Consider this list of the highest ‘starred’ JavaScript front-end technologies on Github: +------------------------------------------------------------+ | Library | Stars | Released | Age | |------------------------------------------------------------+ | React | 96986 | March 2015 | 3 years | | Vue | 95727 | October 2015 | 2.5 years | | Angular (1) | 58531 | October 2010 | 7.5 years | | jQuery | 49061 | August 2006 | 11 years | | Angular (2+) | 36665 | December 2015 | 2.5 years | | Backbone | 27194 | October 2010 | 7.5 years | | Polymer | 19668 | May 2015 | 3 years | | Ember | 19003 | December 2011 | 6.5 years | | Aurelia | 10506 | June 2016 | 2 years | | Knockout | 8894 | July 2010 | 8 years | +------------------------------------------------------------+ > 2.5 years for the youngest isn’t that old in the scheme of things - it’s less than half the support lifespan of your typical desktop OS, for example - but it’s still a ways off our caricature. So what is causing this perception of rapid, even unsustainable change?
- Raphmedia 8y ago
  I never understood this argument. You are comparing frameworks. All of those are nothing but fancy ways to play with the DOM. There's nobody telling anyone to jump from one to the other. Do you migrate your PHP or .NET projects every time a new framework comes out? No. You shouldn't with front-end either. It's as if you printed a table that goes "CakePHP; Yii; CodeIgniter; Laravel; Symfony; Phalcon; Zend." and then complained about the PHP ecosystem.
  - filleduchaos 8y ago
    Did you actually read the argument though?
- bzalasky 8y ago
  Small correction on the chart, React has actually been open sourced for ~5 years, React Native is ~3 years old. As far as how fast frontend technologies are changing, in my ~10 year career, I've only had to use jQuery (~2008-present), Backbone (~2012-present) and React (2015-present) professionally. These libraries weren't swapped out on a whim, and I still use all 3 in different projects on a weekly basis. While I've dabbled with most of the others, I haven't selected them or encountered them professionally. To some extent, I think library churn can be attributed to keeping things interesting when the problems you're solving are less interesting. Most frontend engineers could probably benefit from rolling their own SPA library (not for production use, but to learn how the different pieces come together). There's probably room for a few more "From Scratch" tutorials in this space akin to Destroy All Software's series of screencasts. Working through something like this would make it clear that the differences between the libraries above are smaller than it might otherwise seem.

guessmyname 8y ago

I think the title is referring to the ecosystem and not the technology. • How many frameworks for Java, Python, Bash, etc did you have to learn? • Did you switch from Redis to X because the former was deprecated N months later? • Are OVH, Heroku, AWS updates getting in the way of your development process? Learning a technology by itself like Node.js is not a problem, the problem is that front-end development nowadays requires so many small and fragile tools just to build a web application compared to the number of tools that you would need in another language like C# where the most recognized libraries are several times more stable and change with much less frequency. Mentioning things like database engines, cloud platforms and version control tools is out of the scope of the discussion because they are encapsulated tools, and at least the ones that you mentioned (before you updated your comment) have a very low release rate, and to my opinion are very-very stable in comparison with the JavaScript ecosystem. > Having to learn a new library every 3-4 years (usually when starting a new job) is it really a big deal? Yes, it is. > In my career I also had to learn … Not for the same project and/or development cycle, but surprise me if I that's the case. > And according to HN, what's really hype right now is Rust, Go, FoundationDB, Kubernetes, and so on People stick to them and that's it, I don't know any serious company changing their tech stack every N months just because they are trendy on HN. Several years later they may switch to a new tech stack because the project requirements have changed but not because the author of one of the thousand libraries that you are importing decided to carelessly modify a feature that another dozen libraries use, consequently breaking not just your code but also many others. Or, in another scenario, your package manager doesn't betray you by destroying all your file system during a careless upgrade [1]. > Learn REST and GraphQL, SVN and Git, Linux and Windows Server, Vagrant and Docker You are missing the point entirely… We are talking about how "unstable" front-end development is, not how many tools you have to learn. If I could learn 10-20 tools for front-end development and be certain that they will not drastically change in a year or so, or at least get deprecated, then — and only then — I would not have to worry so much about available updates via the main and (unfortunately) only package manager that the JavaScript community have. [1] https://github.com/npm/npm/issues/19883 https://github.com/npm/npm/issues/19883

tracker1 8y ago
I've only seen one issue in React that affected me.. when they started requiring PascalCase for component names with JSX. Everything else has been really nice. I glommed onto Redux and thunks pretty early on, and have been wrapping around fetch about as long. I used Bootstrap for a long time, and progressed to material-ui with very little disconnect. Those have been my personal preferences for several years, and they haven't changed THAT much in terms of usage. Now that's nothing like I've seen with say Angular, Angular2-6 (including the long, painful Angular 2 beta cycle). I've also seen tooling evolve, and some of that painful... Webpack and Babel have changed a lot. create-react-app doesn't solve it all, but helps abstract some of it. Node has had growing pains and is finally fairly stable for those developing/adapting native code to run in node. I haven't really had to re-learn anything for a project as it's progressed any more than I did 15 years ago on the backend.
- acemarke 8y ago
  The JSX transform has, as far as I know, _always_ required PascalCase for component names. That's how it distinguishes between "this tag name is actually a variable pointing to a component" and "this tag name should be turned into a string".
  - tracker1 8y ago
    Nope.. early on, you could use any local variable... there was a whitelist of html elements... they did a cleanup that required the PascalCase and defaulted to html element render for anything else. It was around 0.10 or so, iirc.

Doctor_Fegg 8y ago

> Having to learn a new library every 3-4 years (because of a new job, generally) is it really a big deal? _If_ frontend development is all you do, then no, it isn't. One of the good things about the internet is that it's possible for a lone wolf to build and ship something amazing. One person can understand enough of the full stack, from HTML/CSS through JS to a serverside language and basic server administration, to build something great, unfunded. The constant churn in frontend development makes that increasingly difficult. If you find a useful library for your backend code, great, just 'gem install' it (or pip or whatever). Useful JS library for your frontend code? You've got to learn the packaging technology du jour just to be able to install it. In two years' time this'll be different, and you'll have to get to grips with another complex web of tiny little components that fit together in ways you don't fully understand. Whereas your backend (for me, Ruby+Postgres) is still essentially the same it's always been, and just as great. Indie full-stack developers can no longer keep up with frontend development, and I think that's a great loss.

Cthulhu_ 8y ago
I've recently gone back to do some Java development after idk, five years of front-end and mobile, and the tooling and frameworks are still the same. A bit more polished maybe, but, Java, Spring, Gradle, bit of Hibernate (urgh), bit of Jackson magic, not much has changed since then, so it was pretty easy to get back up to speed in that area.
Raphmedia 8y ago
> Indie full-stack developers can no longer keep up with frontend development, and I think that's a great loss. Who exactly? Did you ever hear a front-end developer say that or are you building a strawman? There's nothing stopping anyone from building a simple jQuery powered website. There's nothing stopping anyone from building an app with Angular 1 either. Hell, you can even download .zip files on GitHub, unarchive them in a folder and start using them in your projects. Complex build system are only a way to streamline development when you get to a certain level of projects output.
- lolsal 8y ago

NullPrefix 8y ago

>Store data in Postgres, MySQL, SQL Server >British English, American English, Australian English

janoc 8y ago

If all you do is developing applications that don't need to be maintained for 10 years or longer (as many business applications do), then you are fine. Otherwise you are horribly screwed if you try to buy in into the current HTML-based fronted development.

christophilus 8y ago

Raphmedia 8y ago
I never understood this argument. You are comparing frameworks. All of those are nothing but fancy ways to play with the DOM. There's nobody telling anyone to jump from one to the other. Do you migrate your PHP or .NET projects every time a new framework comes out? No. You shouldn't with front-end either. It's as if you printed a table that goes "CakePHP; Yii; CodeIgniter; Laravel; Symfony; Phalcon; Zend." and then complained about the PHP ecosystem.
- filleduchaos 8y ago
  Did you actually read the argument though?
bzalasky 8y ago
Small correction on the chart, React has actually been open sourced for ~5 years, React Native is ~3 years old. As far as how fast frontend technologies are changing, in my ~10 year career, I've only had to use jQuery (~2008-present), Backbone (~2012-present) and React (2015-present) professionally. These libraries weren't swapped out on a whim, and I still use all 3 in different projects on a weekly basis. While I've dabbled with most of the others, I haven't selected them or encountered them professionally. To some extent, I think library churn can be attributed to keeping things interesting when the problems you're solving are less interesting. Most frontend engineers could probably benefit from rolling their own SPA library (not for production use, but to learn how the different pieces come together). There's probably room for a few more "From Scratch" tutorials in this space akin to Destroy All Software's series of screencasts. Working through something like this would make it clear that the differences between the libraries above are smaller than it might otherwise seem.