11 ms·

Watching the Javascript poorly reinvent the wheel has been very disappointing. Very simple mistakes like immutable, never changing build releases that Java deve

by dnomad 8y ago

Watching the Javascript poorly reinvent the wheel has been very disappointing. Very simple mistakes like immutable, never changing build releases that Java developers understood 15 years ago are become recent front page news in this community. Ironically, even though all the code is open-source pre-existing knowledge does not get leveraged in the open source world. There's a kind of market failure at work here it seems; the lack of commercial selective pressure results in the flourishing of lots of poorly researched OS solutions.

wolco 8y ago
I like the energy around the javascript everywhere movement. So what if they reinvent the wheel, sometimes you find a better wheel and break the rules along the way. There is something exciting about developers using a language in ways it was never designed. Then having the language change to support the changing ecosystem...
- ahansen 8y ago
  So true, at the end of the day people are working like this because it's the way they feel the most passionate about. You can't really blame them considering how disinterested people can get working on that last 10% of even their own projects.
  - kingludite 8y ago
    haha, why do we do this? Should we judge programmers by how finished their thing is? I think it is the most impressive quality when I see it (which is non of my own stuff haha)
- ppeetteerr 8y ago
  It's when you build a business on a technology and then have to re-invest to rebuild the product, that's when it becomes an issue. Think of all the start ups that built running businesses on Angular 1.
  - abiox 8y ago
    as far as i know, angular 1 still works just fine... :) (as it happens 1.7 was released recently.)
    - ppeetteerr 8y ago
      It does but try finding a developer looking to work on Angular 1
minitech 8y ago
> Very simple mistakes like immutable, never changing build releases Can you expand a bit more? Not sure what this means.
- dnomad 8y ago
  [1] https://en.wikipedia.org/wiki/Npm_(software)#Notable_breakage https://en.wikipedia.org/wiki/Npm_(software)#Notable_breakag..., [2] https://www.csoonline.com/article/3214624/security/malicious-code-in-the-node-js-npm-registry-shakes-open-source-trust-model.html https://www.csoonline.com/article/3214624/security/malicious..., [3] https://news.ycombinator.com/item?id=16087024 https://news.ycombinator.com/item?id=16087024 And the list goes on and on IMO. What's disappointing is that these were lessons learned a long time ago and now they're being re-learned.
  - staticassertion 8y ago
    This stuff isn't relevant at all to the talk - he never talks about npm or anything to do with package managers but instead how node does imports etc. But anyways, [2] is at least a problem in many other package repositories. [1] would probably be a problem for many - given legal pressure (vendor your shit, that's the solution). [3] was a bug, not a design issue - no package management system is immune to bugs. The one thing Java has is that it uses namespaces, which may help with [2] (but barely). [2] certainly has been a problem in PyPI. Certainly all of this could happen to PyPI. We see it happen with js more, I think, because js happens to be extremely popular so there's a ton of packages for it and it's also much younger (especially node) than others.
    - tcheard 8y ago
      > This stuff isn't relevant at all to the talk - he never talks about npm or anything to do with package managers but instead how node does imports etc. He does have it in his slides. Slide titled: "Regret: package.json", last 2 points: > Ultimately I included NPM in the Node distribution, which much made it the defacto standard. > It's unfortunate that there is a centralized (privately controlled even) repository for modules.
jecxjo 8y ago
This issue is not just a lack of learning from past failures, it's an active issue that is systemic to web development, especially node. Everyone wants reinvent the wheel rather than supporting a similar, already existing project. I don't know if it's that everyone wants to be the lead on something or if they all lack group skills, but there is no reason we need dozens of similar, partially functional libraries. I can barely, and I mean sooo very barely get behind the fact that all of these SaaS companies need to create their own versions of frameworks, but it amazes me just how many square wheels there are in the web community. It was one of the major reasons it took me so long to start doing full stack development, just way too many cooks all wanting to make almost the exact same meal, only theirs is more superior.
- Swizec 8y ago
  It’s because the average dev has less than 5 years of experience according to the StackOverlow survey, and web is the fastest growing field inside software engineering. A large majority of people you’re chiding for not learning from others, don’t even realize those other things exist.
  - jecxjo 8y ago
    But it's not even independent green developers, it's everyone. Chai, mocha, jasmine, jest, should, expect, lab...omg do we really need another unit testing library? Sure they are all slightly different but there is no reason they all couldn't be condensed down to one or two libraries. Shall we list all the reactive UI frameworks? Or routing frameworks? Everyone is at fault here.
    - chrisco255 8y ago
      Chai is not a testing framework, it's an assertion library compatible with all the other main testing frameworks you mentioned. Yes, we do need experimentation and innovation in testing frameworks. Jest was a real innovation to the space and is particularly awesome for React testing with it's snapshots feature. This kind of argument never gets made with anything else. "Why can't we all just stick to the Model T. It's perfect."

by dnomad 8y ago

wolco 8y ago

I like the energy around the javascript everywhere movement. So what if they reinvent the wheel, sometimes you find a better wheel and break the rules along the way. There is something exciting about developers using a language in ways it was never designed. Then having the language change to support the changing ecosystem...

ahansen 8y ago
So true, at the end of the day people are working like this because it's the way they feel the most passionate about. You can't really blame them considering how disinterested people can get working on that last 10% of even their own projects.
- kingludite 8y ago
  haha, why do we do this? Should we judge programmers by how finished their thing is? I think it is the most impressive quality when I see it (which is non of my own stuff haha)
ppeetteerr 8y ago
It's when you build a business on a technology and then have to re-invest to rebuild the product, that's when it becomes an issue. Think of all the start ups that built running businesses on Angular 1.
- abiox 8y ago
  as far as i know, angular 1 still works just fine... :) (as it happens 1.7 was released recently.)
  - ppeetteerr 8y ago
    It does but try finding a developer looking to work on Angular 1

minitech 8y ago

> Very simple mistakes like immutable, never changing build releases Can you expand a bit more? Not sure what this means.

dnomad 8y ago
[1] https://en.wikipedia.org/wiki/Npm_(software)#Notable_breakage https://en.wikipedia.org/wiki/Npm_(software)#Notable_breakag..., [2] https://www.csoonline.com/article/3214624/security/malicious-code-in-the-node-js-npm-registry-shakes-open-source-trust-model.html https://www.csoonline.com/article/3214624/security/malicious..., [3] https://news.ycombinator.com/item?id=16087024 https://news.ycombinator.com/item?id=16087024 And the list goes on and on IMO. What's disappointing is that these were lessons learned a long time ago and now they're being re-learned.
- staticassertion 8y ago
  This stuff isn't relevant at all to the talk - he never talks about npm or anything to do with package managers but instead how node does imports etc. But anyways, [2] is at least a problem in many other package repositories. [1] would probably be a problem for many - given legal pressure (vendor your shit, that's the solution). [3] was a bug, not a design issue - no package management system is immune to bugs. The one thing Java has is that it uses namespaces, which may help with [2] (but barely). [2] certainly has been a problem in PyPI. Certainly all of this could happen to PyPI. We see it happen with js more, I think, because js happens to be extremely popular so there's a ton of packages for it and it's also much younger (especially node) than others.
  - tcheard 8y ago
    > This stuff isn't relevant at all to the talk - he never talks about npm or anything to do with package managers but instead how node does imports etc. He does have it in his slides. Slide titled: "Regret: package.json", last 2 points: > Ultimately I included NPM in the Node distribution, which much made it the defacto standard. > It's unfortunate that there is a centralized (privately controlled even) repository for modules.

jecxjo 8y ago

This issue is not just a lack of learning from past failures, it's an active issue that is systemic to web development, especially node. Everyone wants reinvent the wheel rather than supporting a similar, already existing project. I don't know if it's that everyone wants to be the lead on something or if they all lack group skills, but there is no reason we need dozens of similar, partially functional libraries. I can barely, and I mean sooo very barely get behind the fact that all of these SaaS companies need to create their own versions of frameworks, but it amazes me just how many square wheels there are in the web community. It was one of the major reasons it took me so long to start doing full stack development, just way too many cooks all wanting to make almost the exact same meal, only theirs is more superior.

Swizec 8y ago
It’s because the average dev has less than 5 years of experience according to the StackOverlow survey, and web is the fastest growing field inside software engineering. A large majority of people you’re chiding for not learning from others, don’t even realize those other things exist.
- jecxjo 8y ago
  But it's not even independent green developers, it's everyone. Chai, mocha, jasmine, jest, should, expect, lab...omg do we really need another unit testing library? Sure they are all slightly different but there is no reason they all couldn't be condensed down to one or two libraries. Shall we list all the reactive UI frameworks? Or routing frameworks? Everyone is at fault here.
  - chrisco255 8y ago
    Chai is not a testing framework, it's an assertion library compatible with all the other main testing frameworks you mentioned. Yes, we do need experimentation and innovation in testing frameworks. Jest was a real innovation to the space and is particularly awesome for React testing with it's snapshots feature. This kind of argument never gets made with anything else. "Why can't we all just stick to the Model T. It's perfect."