Comment by V-2 | Hacker News Reader

Comment by V-2 | Hacker News Reader

Why learn frameworks when you can build everything from scratch and become a true carpenter ("building software using general purpose frameworks doesn’t make you a coder or a programmer any more than putting together a pre-built house makes you a carpenter").

"These people [framework creators] seems to be infatuated by the though of having other people follow their “way of doing things”, becoming some kind of PHP community leaders, and having other people use their latest “hip” Open Source tools..."

How lame of these people.

The problem is, if I inherit an application created with a well-known framework, I'll have a much easier time figuring out what is what, and looking for answers when something goes awry.

On the other hand, if the codebase has been written from scratch by Greg, a real carpenter of a programmer, who is no longer with the company, then good luck. I'm at his mercy entirely.

I'll be having his "way of doing things" for dinner whether I want it or not, the only difference is that I won't have a community of other people in the same situation.

This aspect isn't addressed by the author at all, although he found just enough time to provide us with a psychological analysis of framework authors and their narcissist motivations :)

> The problem is, if I inherit an application created with a well-known framework, I'll have a much easier time figuring out what is what, and looking for answers when something goes awry.

Unless they spend most of their code fighting the framework to accomplish their actual task. Which happens rather often.

Not to mention that learning a new framework is not fundamentally different from learning some person's approach to doing things. Whether or not it's easy depends on the quality of code and documentation. Given equal size of the code that does the job, reasonably written framework-free code is probably going to be easier to understand, because it doesn't have external dependencies.

I never understood why after years of dealing with dozens of competing and rather poorly constructed web frameworks in Java, PHP and now JavaScript people still believe that those things have some kind of inherent value. Remember Struts, anyone? PHP Nuke? WebForms? Would you rather maintain something that used either of those over something that was written in vanilla Java/PHP/C#?

> Not to mention that learning a new framework is not fundamentally different from learning some person's approach to doing things.

I don't think this is true.

If you're learning a framework, you have the entire community - which has probably written blog posts, asked and answered StackOverflow questions, and likely has some members who can answer your question at odd hours.

If you're learning one person's approach, you have exactly one person you can ask about it: Greg. Who might quit, or go on paternity leave, or get hit by a bus. If you're lucky, you might also have some coworkers who understand parts of that system.

>If you're learning a framework, you have the entire community - which has probably written blog posts, asked and answered StackOverflow questions, and likely has some members who can answer your question at odd hours.

You're assuming that learning the framework will make understanding actual workload code completely effortless. In non-trivial applications this is never the case. You still have to understand... stuff like this, for example:

http://mikehadlow.blogspot.com/2010/04/custom-aspnet-mvc-mod...

When someone writes code from scratch the quality of the code depends on their ability. When someone uses a framework the quality of the code depends on their ability, the quality of the framework and fitness of the framework for a particular problem.

If the developer is not very experienced but sufficiently disciplined, and the framework is well-designed and fits the chosen task well, than yes, you end up with better code. If any of those conditions fail, the code is usually just as bad or worse than vanilla.

> Unless they spend most of their code fighting the framework to accomplish their actual task. Which happens rather often.

You can't make things foolproof. Fools are very clever.

>Fools are very clever.

this is like gospel.

> Unless they spend most of their code fighting the framework to accomplish their actual task. Which happens rather often

I think this is just confirmation bias - you won't notice all the times you are not fighting the framework, but you do when you are.

> Not to mention that learning a new framework is not fundamentally different from learning some person's approach to doing things

Only if "some person" is real fastidious with documentation, StackOverflow answers and tutorials. You aonly have to learn Laravel[1], but catching up with Greg/Peter/Jane/Paula's framework at every new job will get old fast.

> Remember Struts, anyone? PHP Nuke? Would you rather maintain something that used either of those over something that was written in vanilla Java/PHP?

Those projects were fantastic for their time. Let me put it this way - I would rather maintain something that used those projects and not some custom solution written by a nameless developer in the same era. At least PHP Nuke had (I'm hoping) a clear migration path to PHP v4 and v5 and you won't have to do it manually.

1. Or any other framework

> Let me put it this way - I would rather maintain something that used those projects and not some custom solution written by a nameless developer in the same era

I wrote a very large PHP application around that era.

You are absolutely correct. Even I have a hard time maintaining that code.

More often than not, when I have inherited a project built on a common PHP framework the documentation and community knowledge available is limited because the framework used is, most commonly, not the latest version. So you are basically wading through the tall grass of online resources trying to ascertain what knowledge applies to what version, which for some frameworks can differ tremendously between major releases.

Many developers love a particular framework and they use it as often as possible and it works well for them, one reason being that over time they become familiar and accustomed to it's strengths, patterns, flaws and idiosyncrasies. But I personally find no pleasure in having to familiarize myself with a crusty old framework that I will never touch again in my career versus well-organized vanilla PHP.

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.

"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 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.

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.

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.

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.

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.

> 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.".

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.

> On the other hand, if the codebase has been written from scratch by Greg, a real carpenter of a programmer, who is no longer with the company, then good luck. I'm at his mercy entirely.

You're at his mercy if he used a framework, too. There's nothing to require that he used it in a sensible way. The only difference is that now you get to discover the innermost details of the framework, too, at the same time you're trying to figure out what Greg was doing, and you also get to figure out which is which.

The underlying issue is that PHP is bad at frameworks and because of that there are dozens of them. If there was one, clear, dominant framework it would be one thing...but there's not so investing in using any particular PHP framework is just about as risky of a proposition as rolling your own.

This is likely more an artifact of the PHP community and philosophy being focused on ease of use and deployment, circa early 2000's.

Consider that Ruby has a few dominant frameworks--like Rails--built on a language with read-hostile features like monkey patching. Unlike Python Ruby often has many ways of doing things, and that's reflected in community gems. (EDIT: swipe-typing fail.)

Regardless, there has been some coalescing around more modern PHP frameworks like Laravel recently.

That's true. One of the things that I find particularly interesting is the response to this with PHP vs that of Go. As I've picked up Go, the distinct impression that I've gotten is one of total anti-framework with the idea of just pulling in the parts you needs for what you're doing. Even a general disdain for using anything that isn't in the stdlib.

That seems exactly what what is being advocated for here but with PHP and Composer instead yet the response is reversed.

A stupid idea is stupid regardless of language. Whether the community sees that or not also reflects on the community.

Reply on news.ycombinator.com