5 ms·

> Frameworks and plug-ins exist to allow this to be all plug and play Too many are buggy and/or poorly documented and take lots of trial and error to get worki

by tabtab 4y ago

> Frameworks and plug-ins exist to allow this to be all plug and play Too many are buggy and/or poorly documented and take lots of trial and error to get working as intended. And you create a dependency mess by including lots of pluggins/libraries. It may be quick up front, but can jack maintenance after say 5-ish years. Multi-K-lines-of-code libraries "rot" as environments change. If you can write a shop-tuned version in say 300 lines, do it, because it's easier to fix later. Select vendor libraries/pluggins judiciously.

dchuk 4y ago
Right, so pick old boring frameworks. Rails, Django, Phoenix, etc.
ian0 4y ago
This is true and in experience happens far quicker than 5 years for JS frameworks. Most of the frameworks I learned 5-10 years ago are already effectively dead too. But I think OPs main point stands, your far more likely to die by not shipping things early than by having to refactor occasionally. After 5 years 50% of businesses have failed [0] and this is far far higher for startups & side projects. [0] https://www.bls.gov/bdm/entrepreneurship/entrepreneurship.htm https://www.bls.gov/bdm/entrepreneurship/entrepreneurship.ht...
- tabtab 4y ago
  > your far more likely to die by not shipping things early than by having to refactor occasionally. Know your org. A startup has very different priorities than a bank, for example. Small projects need different conventions than big projects, internal need diff than external, 200 user apps need diff than "web scale", etc. I'm more careful now to state the assumed environment because one size doesn't fit all. And fit your org, not your resume. Buzzword oriented programming is selfish; I've seen it make screwball messes.
- zdragnar 4y ago
  The major JS frameworks have all been around for 5 years; several for 10 (react turns 10 this May). Compare that to the average tech employee tenure, or even the average lifetime of a startup company.
  - dmitriid 4y ago
    I just pulled in a class-based component into a modern React project. It just worked with no adjustment. Now that's commitment to backward compatibility (and they can't have it any other way, they won't rewrite half of facebook just because their own framework changed).
waboremo 4y ago
> shop-tuned version in say 300 lines But if that was the case, you would do that, resorting to other tools for something that tiny is silly and only really done by beginners. Something that tiny would also unlikely have bug or documentation issues. There are some great tools that are poorly documented/buggy, yes, but they are quite rare and it's much easier to use them and fork the repo (if inactive) than to build from scratch. This idea that you avoid creating a dependency mess by writing more of your own work, isn't the entire truth. The dependency is just internal, and far more likely to have poor documentation than open source plugin #4159. So you really haven't solved or avoided the problem at all.
- ramones13 4y ago
  You would think that, but this seven line NPM package has 68M downloads a week - https://www.npmjs.com/package/isarray https://www.npmjs.com/package/isarray
  - waboremo 4y ago
    NPM statistics are easily gamed https://dev.to/andyrichardsonn/how-i-exploited-npm-downloads-and-why-you-shouldn-t-trust-them-4bme https://dev.to/andyrichardsonn/how-i-exploited-npm-downloads... I don't doubt there are a lot of insignificant packages being used, again especially by beginners, I just don't buy it's to that scale
    - ramones13 4y ago
      It's pretty easy to find that the example I gave isn't gamed... A cursory search on GitHub can find a couple examples like dotenv [1] and npm's cli [2] both use it via an older version of nodejs/readable-stream [3]. There's also the classic left-pad debacle - https://github.com/left-pad/left-pad/issues/4 https://github.com/left-pad/left-pad/issues/4 [1] - https://github.com/motdotla/dotenv/blob/master/package-lock.json https://github.com/motdotla/dotenv/blob/master/package-lock.... [2] - https://github.com/npm/cli/blob/latest/package-lock.json https://github.com/npm/cli/blob/latest/package-lock.json [3] - https://github.com/nodejs/readable-stream/ https://github.com/nodejs/readable-stream/
ramones13 4y ago
IMO, aggressive npm install is the superset of the framework problem. We code review every line written by other developers at our company with a fine toothed comb, but will add a dependency from a massive advertising company or some dude in Russia without a second thought. It’s wild.

by tabtab 4y ago

dchuk 4y ago

Right, so pick old boring frameworks. Rails, Django, Phoenix, etc.

ian0 4y ago

This is true and in experience happens far quicker than 5 years for JS frameworks. Most of the frameworks I learned 5-10 years ago are already effectively dead too. But I think OPs main point stands, your far more likely to die by not shipping things early than by having to refactor occasionally. After 5 years 50% of businesses have failed [0] and this is far far higher for startups & side projects. [0] https://www.bls.gov/bdm/entrepreneurship/entrepreneurship.htm https://www.bls.gov/bdm/entrepreneurship/entrepreneurship.ht...

tabtab 4y ago
> your far more likely to die by not shipping things early than by having to refactor occasionally. Know your org. A startup has very different priorities than a bank, for example. Small projects need different conventions than big projects, internal need diff than external, 200 user apps need diff than "web scale", etc. I'm more careful now to state the assumed environment because one size doesn't fit all. And fit your org, not your resume. Buzzword oriented programming is selfish; I've seen it make screwball messes.
zdragnar 4y ago
The major JS frameworks have all been around for 5 years; several for 10 (react turns 10 this May). Compare that to the average tech employee tenure, or even the average lifetime of a startup company.
- dmitriid 4y ago
  I just pulled in a class-based component into a modern React project. It just worked with no adjustment. Now that's commitment to backward compatibility (and they can't have it any other way, they won't rewrite half of facebook just because their own framework changed).

waboremo 4y ago

> shop-tuned version in say 300 lines But if that was the case, you would do that, resorting to other tools for something that tiny is silly and only really done by beginners. Something that tiny would also unlikely have bug or documentation issues. There are some great tools that are poorly documented/buggy, yes, but they are quite rare and it's much easier to use them and fork the repo (if inactive) than to build from scratch. This idea that you avoid creating a dependency mess by writing more of your own work, isn't the entire truth. The dependency is just internal, and far more likely to have poor documentation than open source plugin #4159. So you really haven't solved or avoided the problem at all.

ramones13 4y ago
You would think that, but this seven line NPM package has 68M downloads a week - https://www.npmjs.com/package/isarray https://www.npmjs.com/package/isarray
- waboremo 4y ago
  NPM statistics are easily gamed https://dev.to/andyrichardsonn/how-i-exploited-npm-downloads-and-why-you-shouldn-t-trust-them-4bme https://dev.to/andyrichardsonn/how-i-exploited-npm-downloads... I don't doubt there are a lot of insignificant packages being used, again especially by beginners, I just don't buy it's to that scale
  - ramones13 4y ago
    It's pretty easy to find that the example I gave isn't gamed... A cursory search on GitHub can find a couple examples like dotenv [1] and npm's cli [2] both use it via an older version of nodejs/readable-stream [3]. There's also the classic left-pad debacle - https://github.com/left-pad/left-pad/issues/4 https://github.com/left-pad/left-pad/issues/4 [1] - https://github.com/motdotla/dotenv/blob/master/package-lock.json https://github.com/motdotla/dotenv/blob/master/package-lock.... [2] - https://github.com/npm/cli/blob/latest/package-lock.json https://github.com/npm/cli/blob/latest/package-lock.json [3] - https://github.com/nodejs/readable-stream/ https://github.com/nodejs/readable-stream/

ramones13 4y ago

IMO, aggressive npm install is the superset of the framework problem. We code review every line written by other developers at our company with a fine toothed comb, but will add a dependency from a massive advertising company or some dude in Russia without a second thought. It’s wild.