Hacker News Reader

Comment by MustardTiger | Hacker News Reader

I wonder why this mentality only exists with web devs. Everywhere else, someone writing software is considered normal, not some scary problem. Nobody sees any other kind of application written by a previous programmer and cries "oh no! I am entirely at the mercy of this previous programmer! If only they had used one of the dozen competing frameworks this tragedy could have been avoided.". It is just normal. Perhaps the low barrier to entry and corresponding low average experience of web developers plays a part in this mentality.

View on HN

Because 99% of web dev code is the same stuff and 99% of the time it doesn't need to be rewritten. You don't need your own implementation of URL rules, user authentication and roles, testing suites, database driver or ORM, request parsing, csrf protection, session handling....

I can buy a book on Django/Flask/Symfony/Spring/Express. I can't buy a book about your homebrew 30k LOC "non-framework" which does all the same things plus an additional customized CRUD layer.

> Nobody sees any other kind of application written by a previous programmer and cries "oh no! I am entirely at the mercy of this previous programmer! If only they had used one of the dozen competing frameworks this tragedy could have been avoided."

If a large majority of the code you've been given to maintain could instead be handled by well known, well documented project with thousands of eyes fixing bugs and adding features, you would probably say the same thing.

Imagine inheriting a java codebase of a simple POS system with a UI. Except instead of using Swing or AWT or I don't know what else, the entire UI is custom written in OpenGL. And instead of using any of the standard sorting or ArrayList implementation, they write their own, which are similar, but not identical (and often have 0 tests).

This whole argument is based on two false assumptions. One, that shitty broken web frameworks like cakephp and zend are "well known, well documented project with thousands of eyes fixing bugs and adding features" rather than the horrible messes they actually are. And two, that web apps are the only software to share any common aspects. Every lame VB+Access app I ever saw had more in common than two randomly chosen web apps. Yet nobody needed a "framework" to enforce worst practices and ensure that everything was done inefficiently and unmaintainably.

Because the myriad ways public people interact with your code through HTTP and routes starts to rival the complexity of getting crypto code right, with a lot of the same sorts of downsides (which is to say problems often lead to security issues, and very few people are capable of reasoning about all the implications of the decisions made). I would suggest someone not roll their own framework (which is essentially creating a framework of their own at some level) for the same reasons I would suggest someone not roll their own crypto. The upside is relatively minuscule compared to the downsides, IMO.

Yes, they do. If you came upon someone's custom HTTP client, I imagine your response would be something along those lines. If not lamenting that you're at their mercy, at least cursing them for imposing a requirement of some level of strength that you use what is very likely to be a substandard implementation of what you can find freely available. So, you either replace it with something less likely to cause the odd problem later (and deal with all the testing to make sure you didn't introduce a bug, and you probably did) or deal with those odd problems ("what do you mean we aren't conforming to TLS correctly? Why haven't we seen this until now?").

> If you came upon someone's custom HTTP client, I imagine your response would be something along those lines.

No, why would it? What HTTP client framework am I supposed to be wishing they used?

Maybe cURL? Some other one I don't know of (I know the ones in my preferred languages). Do we really need to also be responsible to dealing with already solved problems as well as the problems specific to our domain? Do we really want to also deal with the not-fully-compliant HTTP client or making sure we support HTTP/2, or do we want to use widely accepted solutions for those so we can focus on the real problem at hand (which is usually not the intricacies of HTTP negotiation, or some other well understood and supplied need).

Curl isn't a framework.

>Do we really need to also be responsible to dealing with already solved problems as well as the problems specific to our domain?

No? What does that have to do with anything?

>Do we really want to also deal with the not-fully-compliant HTTP client or making sure we support HTTP/2, or do we want to use widely accepted solutions for those so we can focus on the real problem at hand (which is usually not the intricacies of HTTP negotiation, or some other well understood and supplied need).

Did you reply to the wrong comment by mistake or something? What does any of this have to do with me or what I said?

> Curl isn't a framework.

I wasn't under the impression we should be limiting this to frameworks. What's the difference between a framework and a library for the purpose of this discussion? I think they are functionally equivalent. I was clear to equate it to crypto originally, which doesn't really make sense when viewed as applying to frameworks only. We're a couple comments removed from that, I thought that wasn't in question. Same with an HTTP client. Frameworks don't event necessarily implement clients. I'm addressing NIH syndrome, and I don't think frameworks really deserve special consideration in any way.

> Did you reply to the wrong comment by mistake or something? What does any of this have to do with me or what I said?

See above. And I've been sticking with the same examples since the first comment. Why is this all of a sudden not making sense?

>I wasn't under the impression we should be limiting this to frameworks

The discussion is entirely and solely about frameworks..

>What's the difference between a framework and a library for the purpose of this discussion?

Wikipedia exists.

>See above

Above what? Nothing you said above answers my question.

>And I've been sticking with the same examples since the first comment. Why is this all of a sudden not making sense?

Because it has absolutely nothing to do with anything I said, like I clearly stated.

My point was frameworks are functionally no different than a large complex library, and as such, the same arguments apply.

That said, I'm not entirely happy with the way the tone of this conversation is heading, so I'll excuse myself now.

>My point was frameworks are functionally no different than a large complex library

You'll have to forgive me for not guessing that given that nothing in your post came anywhere close to even suggesting anything of the sort. I am limited to reading what you write, and can not read your mind.

Yes, frameworks are different from libraries. Boy, that was productive.

"I wonder why this mentality only exists with web devs [...] Nobody sees any other kind of application [...]"

Your premise - on which you based a slightly convoluted ad hominem, implying lack of professional experience on my part - is false to start with. While I did have some PHP experience, I'm not really a web dev. I'm a mobile (Android) and desktop (Windows) developer. Having said that, with web applications you typically have more moving parts and layers to integrate than in case of a client app.

I think you're right that the propensity of non-technical organizations to try and hire unqualified people at below market rates leads to a particular problem in web development.

But I think people programming other types of software have structure that comes from elsewhere. For example, if you write plain Android or iOS apps, in may ways there's a kind of standard app architecture that's just used and taken for granted. Sure, it can be muddled, but only so much for the most part. And the same is largely true for desktop applications, too, when they're built with IDEs that impose structure or even things like Unity.

The thing that's extra weird about this is that most web apps have to reinvent the wheel in ways that desktop software doesn't.

I think some of it has to do with the languages involved. I find the type systems of C/C++/Java to be helpful in figuring out what a piece of code does, as compared to the type systems of Python/PHP/Ruby where it's more difficult to tell what a variable contains. Frameworks help solve this problem because you can infer what type of data you've got by looking at what method it's coming from and where it's being used.

Not sure why you think it doesn't happen in other fields. Every time I spoke with a software developer, they were constantly cursing the architecture of the code they had to dealt with.

Reply on news.ycombinator.com