Hacker News Reader

Comment by onion2k | Hacker News Reader

Frameworks do what the name implies - they provide a consistent base around which to build the rest of your code. That consistency is very useful in a large team. You really don't want people rolling their own solutions to problems, and then finding those solutions don't work together. A framework is an aid to maintaining a consistent interface between disparate parts of the code base. That "limit to creativity" is actually a good thing.

Besides, any large project written without a framework will end up implementing its own "framework-like" interfaces and abstractions anyway. At which point you're essentially using a framework but without any of the advantages of using a well tested and well documented solution that new team members could already have experience of.

View on HN

It also reduces the learning curve when a new employee joins the team. If it is a widely used framework, they may have used it previously. If not, there will be ample information and resources to learn it.

As you've said, every large project that I've worked on, Google, Morgan Stanley, UBS, etc has used some framework or framework-like interface and abstractions. Large teams cannot function without some time of norm/standardization.

When I was at Google, there was a widely used application framework. It enabled getting services up and running quickly and allowed quick integration into other services at Google. New team members can join and quickly be productive. Some teams decided to roll their own stack and many of them turned into a hairy ball of mess.

> When I was at Google, there was a widely used application framework

It was still organization-specific, probably embedded with a lot of the organizational know-how, and tailored for Google's use cases. Which is maybe not the case with the public generic "kitchen sink" frameworks out there.

Which is maybe not the case with the public generic "kitchen sink" frameworks out there.

In the case of Google's tailored, use case specific code, they release their frameworks publicly. Angular, Polymer, Guice, etc are all what you describe, and all freely available to businesses outside of Google.

If your argument is that developers should look beyond the obvious "kitchen sink" frameworks and choose tools that match their requirements criteria as well as possible without adding in unnecessary features then I agree with you completely, but that argument is significantly different to "don't use a framework".

Angular, Polymer, Guice, etc

I don't necessarily disagree, but the fact they release so many different (and incompatible) frameworks should tell us something...!

It tells us is that Google is huge and does lots of different things, and that there isn't such a thing as "one framework to rule them all". That doesn't mean frameworks are a bad idea.

Yep, that's pretty much what I was going for. With maybe a slightly more negative spin -- they seem to experience NIH syndrome even with respect to internal tools, to the extent of developing multiple frameworks that do basically the same thing.

> As you've said, every large project that I've worked on, Google, Morgan Stanley, UBS, etc has used some framework or framework-like interface and abstractions. Large teams cannot function without some time of norm/standardization.

There's an important difference between a library and a framework. Code reuse is great, norms are great, but they need to be composable, and they need to follow the normal rules of the language.

E.g. Spray is my favourite way of doing REST APIs and saves a huge amount of time, but it's a library rather than a framework. I write my own main() (which admittedly may well just be a one-liner that calls into Spray), and it doesn't dictate what other pieces I use - I can do dependency injection my own way or not at all, I can do my own ORM or none, I can use my own unit testing framework or none. I can refactor my Spray code in the ordinary ways of refactoring in Scala because it is just ordinary Scala, and if I want to understand what the library is doing I can click through to the definitions of the library methods which are again just ordinary Scala. For a large project we might all agree on a particular stack - Spray/Hibernate/Guice/JUnit, say - and we might even write some helpers for e.g. constructing a Guice context with Hibernate configured and pulling out the Spray service from it as a one-liner. But I'd still want those pieces to be libraries rather than frameworks as far as possible - I'd want inlining and changing that helper to be a supported use case, partly because it just forces good design (loose coupling, lack of globals etc.) and partly because making it possible for small subteams to experimentally swap out one small component for their piece is the only way one can ever improve on the stack.

The author's point is that a framework does not do anything that a library could not do better. A library respects the principles of abstraction that the programming language provides, which is not true of a framework. Both can be consistent, well documented, well understood, etc., but one is definitely better when it comes to leveraging programming language abstractions. Ultimately, this means libraries are easier to learn than frameworks.

The flip side is that sooner or later the team ends up re-inventing all the things they felt they didn't need from a framework. The instant they start developing and enforcing conventions around architecture design, coding style, etc. (all of which are things they'll have to do as the team and codebase scale up in size) they're right back into all the things people point to as reasons to avoid frameworks.

At that point, they have a framework that fits their use case and don't have to deal with a bunch of the negatives such as the framework getting abandoned, obfuscation, and the framework fighting their use case... Not that your point isn't good... I'm just saying its a grey issue.

> and don't have to deal with a bunch of the negatives such as the framework getting abandoned, obfuscation, and the framework fighting their use case

That's what you think. What actually happens in many cases is that the developers get too busy with other work that is important to the business (e.g. working on the business value directly). At that point the internally-written framework has known bugs and issues, or maybe lack of documentation, but nobody has time budget to seriously solve them and so they keep using the internally-written framework with all its quirks. Once in a while a person who worked on the framework leaves, taking knowledge with him. The remaining people sometimes think "uh... this part so strange, why was it like this again?" but the guy who wrote it already left. And then once in a while someone new joins, thinks "this framework is shit" and ends up reinventing his own internal framework, with its own quirks, while not completely understanding the problems that the original framework was meant to solve. After a while the internal framework gets abandoned in favor of a standardized framework.

I've seen this happening too many times during my days as a consultant. An internal framework is fine if your business case changes slowly, and your team changes slowly, and the framework has been very well-maintained. Miss any of those things and the framework eventually becomes a liability.

So if you're a one-man company and you intend on staying that way, and your business case doesn't evolve quickly, fine. In all other cases though...

Hmmm, I'm not sure we're talking about the same thing. Are you talking about someone doing something like writing their own ad-hoc ORM?

I would agree that it's almost always best to use a library where possible, preferably one that's widely used and very mature.

> which is not true of a framework

What framework are you talking about ? Symfony or Silex do exactly that : "respects the principles of abstraction that the programming language provides". Spring does that too. Any framework powered by dependency injection does that. Only frameworks that try to be to smart for their own good like Rails violate basic separation of concerns. Furthermore, just have a look at most Go or Node web apps out there : globals everywhere, tightly coupled code, no separation of concerns, no dependency injection,direct db calls in controllers... All because "you don't need a framework with Go" or "Dependency injection makes no sense in Javascript", good to luck to the people maintaining these messes 5 years down the road. Not using a framework doesn't make a automatically a codebase better. A framework however can mandate some discipline,especially when based on IoC : on one side : the framework's code , on the other side : the user code and the only glue is the manifest declaring dependencies between the two.

You're right that IoC/Dependency injection pretty much define a framework -- that and ascii folder diagrams. IoC and other patterns are pretty common and well regarded, but they are not features of the language. If you had a library using functional programming instead of an IoC framework you'd be closer to the "principles of abstraction that the programming language provides."

> globals everywhere, tightly coupled code, no separation of concerns

Speak for yourself. I am not guilty of any of these in my large node applications. And I use no frameworks, just npm libraries.

That's not really true. Frameworks enforce patterns on developers (e.g. MVC), and they create a consistent ecosystem within which you can create easily interoperable plugins.

The author's point seems to be informed by being burned by many bad frameworks (which is, to be fair, 90% of frameworks - if you pick based upon fashion driven development this is the hole you'll end up in).

A good framework is rare but immensely valuable. A bad framework is worse than no framework at all.

And furthermore, sharing frameworks has been responsible for the incredibly fertilization. When you consider the recent pace of Javascript development - with jQuery, and now React, we've had years of huge, newly-developing libraries, plugins, communities, and sites-becoming-apps. Turns out, you don't need to effuse limitless creativity when creating a viable web app. You need the same few things over and over, and you'd rather use something with a lot of extendable pre-written code. Facebook built React/Flux because they saw their apps facing a very similar set of problems over and over again. By sharing this admittedly large and ever-shifting set of tools, javascript development has had some terrific momentum.

In some ways, once an organization has really settled into a set of linting rules, testing coverage requirements, shared components, and code review adhering to a style guide, you're freed from all of that pesky creativity. You can just write the thing you have a spec for by reasoning about the minimal data you need to represent the possible states of the app. You eschew choices, and your collaboration is easier, less egotistical, and more productive.*

*Written by an idealistic bleeding-edger.

Frameworks do what the name implies - they provide a consistent base

The consistent base should be provided by the language itself. If your language isn't providing that, it's deficient. Powerful languages discourage frameworks and prefer small libraries. Deficient languages encourage frameworks and tons of repetition because they lack some key features of abstraction.

It sounds like your argument is just to outsource coding standards to the framework's team.

Reply on news.ycombinator.com