7 ms·

I always get a lot of pushback for avoiding frameworks and libraries, and rolling most things by hand. But, most frameworks and libraries aren't built to be au

by Taek 2y ago

I always get a lot of pushback for avoiding frameworks and libraries, and rolling most things by hand. But, most frameworks and libraries aren't built to be audit-grade robust, don't have enterprise level compatibility promises, can't guarantee that there won't be suprise performance impacts for arbitrary use cases, etc. Sometimes, a third party library (like sql-lite) makes the cut. But frameworks and libraries that reach the bar of "this will give me fewer complications than avoiding the dependency" are few and far between.

jppope 2y ago
I completely agree - though there are places where I trust an implementation of things like a well known algorithm. However, to add onto this, I'm consistently shocked at how often it is much CHEAPER to "roll your own." We've done some reviews on systems after a few years and the number of bugs and security vulnerabilities we experience with code based around packages is much MUCH higher. Its hard to put a number to it because the time cost of fixing those issues is variable, but its substantial. Its also amazing to me that it can be cheaper to build your own vs using a 3rd party vendor for something that would appear to be highly specialized - of course opportunity cost is a real thing.
- noduerme 2y ago
  Rolling your own, though, does come down to hammering in the extra nails... and hoping that whoever's doing the job knows where to put those supports in place. If you have someone who looks into the future and sees what issues might come up in a few years, then it's way cheaper than relying on frameworks. If you don't, then you're stuck with some janky software that no one else can fix. I think this is why the larger the scale, the more likely companies are to rely on frameworks which themselves are janky, but at least well understood.
- whstl 2y ago
  The low quality of modern libraries is something that REALLY shocks me. The library space has become competitive, and people are running them as business. The goal is not to be correct or even good, but to be a "first mover" and selling tutorials, books, Github sponsorships, Patreon subscriptions... It's bad not only in terms of security, but also in terms of developer experience. I am constantly amazed at how little documentation things have, at how many BASIC cases they don't cover (let alone edge cases) and how many security holes those libraries have, and the number of dependencies just keeps getting bigger and bigger. Another issue is that newer developers are being taught just the newfangled library and have zero experience with the foundations. The number of React devs who don't know how to use HTML forms without a library is nuts.
  - GiorgioG 2y ago
    > The low quality of modern libraries is something that REALLY shocks me. How could you be shocked? Everything that's happened in the software industry outside of medical/DoD has been about delivering features as fast as you can, quality be damned.
    - whstl 2y ago
      I am shocked because this was not always the reality. I have qualified my statement with "modern".
- tcfhgj 2y ago
  How many could potentially discover security vulnerabilities in your code vs popular lib?
noduerme 2y ago
This is a hard take, just because we all build on stacks. When we trust that Math.Abs() is going to work in some language, or that some socket library is going to do what it says on the tin, we're standing on the shoulders of giants. I also avoid frameworks as much as possible, but by frameworks I mean anything I'd rather roll myself in a scripting language, particularly when learning and keeping up with the framework seems like more of a hassle. But for the layers and layers of underlying software and hardware behind me writing REST calls and async functions? Also, there are higher level libraries that are sometimes good, because why reinvent the wheel every time you make something? Pixijs is one I use a lot. Also, Chart.js. Jquery. Moment.js. Good ol' Bootstrap 4 alpha's CSS handles a ton of use cases, and I never need to think about it again. There's very little in those that I haven't at one time or another rolled myself, but having a toolkit that you know and doesn't change much saves you a lot of time. The danger is more getting into libraries that aren't already dead, and are still in active development ;)
- chrisweekly 2y ago
  Moment.js is one of those libraries to avoid; the bloat....
  - aabaker99 2y ago
    I still like Moment because it offers better control of time zones that aren’t the browsers time zone when compared to the builtin Date APIs. Do you have a recommendation to replace Moment for that use case? I’m hopeful for the future with JavaScript Temporal.
    - microflash 2y ago
      dayjs is a similar library that I’ve used to replace Moment with minimal effort.
    - g8oz 2y ago
      A maintainer of moment.js has moved on with an immutable rewrite called luxon.js. Highly recommended. https://github.com/moment/luxon/blob/master/docs/why.md https://github.com/moment/luxon/blob/master/docs/why.md
infinghxsg 2y ago
[dead]
pc86 2y ago
This is smart if you work for a company that actually needs this level of robustness. The problem is that most don't, and a lot of people who work for these companies wish they were working someone "better"/"more important," so they pretend they actually do need this level of performance. The guy like you on a mission critical team at a cutting edge company is a godsend and will be a big part of why the project/company succeeds. The guy who wants to build his own ORM for his no-name company's CRUD app is wasting everyone's time.
- deleted 2y ago
  [deleted]
- ryandrake 2y ago
  I think many engineers would highly benefit from doing a 1-2 year stint working on safety-critical embedded software, where there are correctness requirements, and lives are lost if you're wrong or careless. It may not be everyone's bowl of soup, but it would at least expose you to that side of the world and you might learn something from the experience. Perhaps if everyone did this kind of tour of duty, something would rub off, and there would not be so much casual yolo carelessness in the "normal" software world.
  - tacitusarc 2y ago
    On the other hand, do I want careless devs working in those industries?
    - ryandrake 2y ago
      I don't think "careless" is a permanent, intrinsic attribute of a developer. It's something they learn to be, and it can be unlearned. We respond to incentives. If a developer's only incentive is "we reward shipping as fast as possible" then they will carelessly ship slop as fast as they can type it. If that incentive is removed, they can learn a better way...
    - rcxdude 2y ago
      From my experience in the industry, if the average backend dev went to work in that industry, the average level of competence would go up (compare the average salary, for one thing). The processes are all about making it hard to fuck up really badly, they're very much not going to weed out 'careless' devs, just limit the damage they can do.
jon-wood 2y ago
This is very contextual. If I'm building a web application for an early stage startup which is basically a bunch of pretty CRUD views I'm absolutely using a framework for it, there's no point in hand rolling everything when the problem being solved is exactly what a framework is designed to do. If it's something safety critical, or where getting software updates out to it is going to be a problem, I'm probably going to end up hand rolling a lot more and depending on frameworks less, because I need to understand what the failure modes are and how it's going to deal with them.
tshaddox 2y ago
What programming languages are you using? Compilers and interpreters are pretty darn complicated, not to mention operating systems and computer hardware.
flessner 2y ago
I think you're correct, but certain libraries are so widespread enough that it's sensible. Especially S3, SQLite (as mentioned), Postgres and Redis usually offer good abstractions. Other than that, time and crypto are two things I also wouldn't code myself, both are just too easy to mess up.
roguecoder 2y ago
Frameworks are just someone else's architecture. They are helpful if you have the same problems as that other company, but I worry about software that uses frameworks because the programmers don't feel confident building their own. It means when it comes time to evolve beyond the off-the-shelf architecture, programmers keep plowing ahead far past when they should have added another level of abstraction & encapsulation. On the other hand, I also see applications where people dogmatically avoid using pre-existing architectures but also don't take the time to build their own. You end up with references to one table scattered all across the code base in hand-composed SQL. I'd much rather take an outgrown-framework over a spaghetti mess.

by Taek 2y ago

jppope 2y ago

I completely agree - though there are places where I trust an implementation of things like a well known algorithm. However, to add onto this, I'm consistently shocked at how often it is much CHEAPER to "roll your own." We've done some reviews on systems after a few years and the number of bugs and security vulnerabilities we experience with code based around packages is much MUCH higher. Its hard to put a number to it because the time cost of fixing those issues is variable, but its substantial. Its also amazing to me that it can be cheaper to build your own vs using a 3rd party vendor for something that would appear to be highly specialized - of course opportunity cost is a real thing.

noduerme 2y ago
Rolling your own, though, does come down to hammering in the extra nails... and hoping that whoever's doing the job knows where to put those supports in place. If you have someone who looks into the future and sees what issues might come up in a few years, then it's way cheaper than relying on frameworks. If you don't, then you're stuck with some janky software that no one else can fix. I think this is why the larger the scale, the more likely companies are to rely on frameworks which themselves are janky, but at least well understood.
whstl 2y ago
The low quality of modern libraries is something that REALLY shocks me. The library space has become competitive, and people are running them as business. The goal is not to be correct or even good, but to be a "first mover" and selling tutorials, books, Github sponsorships, Patreon subscriptions... It's bad not only in terms of security, but also in terms of developer experience. I am constantly amazed at how little documentation things have, at how many BASIC cases they don't cover (let alone edge cases) and how many security holes those libraries have, and the number of dependencies just keeps getting bigger and bigger. Another issue is that newer developers are being taught just the newfangled library and have zero experience with the foundations. The number of React devs who don't know how to use HTML forms without a library is nuts.
- GiorgioG 2y ago
  > The low quality of modern libraries is something that REALLY shocks me. How could you be shocked? Everything that's happened in the software industry outside of medical/DoD has been about delivering features as fast as you can, quality be damned.
  - whstl 2y ago
    I am shocked because this was not always the reality. I have qualified my statement with "modern".
tcfhgj 2y ago
How many could potentially discover security vulnerabilities in your code vs popular lib?

noduerme 2y ago

This is a hard take, just because we all build on stacks. When we trust that Math.Abs() is going to work in some language, or that some socket library is going to do what it says on the tin, we're standing on the shoulders of giants. I also avoid frameworks as much as possible, but by frameworks I mean anything I'd rather roll myself in a scripting language, particularly when learning and keeping up with the framework seems like more of a hassle. But for the layers and layers of underlying software and hardware behind me writing REST calls and async functions? Also, there are higher level libraries that are sometimes good, because why reinvent the wheel every time you make something? Pixijs is one I use a lot. Also, Chart.js. Jquery. Moment.js. Good ol' Bootstrap 4 alpha's CSS handles a ton of use cases, and I never need to think about it again. There's very little in those that I haven't at one time or another rolled myself, but having a toolkit that you know and doesn't change much saves you a lot of time. The danger is more getting into libraries that aren't already dead, and are still in active development ;)

chrisweekly 2y ago
Moment.js is one of those libraries to avoid; the bloat....
- aabaker99 2y ago
  I still like Moment because it offers better control of time zones that aren’t the browsers time zone when compared to the builtin Date APIs. Do you have a recommendation to replace Moment for that use case? I’m hopeful for the future with JavaScript Temporal.
  - microflash 2y ago
    dayjs is a similar library that I’ve used to replace Moment with minimal effort.
  - g8oz 2y ago
    A maintainer of moment.js has moved on with an immutable rewrite called luxon.js. Highly recommended. https://github.com/moment/luxon/blob/master/docs/why.md https://github.com/moment/luxon/blob/master/docs/why.md

infinghxsg 2y ago

[dead]

pc86 2y ago

This is smart if you work for a company that actually needs this level of robustness. The problem is that most don't, and a lot of people who work for these companies wish they were working someone "better"/"more important," so they pretend they actually do need this level of performance. The guy like you on a mission critical team at a cutting edge company is a godsend and will be a big part of why the project/company succeeds. The guy who wants to build his own ORM for his no-name company's CRUD app is wasting everyone's time.

deleted 2y ago
[deleted]
ryandrake 2y ago
I think many engineers would highly benefit from doing a 1-2 year stint working on safety-critical embedded software, where there are correctness requirements, and lives are lost if you're wrong or careless. It may not be everyone's bowl of soup, but it would at least expose you to that side of the world and you might learn something from the experience. Perhaps if everyone did this kind of tour of duty, something would rub off, and there would not be so much casual yolo carelessness in the "normal" software world.
- tacitusarc 2y ago
  On the other hand, do I want careless devs working in those industries?
  - ryandrake 2y ago
    I don't think "careless" is a permanent, intrinsic attribute of a developer. It's something they learn to be, and it can be unlearned. We respond to incentives. If a developer's only incentive is "we reward shipping as fast as possible" then they will carelessly ship slop as fast as they can type it. If that incentive is removed, they can learn a better way...
  - rcxdude 2y ago
    From my experience in the industry, if the average backend dev went to work in that industry, the average level of competence would go up (compare the average salary, for one thing). The processes are all about making it hard to fuck up really badly, they're very much not going to weed out 'careless' devs, just limit the damage they can do.

jon-wood 2y ago

This is very contextual. If I'm building a web application for an early stage startup which is basically a bunch of pretty CRUD views I'm absolutely using a framework for it, there's no point in hand rolling everything when the problem being solved is exactly what a framework is designed to do. If it's something safety critical, or where getting software updates out to it is going to be a problem, I'm probably going to end up hand rolling a lot more and depending on frameworks less, because I need to understand what the failure modes are and how it's going to deal with them.

tshaddox 2y ago

What programming languages are you using? Compilers and interpreters are pretty darn complicated, not to mention operating systems and computer hardware.

flessner 2y ago

I think you're correct, but certain libraries are so widespread enough that it's sensible. Especially S3, SQLite (as mentioned), Postgres and Redis usually offer good abstractions. Other than that, time and crypto are two things I also wouldn't code myself, both are just too easy to mess up.

roguecoder 2y ago

Frameworks are just someone else's architecture. They are helpful if you have the same problems as that other company, but I worry about software that uses frameworks because the programmers don't feel confident building their own. It means when it comes time to evolve beyond the off-the-shelf architecture, programmers keep plowing ahead far past when they should have added another level of abstraction & encapsulation. On the other hand, I also see applications where people dogmatically avoid using pre-existing architectures but also don't take the time to build their own. You end up with references to one table scattered all across the code base in hand-composed SQL. I'd much rather take an outgrown-framework over a spaghetti mess.