3 ms·

> we need to do something Do something about what? Lots of discarded projects on Github? Too many people working with Javascript? Fast iteration? Lowering bar

> we need to do something Do something about what? Lots of discarded projects on Github? Too many people working with Javascript? Fast iteration? Lowering barriers to entry? Those all sound like good (or at least neutral) things to me. I've clearly missed the point of this post.

xeLL 12y ago
Maybe the point is maintainability?
- colin_jack 12y ago
  I'm not sure I really buy it, if you want to use the libraries/frameworks others are using that's easy, there's plenty of content out there that pushes you in the right direction. You can also take a punt on a framework/library that hasn't been maintained, or doesn't seem to have much interest, but that's your choice.
- rhizome31 12y ago
  Before picking a library, one should do some research: take a look at the issue tracker, the mailing-list, open the source code, etc. It will give a good idea whether it's a good bet or not. I don't think this issue is specific to JavaScript. Note that the author comes from Java. Developpers coming from dynamic languages will be much less annoyed by JavaScript vibrant ecosystem.
emodendroket 12y ago
Did you read it?
- HCIdivision17 12y ago
  I did, and I somewhat agree with `richmarr. The author of the blog does have a point, and it's not really wrong much, but I've come to the fairly strong opinion it's an unhelpful thing to complain about publically. (Which is a slightly ironic stance, I admit.) As a plant engineer, you're going to have to part out and understand a system in its entirety at some point. And you'll be rating bolts and nuts and greases and such to meet the specification you need. There are a lot of bolts to choose from. It's the same for chips or components when designing a circuit: there are lots of transistors to choose from. For many tasks, many will effectively be interchangable. Sometimes you'll need to be careful, and other times you'll be working on a system where you'll need to research the manufacturer to make sure they're likely to be still in business in ten years. But you'd never reasonably complain about the choice. Nor about all the regular folk just building a porch out of some wood and screws from Home Depot. You wouldn't complain about a kid learning circuitry by plopping some random components from Radio Shack into a breadboard (which they'll never move to a proper PCB). And I don't see why you'd complain about millions of people interacting with software the same way. Learning to deal with the glut is as simple as going to a curated aggregator (Home Depot/Radio Shack) or becoming an engineer. I've seen the sort of stuff non-programmers inflict on systems. I'm not even talking about JS on the web, but like simple relay-equivalent ladder logic on heavy machinery. It's just as bad there. But. Work needs to get done, production needs to move forward, and craftsmanship is expensive and time consuming. There's a place for the cowboy programmer, just as there is for the craftsman. So it seems a bit silly to complain about the situation. To me, it just means software is becoming an industry just like any other.
  - emodendroket 12y ago
    To me, it seems more like what's happening is a lot of people think it's less interesting to work on an existing, established product than to rewrite it altogether or make a new one and so we're seeing a steady procession of neat but immature frameworks instead of a mature one gaining steam. This, to me, is a problem because it means programmers waste a ton of time learning the incantations for a new framework instead of focusing on the actual problems they're trying to solve. It's like if you switched between similar programming languages for every new project you started without becoming very familiar with any of them.
logicalmind 12y ago
In my simplified view, I think we need to do something about the fact that you cannot build an application today that will not be obsolete in 6 months (at best). And by obsolete, we're not talking about obsolete like a COBOL application. We're talking about relying entirely on frameworks/libraries that may literally no longer exist. Think about an angular 1.x application 5 years from now. If you're building an application that will take a non-trivial amount of time to build and will have a lifetime of years, what technologies would you pick? How do you train your team members? What is your strategy for maintaining it into the future? If someone built a webapp 10 years ago, it would be php, rails, asp.net, java, etc. And you can find someone who would (possibly reluctantly) get in there and do something with it. But what about the app built using 20 npm libs. What do they do in 10 years?
- steveax 12y ago
  > But what about the app built using 20 npm libs. What do they do in 10 years? Read the code, just like they'd read the PHP/Ruby/whatever? Not sure I understand what problem you're suggesting.
- twerquie 12y ago
  > What do they do in 10 years? Where is this mystical app that gets sudden developer attention after 10 years of maintenance-free use? I've never come across a 10 year old application that hasn't been actively maintained that didn't need at least parts rewritten.

xeLL 12y ago

Maybe the point is maintainability?

colin_jack 12y ago
I'm not sure I really buy it, if you want to use the libraries/frameworks others are using that's easy, there's plenty of content out there that pushes you in the right direction. You can also take a punt on a framework/library that hasn't been maintained, or doesn't seem to have much interest, but that's your choice.
rhizome31 12y ago
Before picking a library, one should do some research: take a look at the issue tracker, the mailing-list, open the source code, etc. It will give a good idea whether it's a good bet or not. I don't think this issue is specific to JavaScript. Note that the author comes from Java. Developpers coming from dynamic languages will be much less annoyed by JavaScript vibrant ecosystem.

emodendroket 12y ago

Did you read it?

HCIdivision17 12y ago
I did, and I somewhat agree with `richmarr. The author of the blog does have a point, and it's not really wrong much, but I've come to the fairly strong opinion it's an unhelpful thing to complain about publically. (Which is a slightly ironic stance, I admit.) As a plant engineer, you're going to have to part out and understand a system in its entirety at some point. And you'll be rating bolts and nuts and greases and such to meet the specification you need. There are a lot of bolts to choose from. It's the same for chips or components when designing a circuit: there are lots of transistors to choose from. For many tasks, many will effectively be interchangable. Sometimes you'll need to be careful, and other times you'll be working on a system where you'll need to research the manufacturer to make sure they're likely to be still in business in ten years. But you'd never reasonably complain about the choice. Nor about all the regular folk just building a porch out of some wood and screws from Home Depot. You wouldn't complain about a kid learning circuitry by plopping some random components from Radio Shack into a breadboard (which they'll never move to a proper PCB). And I don't see why you'd complain about millions of people interacting with software the same way. Learning to deal with the glut is as simple as going to a curated aggregator (Home Depot/Radio Shack) or becoming an engineer. I've seen the sort of stuff non-programmers inflict on systems. I'm not even talking about JS on the web, but like simple relay-equivalent ladder logic on heavy machinery. It's just as bad there. But. Work needs to get done, production needs to move forward, and craftsmanship is expensive and time consuming. There's a place for the cowboy programmer, just as there is for the craftsman. So it seems a bit silly to complain about the situation. To me, it just means software is becoming an industry just like any other.
- emodendroket 12y ago
  To me, it seems more like what's happening is a lot of people think it's less interesting to work on an existing, established product than to rewrite it altogether or make a new one and so we're seeing a steady procession of neat but immature frameworks instead of a mature one gaining steam. This, to me, is a problem because it means programmers waste a ton of time learning the incantations for a new framework instead of focusing on the actual problems they're trying to solve. It's like if you switched between similar programming languages for every new project you started without becoming very familiar with any of them.

logicalmind 12y ago

In my simplified view, I think we need to do something about the fact that you cannot build an application today that will not be obsolete in 6 months (at best). And by obsolete, we're not talking about obsolete like a COBOL application. We're talking about relying entirely on frameworks/libraries that may literally no longer exist. Think about an angular 1.x application 5 years from now. If you're building an application that will take a non-trivial amount of time to build and will have a lifetime of years, what technologies would you pick? How do you train your team members? What is your strategy for maintaining it into the future? If someone built a webapp 10 years ago, it would be php, rails, asp.net, java, etc. And you can find someone who would (possibly reluctantly) get in there and do something with it. But what about the app built using 20 npm libs. What do they do in 10 years?

steveax 12y ago
> But what about the app built using 20 npm libs. What do they do in 10 years? Read the code, just like they'd read the PHP/Ruby/whatever? Not sure I understand what problem you're suggesting.
twerquie 12y ago
> What do they do in 10 years? Where is this mystical app that gets sudden developer attention after 10 years of maintenance-free use? I've never come across a 10 year old application that hasn't been actively maintained that didn't need at least parts rewritten.