4 ms·

If you can't afford to be on the cutting-edge, you use battle-tested technologies, and let the people who can afford it do their thing to shake out which produc

If you can't afford to be on the cutting-edge, you use battle-tested technologies, and let the people who can afford it do their thing to shake out which products are worth keeping around. That's sort of the right approach for any software development, yeah?

innocentoldguy 10y ago
Yeah, but most other technologies don't have new libraries and frameworks coming out every other day. For example, with Ruby, the community has stuck with Rails and Sinatra for more than a decade now. With Python, most developers go with Django or Flask. With Elixir, Phoenix or Plug. With Javascript/Node, however, you have Hapi.js, Sails.js, Mean.js, Koa, Socket.io, Mojito, Express.js, Meteor, Mithril.js, Derby, and others, not to mention the front-end options, like Angular, React, Svelte, etc., Some of these frameworks are even written by the same developers to accomplish largely the same thing (e.g. Express vs. Koa). This doesn't seem like a great strategy for long-term success. It got to the point with me that I didn't want to invest any more time in Javascript technologies, simply because their lifespans seemed to be quite short, compared to other options. In the Javascript community, framework feel disposable. I don't mind learning, but there has to be time for implementation and mastery, and there has to be some level of long-term career payoff for the time invested in learning. For example, I can still get any number of Rails jobs after 11 or 12 years of using the framework. Can the same be said of the original Express.js? I know it isn't a comprehensive, scientific study, but a quick search on local job boards in my area turns up 15 Rails jobs, and no Express.js jobs. No Hapi.js jobs. No Metor jobs. No Mithril.js jobs. No Derby jobs. I don't mean to take away from the successes the Javascript community has had over the years. Javascript is certainly in a better state than it was a decade ago. However, having so many libraries and frameworks come and go so quickly isn't a good thing, in my opinion. I think the community could benefit a lot by embracing more cohesion and focus, but that's just my opinion, based on my experience with other languages and communities.
- macinjosh 10y ago
  I find it kinda funny because we finally have decent cross browser consistency on the front-end, which back in the day, was the main frustration point of front-end dev. Now the problem is finding a framework that you can depend on and invest in long term. Makes me wonder if the browser wars turned front-end devs into masochists and now the only way to satisfy that urge for pain is to reinvent their frameworks on a regular basis. /s
  - tracker1 10y ago
    Angular isn't going away, even 1.x will probably see updates for another 3-5 years. React also isn't going anywhere with the heavy hitters behind it... although there may be some migration to react-alikes that use jsx etc, but the techniques in the apps are largely the same. Vue.js is probably here for a while, though a little uncertain, there's definitely some desire there. I'm not sure about Polymer and web-components, I think there will definitely be more web-component packages to work from in the future, but for now, just kind of holding off myself. I'm pretty actively following the JS world, and tbh in 2012 I felt so in over my head as npm was growing... It's gotten easier. In general, your best bet is to stay a little behind the bleeding edge and look at what the heavy hitters are investing time/money in, and beyond that what you like. I'm pretty heavy in the React camp (including Preact, Inferno, etc)... Most of the look-alikes are compatible enough to work, or have a similar enough workflow. I happen to like the component structure, and am a fan of Redux as well. Others have hunkered down for Angular2+.
    - macinjosh 10y ago
      I totally agree that those things are not going to simply disappear. It just seems that every new framework supposedly has some distinct advantage that previous frameworks lack and the urge of most front-end devs is to move on to the next shiny thing. If you don't move onto the next shiny thing you are considered to be some sort of luddite or ignorant to the amazing new thing a new framework has. So while I can pick a framework like the ones you mentioned and stick with it convincing team mates or colleagues to do the same becomes difficult.
- allover 10y ago
  Counterarguments: The older libraries (that caught on) are still perfectly fine to use. There's no reason you can't still be running an Express.js app with Backbone.js + RequireJS (for modules) in the front-end. We have a Backbone.js + RequireJS app at work and it's totally fine, well structured OOP, and arguably a great codebase in comparison to some Angular 1 architecture horror-stories I've heard about. Of course it takes strong, level-headed devs to say "no we're not rewriting it in Angular". In terms of jobs, being able to search for 'framework + jobs' is kind of insane anyway. 'language + jobs' makes more sense, a dev should be able to pickup any framework pretty quickly. Not everyone in the Ruby community was that happy that Rails become so defining, you could argue that it was an anomaly to have a language so dominated by 1 framework. That said I do prefer Rails/Django over any backend Node framework to-date, at least when it comes to the DB/ORMs/migrations story (which then lead to mature CMSs too), so I don't love that no Node backend framework grew comparable mindshare there.
  - tracker1 10y ago
    I'd counter your last point and ask is an ORM really necessary... especially since most DBMS with Node modules have tagged template literals to parameterized queries. In general the responses from databases are usually very easy to use without the cruft and limitations regarding ORMS. As for migrations, I'm a little more old-school, I prefer versioned scripts/rollbacks that are hand-crafted for SQL, or for very large document/column databases on-read/save upgrades. Backbone works... though I was in the browserify camp over requirejs/amd, mainly because I wanted the same syntax/modules without umd overhead... moving towards Webpack was a sinch. Keeping what works is often a good idea, I wouldn't suggest even trying to rewrite everything in one pass for most things. To GP, almost everything revolves around Express server-side, there are other options, but that's still the bulk of the mindshare in my experience, even if I do like the way Koa works slightly better. For that matter, jQuery really rules the world still, even if the mindshare has declines, and likely wouldn't reach for it for new projects.
  - innocentoldguy 10y ago
    Thank you for your commentary, allover. You do bring up a good point, I think. It does address a slightly different issue than I wanted to bring up though. Consider this: I can still use Delphi to make Windows apps too, but where am I going to find a job? Being able to use an old tool isn't my point. My point is that while you may still be using Express.js where you work, there are many other Javascript companies who aren't using it anymore. They've moved on. Even the Express.js developers have moved on to something else (Koa), so by mastering Express.js, you sort of paint yourself into a corner in your career. You most likely won't show up on recruiting radars, since you don't have the latest JS buzzwords on your résumé, and if you try to go get another Express.js job on your own, you'll have a more difficult time of it. The high turnover rate of JS frameworks works to your detriment, I would think, because it is more difficult to keep up with all the moving targets. If JS programmers don't see their framework-du-jour culture as a problem, then by all means, keep doing it. I just think you'd be better off, and attract more developers, if you congregated around the best framework or two out there, and worked to make them the best they can be, instead of re-inventing the wheel every other day. I'm simply bringing it up as a point to consider for making the JS community more stable and cohesive, and worthy of personal investment. I know this fly-by-night aspect of the Javascript community is one of the reasons I don't bother with server-side JS. I know a lot of other developers in my area who feel the same way. Just something to consider...

innocentoldguy 10y ago

Yeah, but most other technologies don't have new libraries and frameworks coming out every other day. For example, with Ruby, the community has stuck with Rails and Sinatra for more than a decade now. With Python, most developers go with Django or Flask. With Elixir, Phoenix or Plug. With Javascript/Node, however, you have Hapi.js, Sails.js, Mean.js, Koa, Socket.io, Mojito, Express.js, Meteor, Mithril.js, Derby, and others, not to mention the front-end options, like Angular, React, Svelte, etc., Some of these frameworks are even written by the same developers to accomplish largely the same thing (e.g. Express vs. Koa). This doesn't seem like a great strategy for long-term success. It got to the point with me that I didn't want to invest any more time in Javascript technologies, simply because their lifespans seemed to be quite short, compared to other options. In the Javascript community, framework feel disposable. I don't mind learning, but there has to be time for implementation and mastery, and there has to be some level of long-term career payoff for the time invested in learning. For example, I can still get any number of Rails jobs after 11 or 12 years of using the framework. Can the same be said of the original Express.js? I know it isn't a comprehensive, scientific study, but a quick search on local job boards in my area turns up 15 Rails jobs, and no Express.js jobs. No Hapi.js jobs. No Metor jobs. No Mithril.js jobs. No Derby jobs. I don't mean to take away from the successes the Javascript community has had over the years. Javascript is certainly in a better state than it was a decade ago. However, having so many libraries and frameworks come and go so quickly isn't a good thing, in my opinion. I think the community could benefit a lot by embracing more cohesion and focus, but that's just my opinion, based on my experience with other languages and communities.

macinjosh 10y ago
I find it kinda funny because we finally have decent cross browser consistency on the front-end, which back in the day, was the main frustration point of front-end dev. Now the problem is finding a framework that you can depend on and invest in long term. Makes me wonder if the browser wars turned front-end devs into masochists and now the only way to satisfy that urge for pain is to reinvent their frameworks on a regular basis. /s
- tracker1 10y ago
  Angular isn't going away, even 1.x will probably see updates for another 3-5 years. React also isn't going anywhere with the heavy hitters behind it... although there may be some migration to react-alikes that use jsx etc, but the techniques in the apps are largely the same. Vue.js is probably here for a while, though a little uncertain, there's definitely some desire there. I'm not sure about Polymer and web-components, I think there will definitely be more web-component packages to work from in the future, but for now, just kind of holding off myself. I'm pretty actively following the JS world, and tbh in 2012 I felt so in over my head as npm was growing... It's gotten easier. In general, your best bet is to stay a little behind the bleeding edge and look at what the heavy hitters are investing time/money in, and beyond that what you like. I'm pretty heavy in the React camp (including Preact, Inferno, etc)... Most of the look-alikes are compatible enough to work, or have a similar enough workflow. I happen to like the component structure, and am a fan of Redux as well. Others have hunkered down for Angular2+.
  - macinjosh 10y ago
    I totally agree that those things are not going to simply disappear. It just seems that every new framework supposedly has some distinct advantage that previous frameworks lack and the urge of most front-end devs is to move on to the next shiny thing. If you don't move onto the next shiny thing you are considered to be some sort of luddite or ignorant to the amazing new thing a new framework has. So while I can pick a framework like the ones you mentioned and stick with it convincing team mates or colleagues to do the same becomes difficult.
allover 10y ago
Counterarguments: The older libraries (that caught on) are still perfectly fine to use. There's no reason you can't still be running an Express.js app with Backbone.js + RequireJS (for modules) in the front-end. We have a Backbone.js + RequireJS app at work and it's totally fine, well structured OOP, and arguably a great codebase in comparison to some Angular 1 architecture horror-stories I've heard about. Of course it takes strong, level-headed devs to say "no we're not rewriting it in Angular". In terms of jobs, being able to search for 'framework + jobs' is kind of insane anyway. 'language + jobs' makes more sense, a dev should be able to pickup any framework pretty quickly. Not everyone in the Ruby community was that happy that Rails become so defining, you could argue that it was an anomaly to have a language so dominated by 1 framework. That said I do prefer Rails/Django over any backend Node framework to-date, at least when it comes to the DB/ORMs/migrations story (which then lead to mature CMSs too), so I don't love that no Node backend framework grew comparable mindshare there.
- tracker1 10y ago
  I'd counter your last point and ask is an ORM really necessary... especially since most DBMS with Node modules have tagged template literals to parameterized queries. In general the responses from databases are usually very easy to use without the cruft and limitations regarding ORMS. As for migrations, I'm a little more old-school, I prefer versioned scripts/rollbacks that are hand-crafted for SQL, or for very large document/column databases on-read/save upgrades. Backbone works... though I was in the browserify camp over requirejs/amd, mainly because I wanted the same syntax/modules without umd overhead... moving towards Webpack was a sinch. Keeping what works is often a good idea, I wouldn't suggest even trying to rewrite everything in one pass for most things. To GP, almost everything revolves around Express server-side, there are other options, but that's still the bulk of the mindshare in my experience, even if I do like the way Koa works slightly better. For that matter, jQuery really rules the world still, even if the mindshare has declines, and likely wouldn't reach for it for new projects.
- innocentoldguy 10y ago
  Thank you for your commentary, allover. You do bring up a good point, I think. It does address a slightly different issue than I wanted to bring up though. Consider this: I can still use Delphi to make Windows apps too, but where am I going to find a job? Being able to use an old tool isn't my point. My point is that while you may still be using Express.js where you work, there are many other Javascript companies who aren't using it anymore. They've moved on. Even the Express.js developers have moved on to something else (Koa), so by mastering Express.js, you sort of paint yourself into a corner in your career. You most likely won't show up on recruiting radars, since you don't have the latest JS buzzwords on your résumé, and if you try to go get another Express.js job on your own, you'll have a more difficult time of it. The high turnover rate of JS frameworks works to your detriment, I would think, because it is more difficult to keep up with all the moving targets. If JS programmers don't see their framework-du-jour culture as a problem, then by all means, keep doing it. I just think you'd be better off, and attract more developers, if you congregated around the best framework or two out there, and worked to make them the best they can be, instead of re-inventing the wheel every other day. I'm simply bringing it up as a point to consider for making the JS community more stable and cohesive, and worthy of personal investment. I know this fly-by-night aspect of the Javascript community is one of the reasons I don't bother with server-side JS. I know a lot of other developers in my area who feel the same way. Just something to consider...