Frameworks Don't Make Much Sense

http://www.catonmat.net/blog/frameworks-dont-make-sense/

by th0ma5 • 10 years ago

136 138 10 years ago

dools2• 10 years ago

I'm a huge fan of libraries, rather than frameworks. I wrote an article on this topic some time ago, focused specifically on PHP[0]

I don't think that frameworks regularly achieve ANY of the results they set out to achieve, and they age terribly.

[0]http://www.workingsoftware.com.au/page/Kill_your_index.php.h...

jon-wood3• 10 years ago

In any reasonably large organisation that is going to take you down one of two routes.

The first is that you end up with a defacto framework made up of the libraries that are useful in every project, with configuration copy and pasted from project to project. At some point you'll end up abstracting all that out into a higher level library, and boom, you're maintaining an internal framework.

The second, even less desirable, outcome is that every project in the company uses whatever mess of libraries the person who kicked off that project liked at the time. In that situation every time someone needs to work on a new project they lose hours to working out which libraries were being used, and learning how they fit together in this particular case.

dools2• 10 years ago

In python you can use flask, in php you can use php. In both cases there are lots of common libs everyone will know how to use that can be included in the project, but not tied to a single framework. Once you remove templating, routing, orm and package management/directory structure from most frameworks you're not left with anything useful. So solve those problems at a library level. No framework required.

ludamad2• 10 years ago

The author doesn't mention using frameworks for prototyping, isn't that useful for deploying earlier?

marcus_holmes6• 10 years ago

Unfortunately I think Rails has poisoned the well here. Too many web devs seem to expect that any environment they code in should have all the bells and whistles that Rails has.

My particular bugbear is working with people who refuse to learn SQL as if it's some arcane bit of weirdness on a par with machine code. They've only ever used ORMs and have no idea how to actually talk to their data. /rant

I recently looked at Phoenix, and ran into a few dependency issues straight out of the box. Thankfully, because it reminded my why I stopped using frameworks ;) I started getting to grips with Plug instead... much better :)

melloclello• 10 years ago

My particular bugbear is working with people who refuse to learn SQL as if it's some arcane bit of weirdness on a par with machine code. They've only ever used ORMs and have no idea how to actually talk to their data. /rant

Lol this is me. People who write their SQL from scratch confuse me, I'm like, just use the ORM and then everything's consistent! :P

spotman• 10 years ago

The real trick is to have a deep understanding of SQL before you use an ORM so that you know exactly what you are asking the ORM to ask the database to do.

Otherwise you will never be able to really understand what is going on and will not be able to optimize a complex app that needs to be performant at scale.

Learning both has its advantages and I think an ORM can indeed speed up development, most especially for the prototyping phase.

sanderjd• 10 years ago

Learning about the relational model and its mapping in SQL is a really major level-up that you should really consider getting under your belt!

I used to do a lot of hiring of Rails developers, and always believed (though admittedly not scientifically enough) that the best differentiator between "sorta productive" and "capable of fully independent work" was an understanding of how AR maps to SQL and the ability to know when (and how best) to drop down into writing queries directly.

ericd• 10 years ago

You might want to look at some of the SQL that your ORM is generating for your important queries... Because a lot of times, odds are it's much, much less efficient than it could be.

I've seen ActiveRecord create some head scratchers.

ChrisDutrow8• 10 years ago

A developer who doesn't understand SQL could be a little dangerous because they might not understand data structures and big-O concepts (sets, hash tables, etc..). I don't think someone needs to be a wizard with the syntax, but they need to understand what the database is doing. Otherwise they could write something that won't handle load under real world use.

nissimk• 10 years ago

Don't trade consistency for power. If you know sql, you can answer questions about your data without writing a program, by just executing queries in a database UI. This ad-hoc querying is far more powerful than any other debugging technique for many classes of problems.

afarrell• 10 years ago

I have been thinking of writing an SQL tutorial specifically for folks who have only worked in ORMs. Do folks here have a favorite SQL tutorial that I should look at for stylistic inspiration?

john2x• 10 years ago

I'm spoiled by ORM's, but I have no problem using SQL to query the database. What I have trouble with though is creating tables using raw SQL and managing schema migrations. Even when using an ORM it seems kind of messy. I'd love a tutorial on how to properly maintain migrations without an ORM.

eximius• 10 years ago

Stanford has an online databases course that is a bit more thorough than you'd probably intend, but it is very excellent.

marcus_holmes6• 10 years ago

The things that no-one seems to know about from ORMs are:

1. Stored procedures. the idea that you treat your SQL like other code, and put it in sprocs, parameterise it, version it, etc.

2. Optimising tables and playing around with different normal forms and indexes to get the best results. Database design, basically. The 1:1 Object:Table mapping that ORMs use is not always optimal.

3. Indexing multiple fields that get queried together. If you commonly query on user name and state, then create an index for that. Maybe. If that table is read from more than it's written to. If read time optimisation is more important than write time optimisation.

I haven't looked at a SQL tutorial recently, so I can't help with that, sorry

ocean3• 10 years ago

What kind of dependency issues?

marcus_holmes6• 10 years ago

to be honest I can't remember, as I flipped the table after my third time trying to get it all to work, and deleted the whole thing.

I was using this tutorial: http://phoenix.thefirehoseproject.com/0.html which was featured recently in HN and uses a pretty old version of Phoenix that no longer works out of the box (something about an Access error?). Trying to work out which version of Phoenix since 0.8 does actually work out of the box was fun.

There was the problem with babel needing the ES2015 in a .babelrc in the application folder. Took me a while to find that one. It's been an outstanding issue on the Phoenix repo for a while now.

Then my version of Chrome wasn't playing nicely with Elixir - I would get a 400 response no matter what. This isn't a Phoenix problem, I get the same thing with Plug. Bit of a head-scratcher, works fine in Incognito mode, doesn't work in vanilla even with all the extensions disabled. Took me a while to work out where that problem was.

then I got to building a controller, and it just wouldn't compile for some reason. I got a bit fuzzy around here due to the rising rage at the bloody thing and why won't it just bloody work I'm sure I haven't fat-fingered that it should just bloody work why oh for god's sake stuff this.

Eridrus• 10 years ago

I'm pretty glad ORMs caught on; I remember the bad old days when developers did write all their own SQL queries: we ended up with piles of SQL injection everywhere.

dopeboy• 10 years ago

Though I'm glad ORMs caught on too, preventing injections is covered in almost newbie tutorial when dealing with SQL.

marcus_holmes6• 10 years ago

The only time I've had a problem with SQL injection is with a PHP dev who just didn't get the whole issue. Mind you, he didn't get a lot of things.

It's one of those things you generally learn once and never have a problem with again.

pjmlp• 10 years ago

On which world?

We still do them by hand, as ORMs don't match the performance of the data that we work with.

Plus it is dumb to have data cross the wire for DB operations that can happily stay on the server.

I always enjoy showing some devs how well written SQL outperforms their beloved ORM.

jammycakes• 10 years ago

ORMs are a massive benefit to productivity and security for about 80% of your database access. The problem is that people expect to use them for 100% of their database access. For that last 20%, they just get in the way and cause more problems than they solve.

RangerScience2• 10 years ago

Can't help you with the refusal, but the easiest path from Rails ORM to SQL is the ".explain" method - or just paying attention to the console output when running an ORM query, and seeing how your ORM code gets translated to SQL.

smitherfield• 10 years ago

Understanding the SQL an ORM generates is definitely an underrated skill. I've probably fixed hundreds of inefficient/N+1 queries and injection vulnerabilities created by developers who either didn't know what SQL they were generating or didn't think about it.

crdoconnor2• 10 years ago

Not nearly as underrated as an understanding of normalization.

SQL can just be picked up if you don't know it. It's a known unknown.

A lack of understanding of normalization is something that leads people to create epic, incredibly hard to escape from architectural fuckups without even realizing the hole they've dug for themselves.

tarsinge2• 10 years ago

In Rails for complex applications I always start with the SQL in my mind, and I bend the ORM to produce my SQL (if I can, otherwise I use plain SQL). For example to generate a NOT IN : ModelA.where.not(id: ModelA.joins(:model_b).where(...).select(:id))

onion2k3• 10 years ago

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.

Johnie2• 10 years ago

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.

pilsetnieks• 10 years ago

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.

lmm• 10 years ago

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.

kganser2• 10 years ago

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.

ubernostrum2• 10 years ago

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.

aikah3• 10 years ago

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.

crdoconnor2• 10 years ago

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.

quxbar• 10 years ago

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.

andrewgjohnson• 10 years ago

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

chongli• 10 years ago

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.

elliotec3• 10 years ago

I think there are solid cases where frameworks make a lot of sense. They provide very helpful layers of abstraction on often used patterns, like Rails CRUD apps, in which you can just use the command line to generate fantastically useful patterns that would take forever to implement.

On the other hand, learning the basics of a language, or more importantly learning how programming works and how software is written, is going to be far more powerful than learning a framework first, even though that is often the step most newcomers take.

Learning the ins and outs of JavaScript for example is going to help you immensely in navigating the mess of JS churn and you'll be able to learn the framework du jour much faster than approaching it framework-first.

routerl• 10 years ago

Hear, hear.

I'm learning exactly those (hard) lessons right now, as a (very) junior developer. I'd written a couple of CRUD-with-embellishments apps, using Django and Meteor. Now I'm staring down the length of my first non-framework JS app and learning huge amounts about software architecture, design, workflow, etc.

It's intimidating, frustrating, and occasionally paralysing, but I can track my growth as a developer, rather then just tracking my app's growth.

jon-wood3• 10 years ago

My feeling on the matter is that the developer you want to hire is one who can write a decent framework from scratch, but who also knows its probably not the best use of their time. Extra points if they can identify the one time in a thousand they should be doing everything from scratch.

matt40772• 10 years ago

True – but: I think I never learnt so much so much in such a short time as when I started with rails. MVC, project layout, API design – a good framework can be an incredible role model for these higher-level concepts.

mercer2• 10 years ago

I can highly recommend you go even 'lower' than that and use something like Express, or go framework-less. I did that once, and I learned to appreciate so much more why Rails/Django/whatever is built the way it is. I really think I became a better Rails developer, and a better developer in general, by dropping down to a lower level.

elliotec3• 10 years ago

I absolutely agree with this actually. Rails is a bit of a unicorn I think in that respect. You can create wildly amazing things without knowing much actual ruby at all, which is beautiful.

cenal• 10 years ago

Frameworks make perfect sense if you don't know what you are doing. I've seen way too many inexperienced developers that try their hand with coding something from scratch only to have the product development fail spectacularly and never launch.

If you are as accomplished as the author then a framework is probably going to only slow him down. In full disclosure I've worked with the author. Peteris Krumins is an extremely talented developer who has a very cool startup called Browserling (http://www.browserling.com) for those of you who need browser based testing.

greggman• 10 years ago

frameworks make sense even if you do know what you're doing. Google, Facebook, all the top companies use frameworks. Why would I want to waste time reinventing the wheel. I just want to drive the car to get to my destination. I don't want to build the engine.

A better analog might be movie making and some guy claiming "buying cameras makes no sense. You should develope your own cameras and your own film. it's more creative".

No, it's not. It's wasted time doing busywork someone else has already done. Similar to game engines. You could write your own and spend 1 to 10 man years reproducing what's already been done. Or you could spend that 1 to 10 man years on design, prototypes, and iteration in the actual meat of your project.

JackFr• 10 years ago

If you've ever made a pinhole camera they're actually relatively easy to make and tons of fun. No good for movies though...

esailija4• 10 years ago

They use frameworks that they themselves invented specifically for their use cases, they didn't take someone else's framework because they know it doesn't make sense just as the author claims.

Johnie2• 10 years ago

I'm curious about how large of a team/organization and size of the codebase the framework vs anti-framework camps fall on.

leohutson2• 10 years ago

Frameworks are just a set of libraries that play nice.

If you use a bunch of separate libraries from different developers, then you have to write a lot glue code to get data between those libraries.

That code is usually slower, as it will involve copying and transforming data, i.e. you'll be copying data in and out of different classes, copying data to memory allocated by the library, copying data to differently aligned memory, transposing data, copying data between different sized scalar types etc.

Frameworks make cross platform development a lot faster, and learning a framework is no more of a waste of time than learning another language or native OS api.

I absolutely agree, that bundling together a bunch of dependencies, and having those dependencies maintained by the same vendor has a risk/cost.

Don't choose a shitty or faddish framework; put as much research into choosing your framework as you would into researching it's individual libraries, use the framework as it was designed, and only use what you need.

learc83• 10 years ago

Frameworks are just a set of libraries that play nice.

Many times when people talk about the difference between frameworks and libraries, they are talking about which code is driving the program. I think this is the case here.

An overly simplified example of the difference is that, with a library, your code calls the library. With a framework, the framework calls your code.

Animats• 10 years ago

Yes. Thus, in one program, you can use multiple libraries, but not multiple frameworks.

leohutson2• 10 years ago

Not quite sure I understand the calling distinction? I guess the article is more about web frameworks, which I have no knowledge of. I had desktop applications in mind, in particular GUI centric frameworks like Qt, which aside from moc is mostly just a very extensive set of libraries that build functionality on top of each other.

dschiptsov• 10 years ago

Higly specialized do, general purpose bloatware don't.

franciscop2• 10 years ago

I followed this advice, I used document.querySelectorAll() with a .slice() hack instead of jquery and similar methods. As I needed more and more functions I kept adding them, and now I have a beautiful jquery alternative [1].

It has helped me a lot to learn core Javascript concepts, testing my code and hating Internet Explorer even more. I wouldn't change everything that I have learned for anything. So try it, create your own small library, you'll learn a lot.

[1] http://umbrellajs.com/

maxwin• 10 years ago

So as time goes by, you ended up creating a jquery alternative. Now imagine you work on a large team and everybody ends up creating their own frameworks...

saiprashanth93• 10 years ago

I think the above comment should be taken in the context of doing it for the sake of learning, not for putting it to use in actual projects.

esailija4• 10 years ago

jQuery is not a framework, it's a collection of helper functions for the DOM.

franciscop2• 10 years ago

That would be awesome since then everyone would learn A LOT about javascript. But to work together with other people, one of the first things to decide is the technology; and if you create something from scratch as a team, you do it together, not each one their own.

gosukiwi• 10 years ago

You can learn a lot of things from frameworks. If you try to come up with your own solution without beeing experienced enough you'll end up with a mess.

hoodoof2• 10 years ago

I don't buy it at all.

Of course frameworks take alot of effort to learn.

But the point is that you'll pay an up front cost in time and learning and get a much bigger payoff further down the track in productivity and possibility.

You have to be really careful not to get a programmer like this on your team - I have encountered a few. They are scornful of all code that they didn't write so they rewrite everything. Pure waste of time.

One of the smartest programmers I know said that if you work within a well organised codebase then over time your programming should get faster, whereas without a well organised code base you will get mired in a sticky swamp and things will become multiples of slower.

A good framework should give you that well organised framework within which to perform at your best productivity. Of course a crap framework won't do anything for you but why use a crap framework?

dietrichepp2• 10 years ago

The time taken to learn the framework was a relatively minor point of the article. I have serious doubts about the payoff—in my experience, by the time you know a framework well, you are fighting against mismatched abstractions, edge cases, performance issues, etc. You spend more time fighting the framework than developing your application. Then if you change to another framework, you have to learn everything over again. But if you use a bunch of libraries instead, you can swap one of them out without touching the others. For example, I can keep the same router but use a different ORM.

The same problems with bad abstractions happen with many applications in the long run, but it seems that using a framework will get you there more quickly. I'd say that the advantage of frameworks is developing many smaller prototypes more quickly.

hoodoof2• 10 years ago

Sounds like you're using the wrong framework.

May I ask what framework you have in mind with those comments?

I have to say I am very careful about how I budget and spend my learning time. I do not have much time so I make a big decision when I invest in learning a framework and I plan for it to pay off over a number of years. It would be deeply inefficient to be working at a shallow level of understanding across more than two or at most three frameworks.

I've chosen one web server to understand deeply and one front end browser based framework to understand deeply and I'm reluctant to take on anything more than that.

ChrisDutrow8• 10 years ago

I agree, selecting libraries is a much more fluid approach. Once you get comfortable with your libraries, you basically have your own framework without the commitment.

scotty79• 10 years ago

Of course frameworks take alot of effort to learn.

Trick is to pick the framework you'd be forced to write anyway for your project if you didn't have one. Then learning comes naturally.

windlep• 10 years ago

This ignores the problem of not using a framework, that is, for a sufficiently complex project you will eventually end up with your own ad-hoc framework if you don't use an existing one. Maybe it's better, maybe worse, but one will appear regardless.

That's how Django and Rails started (and I'm sure many more). Ad-hoc frameworks that then get yanked out of the project so the company can re-use the useful parts.

I've seen quite a few ad-hoc frameworks companies have inadvertently created in their effort to "not use a framework", rarely were they nearly as good as what was already out there in the OSS world.

wwweston• 10 years ago

you will eventually end up with your own ad-hoc framework

Or some people call it, "code that solves the problems we actually had."

raverbashing2• 10 years ago

While creating 10 other problems usually

Sometimes I agree that using a home-grown solution is better, but you don't want to reinvent what took a lot of time and a lot of people to work through (like Frameworks, DBs, etc)

ng12• 10 years ago

That is virtually unmaintainable. What happens when Joe Hacker moves on to greener pastures? The new guy gets stuck with a framework that he can't Google. This is where the author lost me:

You've to ask for expert help, wait until someone helps you or pay an expert framework consultant.

The ability to ask an expert for help is a boon, not a curse.

stop1234• 10 years ago

Most people are commenting about to use a framework or not.

The hard part is choosing which framework to use when you have so many to choose from.

How do you do that? The simple answer of using the most popular one is moot since we would all be using wordpress if it was about CMSs...

"Frameworks limit your scope of creativity" - I get that.

aikah3• 10 years ago

The hard part is choosing which framework to use when you have so many to choose from.

No it's not hard. Most frameworks/libraries stop being maintained after a couple of years. Only a handful are stable and being maintained seriously. It's not hard to pick and choose what to use.

The simple answer of using the most popular one is moot since we would all be using wordpress if it was about CMSs...

Wordpress code might sucks but is actively and seriously maintained. The problem with Wordpress is that people use it for things it was never designed for. Who is to blame? The maintainers or the users?

mrweasel• 10 years ago

"Frameworks limit your scope of creativity" - I get that.

I sort of agree, but I don't think it really matter that much. The majority of the work people do are basically just database front-ends. You put stuff in, you pull stuff out, your creativity is already severally restricted by the job at hand. It makes a ton of sense to pick a framework for your CRUD application, it speeds up development time by a lot, and the creativity limiting effect is negligible.

Frameworks like Django provides a ton of features that there's absolutely no reason to reimplement, because you're just going to do it wrong anyway. You're not going to get CSRF tokens right and you're user management system is going to have some weird flaw. It's not that people shouldn't try to write these things, they absolutely should, but not if they're just trying to do a quick application.

Confusion• 10 years ago

Most of these arguments seem to apply to any 3rd library, but I don't suspect the author wants to argue against using those. I guess the question is: when does a library become a framework and until when do the benefits of code reuse overcome the cost of these downsides?

cryptos• 10 years ago

I disagree. The question whether to use frameworks or not is a bit more complex. As everything in software engineering, like choosing a framework, is a trade-off. Frameworks come with a price and it depends on the context, whether it pays off or not. I've seen some really terrible in-house "frameworks", because someone decided not to use a framework. And over time the few "helper" and "util" classes evolved into a poorly structured and poorly documented framework with poor test coverage.

Common frameworks are (in general) not only better structured, better documented and tested, but it is far more likely that new developers have some knowledge of them, whereas your in-house code-dump is not known by anyone else.

amasad• 10 years ago

Posts like this should start by clearly defining what they mean by framework. It's really hard to draw the line between a framework, platform or a library. One of the best differentiation I've heard between frameworks and libraries is that the former calls you but you call the latter. But even that is still not clear, a lot of libraries allow you to define callbacks and implements the adapter pattern to pass them classes and objects which in turn gets called by the library.

Let's take Browserify for example which I think the author and co most likely use. It allows you to define modules and then it calls those modules which are expected to prepare some objects that are passed to it. There is a contract, and it calls you. It sounds like a framework. What makes it any different than Rails or anything else?

You may say Browserify is based on the CommonJS standard. CommonJS being a real standard is debatable, but even if we accept that it's still an arbitrary line to draw. Any sufficiently popular framework can make itself a standard (e.g. The json API that was inspired by many of the existing frameworks).

raverbashing2• 10 years ago

The NIH syndrome is strong with this one

No, they make a lot of sense. Regardless if you use Flask, Django, Rails I don't want to reinvent the wheel of receiving and dispatching requests, dealing with Sessions, etc.

aikah3• 10 years ago

Frameworks are one of the hugest anti-patterns in software development.

Says who ? this article isn't serious. If you're going to use an argument of authority you'd better quote that authority directly instead of making stuff up... seriously.

But I guess it was the outrage-bait of the day. Clearly some people know what sells.

Upgrading versions for no reason is another huge anti-pattern.

Says who again ?

Seriously, who is this guy ? what has he ever accomplished?

austerity• 10 years ago

I too like to come up with rationalizations of my NIH syndrome.

ChrisDutrow8• 10 years ago

I hate frameworks. God I hate them. Until I saw this post, I thought I was a simple minded freak in the extreme minority.

They are probably great for many people and projects. But someone like me, who wants things just so... I'm always fighting them and the're always getting in my way with their obfuscation.

I wrote this in Python/JavaScript, adding helpful libraries as I needed them (backbone.js for Javascrpt organization, jinja2 for templating to name a few) https://demo.enterprisejazz.com

Almost all the front end controls are custom and the back end database is a custom hybrid or Cassandra/Redis. I don't think software like that usually comes from a framework. Though I could be wrong cause like I said... I hate them.

matt40772• 10 years ago

I think that article is indeed written by a simple=minded freak who's in the extreme minority.

Walkman• 10 years ago

This guy did not used Django yet. It does so much for you it's incredible. Huge productivity boost.

RangerScience2• 10 years ago

Bullllllssshhhhiiiiiiit.

I work in industrial augmented reality (Daqri). Here is an actual task I, or someone else, actually has to do someday: I have a steel mill with 24000+ sensors distributed over ~20 machines and/or stations. I need to put the sensor readings into AR space as callouts over the relevant machine and/or station, as well as the results of any secondary processing of those sensors (aka, historical trend analysis, error predictions, etc), as well as ways to view and browse existing documentation of those machines, stations, sensors.

In order for the AR-based HMI to be effective, you're going to have to tweak and polish each machine/station's AR HMI.

Then I have to do that to the facility that uses the steel this facility produces. And then the facility that uses the steel products THAT facility produces.

As each of these facilities was independently constructed, sensorized, and upgraded over the last few decades, each one has it's own differences and quirks, and although there are some solid and reliable standards, there's more than one and many of them are deliberately hard to integrate in order to create lock-in.

The only way I can imagine possibly being successful at this is with a framework that makes it easy.

So... Either the author has never had to do same-same-but-different over and over and over again, or we have different ideas as to what a framework is.

PS - This reminds me of the defaults/no-defaults debate, which I think ends up actually just being "stop working with code that has 'defaults' that are hard to change" - which I'd say mean they're not actually defaults.

hodgesrm• 10 years ago

The author's argument stands or falls based on the meaning of the word framework and the problem you are trying to solve.

Assuming Jersey and Spring qualify as frameworks and the problem is building web services it's hard to see the argument against using them. It takes about 15 minutes from a standing start with Maven and Eclipse to build a simple web service using Spring. Frankly unless you are writing the framework itself I don't know why most people would want to deal with issues like marshaling and demarshaling HTTP requests, let alone ensuring consistent adherence to REST conventions. Life's too short to spend very much of it dealing with wire protocols or worrying about low-level libraries that handle these problems.

The argument for frameworks gets even stronger when you start to consider cross-cutting issues like security where there's a substantial penalty if you get things wrong.

ChrisDutrow8• 10 years ago

I agree, as I look over these posts, it seems the people on opposite sides are visualizing what "not using a framework" means very differently. I assume the "not framework" people are selecting tried and true libraries, not writing code to marshal http requests.

tarsinge2• 10 years ago

As always, it depends of the context. When I'm writing apps with complex BUSINESS rules, and I spent the day with my client understanding a business process, I can implement it in a few lines in Rails, from database to UI. Frameworks are just another layer of abstraction, and sure you don't always need it

AstralStorm5• 10 years ago

This after one or two lines of text feels like an evolved rant by someone who had a specific issue with a specific framework and tries to justify their drastic steps or NIH.

All abstractions have warts and frameworks are no exception. An annoyance that is well known and cannot be easily fixed is no reason to throw out the baby with bathwater.

esailija4• 10 years ago

Frameworks are all or nothing, that is how they are different. Or does it make sense to have a codebase that has a mix of angular, react, backbone and ember for instance? Of course not. They are nothing like libraries in this regard.

AstralStorm5• 10 years ago

Correct, which is why the choice of the framework should be done intelligently and not haphazardly. A good framework is flexible enough to handle weird corner cases with grace. Sadly, this is often lacking in the frameworks for web development.

The author suggests not using any frameworks at all, while instead they probably should write what they or most everyone should look for in one.

finalight• 10 years ago

if your codebase is already very large to the point that refactoring/rewriting can take ages, then I agree with not using framework from 3rd party

however, for starter pack, it's best to use a existing good framework. There's always a learning curve in whatever you do, but at least framework help you speed up your development.

TurboHaskal• 10 years ago

I guess he makes good points from a nerd's perspective, but I've found that frameworks make hiring really easy, allow new hires to be productive early on, provide a set of nice conventions and help reducing risks such as bus factor.

bobwaycott• 10 years ago

And yet, these "easy" new hires still get subjected to interview questions about algorithms and other useless things that don't actually matter to the work at hand. Sadly, I've seen too many clients wind up with great CS candidates who can allegedly solve all the things, but can't actually join the team and solve all the real things.[1]

[1]: Unless, of course, by "solve" you mean rewrite everything from scratch in New Hire A's language and framework and toolset of choice because ... reasons.

mbrock• 10 years ago

People disagree strongly with this article because it's written in a strongly opinionated way yet is also quite abstract in that it fails to specify the context and meaning of certain key things in the argument.

But whatever. This is how discussions work nowadays: someone makes a strong vague claim, and then other people react strongly against it, and we all have a fun time arguing.

"NIH syndrome" is a thought-terminating cliché.

Frameworks are sometimes useful in the same way that a "methodology" like Scrum is useful, or in the way a "theory" in social science is useful: they are patterns that people can learn and adapt to and they let people work continuously without always stopping to make fundamental decisions.

I think the anti-framework train of thought is very useful as an antidote to the framework mania that some programmers go through, or let's say the "anti-NIH syndrome."

You could kind of compare it to Paul Graham's thing about tiny teams of expert hackers using the power of Lisp to create their own kind of bottom up dialect perfectly tailored to the nature of their project. It's hard to do that if you're always jumping to put in complex external scaffolding that's designed for big teams.

tomelders• 10 years ago

Hmmmmm..... I think the sentiment in this article is ( or at least should be ) limited to web frameworks where the pace of change is too fast even for the most nimble of framework developers to keep up with. Things move so fast that web devs need "some" help.

I think the problem is that the first step in too many web projects is "what framework shall we use".

I like to quip that "Frameworks are great!... until they're not". And while I favour libraries over frameworks, that's not a panacea, it's more like a preference. For as long as the web continues to grow in complexity at irregular intervals and with zero real consensus, we will need to offload lot's of our work onto frameworks and/or libraries.

zby• 10 years ago

Frameworks are framing libraries are liberating :)

MrPatan• 10 years ago

- Frameworks make it easier to choose the right decision (or at least what the framework creators believe is the right decision)

- Frameworks make choices for you, yes, which reduces decision fatigue and lets you use creativity for the valuable stuff instead of for how to call that variable.

- Frameworks improve communication between developers. Implicit or explicit, they usually have a language (human language) that makes the most challenging part of software development (putting data in other people's brains) a bit easier.

Note how this applies to larger teams and projects. it's totally possible that a single developer working on a small thing is not the right user and use case for a framework!

rk06• 10 years ago

Man, it sounds as if the author has suffered from js framework hell and thinks all frameworks for all languages are bad.

stevesun21• 10 years ago

Framework useful, no doubt, but , I saw so many programmer cannot even design things without thinking about which framework they are going to use – frameworks kidnap these people ability to become a real programmer. I can show you an example right away, Ruby on Rails. I know someone they even cannot design REST APIs without thinking about ActiveRecord, what a shame! Don't get me wrong, frameworks is still good way to build things, but as a legit programmer, you need to own the ability to solve the same problems even without them.

rawfan• 10 years ago

The author seems to be a big fan of re-inventing the wheel all the time.

esailija4• 10 years ago

Duplication is preferable to using the wrong abstraction.

AstralStorm5• 10 years ago

So don't choose a bad framework?

JDDunn9• 10 years ago

I think this depends on the language. In languages where there is a de-facto standard framework, like Python & Django or Ruby & Rails, frameworks are very useful. Then slightly less useful in languages where there are many competing frameworks, like PHP. Then there's front-end Javascript with its flavor-of-the-month frameworks, where they probably do more harm than good.

al2o3cr• 10 years ago

Two fun alternative reads of this article:

s/framework/high-level language/ + s/core language/assembler/

s/framework/operating system/ + s/core language/hardware/

ludamad2• 10 years ago

I certainly hope no one prefers hardware solutions to small abstractions :)

poosanth• 10 years ago

Very anecdotal and personal.

jameshart• 10 years ago

All code runs inside some kind of a framework. It might be just the OS process framework, which requires you to implement an entry point that handles command line args, and provides you with access to threads and I/o streams. It might be an http server framework, which hands you requests and waits for your responses. Or it could be the web browser framework, with its Page lifecycle and ui events. You're always in a box of some kind; frameworks typically do things like create a different shaped box within an existing one (eg react creates a reactive box inside the browser's event based one). They can create the same shaped box inside different outer boxes (eg a jvm in a web browser and a web server and a console app). Or they can just make a simpler, more task-specific box.

Some frameworks are sandboxes - they don't let you even see the outer box (eg a page running in a web browser can't use the 'OS process' box that the web browser is in). Others give you a way to escape.

Sometimes it makes sense to intentionally box yourself in. It makes code easier to reason about. If there's no possible way for code inside this box to directly access files on this server then a whole bunch of security risks become easier to evaluate. If there is simply no way for code in this box to be multithreaded, a whole lot of synchronization risks just go away.

redblacktree• 10 years ago

I think what some folks may be missing is that highly-opinionated frameworks are extremely useful for less-capable programmers. I think most resistance to large frameworks comes from experienced developers who don't agree with all of the choices made by that framework. This is fine, and they shouldn't use it.

However, for someone who doesn't understand why they shouldn't pipe user input into a SQL statement, a framework can keep them out of a lot of trouble. Even though a more experienced developer may view it as "non-optimal."

hashkb• 10 years ago

I completely agree, but this attitude gets you in trouble unless you're the boss.

frik• 10 years ago

Frameworks are all or nothing.

It's better to use libraries. That's also the right kind of abstraction.

Frameworks Don't Make Much Sense

Related Stories