Comment by scarface74 | Hacker News Reader

Comment by scarface74 | Hacker News Reader

Parent Full thread

> After 25 years of experience writing software I can honestly say I have encountered many people that agree with this, and perhaps all of them (every single one) have not actually experienced writing an application without a framework. This sentiment sounds correct in theory, but it isn't based on any experience from any one of the people making such a claim

I also have 25 years of experience and started my career writing C and FORTRAN on mainframes without any real library let alone a framework and then wrote my own libraries in C for my next job where I had to write cross platform code that ran on x86 based PCs and mainframes.

My next job, involved maintaining a proprietary compiler/IDE/VM for ruggedized Windows CE devices. So I think I have experience working without frameworks. Not to mention by the time I graduated from college in 1996 , I was a hobbyist assembly language programmer on 4 processors for 10 years (65C02, 68030, PPC 601, x86)

I can say that it’s the fifth level of hell coming behind an “architect’s” half assed framework who thought their problem was so special that they didn’t want to use a mainstream framework to handle non business specific concerns.

There have been a few times that I have ripped out my own code in favor of a popular library when I discovered it.

This isn't about NIH syndrome. This is about other people's code which is composable and can be mixed and matched with other code from other sources, compared to other people's code which dictates to you how your code is written, how it runs, and what contexts you can use it with. Libraries vs. frameworks.

> There have been a few times that I have ripped out my own code in favor of a popular library when I discovered it.

I'm much more likely to rip out the one function I need out of a framework or library and put it in my code, with a comment "// stolen from <source>". I've spent lots of time untangling the crux of someone's implementation away from the problematic abstractions they built up around it to make it universally adaptable.

And of course you regularly check back for bugs and security issues, right?

Usually the security issues come from the wrapper code that tries to hammer the square peg of an algorithm into the round hole of the abstraction they provide. Dropping the wrapper code is the safest thing you can do.

I used to be a web app security tester. I loved it when I got an app that didn't use a framework for development because I knew I'd get some security issues for sure.

In the context of web applications, frameworks mean that your devs don't have to be experts in SQL Injection, XSS, SSRF, Session management etc etc etc.

My experience over several hundred tests was that without a framework there weren't many apps that could get that right first time. If they were lucky the pentesters found the issues, if they were unlucky, it was attackers.

A library could work here too, to turn off the footguns and provide safe tooling. No need for the library to also intercept all of the DOM callbacks for you as well.

Reply on news.ycombinator.com