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.
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".
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.
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."
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...
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.*
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.
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 :)
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.
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.
> For that last 20%, they just get in the way and cause more problems than they solve.
If I had a nickel for every project I worked on that started using an ORM but eventually was forced to write actual SQL to cover those use cases the ORM just couldn't I'd be rich. In fact it's the number 1 reason I don't even bother with ORMs anymore.
If I abstract my data access to a set of APIs then all I have to do is reimplement the SQL or whatever behind each API when I need to move to a new storage system which usually ends up not being very difficult compared to the headaches of trying to get an ORM to cover that last 20%.
While I do write SQL during exploration, for the purposes of production systems I've never had a query that I haven't been able to represent using SQLAlchemy. The reason for this is that in addition to being an ORM, it exposes an object-oriented general SQL abstraction layer.
> For that last 20%, they just get in the way and cause more problems than they solve.
This is why my preferred measure of an ORM is how effectively one can write your own SQL with it, and what you get out from your database call when you do so (do you still get "real" business objects or just key-value pairs?)
That said, I've found you can trick even a rather recalcitrant framework into making sophisticated queries by setting up a database view and tell your ORM that the view is just another table...
However you can deal with SQL safely bypassing the ORM if you compose the queries correctly. An example with Ruby and the pg driver for PostgreSQL:
db.prepare("select_title", "select title from posts where author = $1::text")
...
db.exec_prepared("select_title", [ author ]) do |result|
...
end
I concede that it's more prone to unsafe coding than Post.where(author: author).pluck(:title)
Everybody in the team must resist the temptation to ever write a db.exec("select title from posts where author = #{author}")
What I do is using the ORM all the times, except for complex queries that would be a nightmare to code with ActiveRecord/Arel and to understand when written in Ruby. In those case I use ActiveRecord's find_by_sql. It can be protected by SQL injections easily. I quote the documentation:
Post.find_by_sql ["SELECT title FROM posts WHERE author = ? AND created > ?", author_id, start_date]
Again, it has the same problem of having to enforce the discipline of passing the arguments in the right way but there are countless ways of making a project unsafe and the team must be trained to prevent unsafe coding practices. SQL is only one of them.
Intro tutorials will cover lots of ways to prevent common security issues.
Hard experience has taught that programmers still won't adopt those approaches in significant numbers unless their tools are forcing it on them by default.
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.
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.
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?
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
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.
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))
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.
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.
I've been getting a bit farther along with Phoenix - just building a toy Instagram-lite site for learning purposes.
I like the Elixir language, but I'm a little concerned that in a real-world production app you'd really need to learn the fundamentals of Erlang and OTP as well (especially for things like error handling). So while Elixir is fairly easy (if you've done a bit of Ruby and functional programming) it's really the tip of the iceberg.
Phoenix itself is OK, but the lack of documentation and examples is brutal. It's very easy to go off into the weeds trying to do very basic stuff. I'm sure I'm doing a lot of things wrong, but there's a lack of clear examples to show the right way, even for simple things like "how to get the first row of a complex query with Ecto". I've stayed clear of doing an SPA so I don't get bogged down in Javascript tooling and pipelining issues, but a lot of things are missing from the basic setup - for example, Phoenix uses Bootstrap by default, but for some bizarre reason they don't include the glyphicon fonts out of the box, so you actually have to download/install bootstrap somewhere and copy fonts over. Maybe not a big deal in itself but enough of these annoying issues can sap momentum and enthusiasm.
I get that Phoenix is alpha, non-production ready software unless you happen to be a core dev, but the deeper feeling I keep getting though is that I don't really like big-box frameworks anymore. Sure, Django is still my go-to for a straightforward, lots-of-CRUD-screens type of project and it does that job very well. But I don't want to learn another Django. A lot of side projects I just want to start small, build out a nice UI in React or Vue (or play around in the mobile space) and add an API when I need a backend store or SMTP or whatever. For that Flask is fine, or maybe Go (or in your case, Plug). Use whatever libraries you need and follow sensible design patterns that suit the case at hand.
Phoenix is definitely production ready, as I am using it in many production systems now.
1) You have to eventually get into OTP. Elixir language is ok but all the stuff which makes it attractive is OTP and it's concurrency. If you are building a very small API you don't have to learn OTP ans you can get very far with that.
2) I find Phoenix documentation very good and the number of examples are increasing a lot day by day.
3) The default included bootstrap is just to show the landing page. You have to add your own css which you have to do if you use any other framework or library.
4) Phoenix is nothing like Django or Rails. Phoenix is very modular. See http://theerlangelist.com/article/phoenix_is_modular
> I find Phoenix documentation very good and the number of examples are increasing a lot day by day.
We can beg to differ. Yes, it's improving, but there's still a long way to go before it's at the standard of more mature frameworks.
> The default included bootstrap is just to show the landing page. You have to add your own css which you have to do if you use any other framework or library.
Sure, but if you're going to include bootstrap then you might as well do it properly rather than half-assing it. Better to not install bootstrap, I'd be fine with that, but to include it kinda-sorta then have bits missing is just going to confuse newbies.
> Phoenix is nothing like Django or Rails. Phoenix is very modular
Maybe it is, but you have to get far into the learning process to figure out where everything fits together, with pipelines, plugs, and so forth, before you can add and remove what you need. Out of the box Phoenix comes with a ton of dependencies and configuration you need to reason about first. In that respect it's very similar to Rails and Django.
Starting small and adding functionality that I need as I go allows me to understand exactly what I'm doing and why. I get to make the choices about whether I need a dependency, and what the costs of that dependency are.
If all I need is 5% of the functionality, I can code up a small module to do just that without importing 150Kb of random unnecessary.
> 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
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.
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.
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.
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.
One of the things I like about the .NET Linq-to-SQL and EF ORMs is that it's pretty easy to plug into them and get them to dump the actual SQL that they are executing.
Still, you really need to have a good handle on the difference between operations that build up the query, without executing it, and those that pull the data back from the database. Also understanding what code constructs that the ORM is capable of translating into SQL statements.
.NET is actually the framework that gave me such a bad taste for frameworks. It's important to note that my experience with it is from around 2010-2012 though so it could have gotten much better since.
The ORM in particular would sometimes cause me to write very inefficient queries. If I understood the ORM better, I probably could have avoided this, but I found it much easier to write a data layer that ran SQL queries directly and supplied the other layers with simple JSON-like objects.
Yeah, most of the projects I've been working on lately wouldn't be possible with a licensed operating system. For me, working with linux is very difficult, but the capability far outweighs the difficulty. I don't catch on easily to concepts, commands, and multiple steps of such an advanced tool.
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.
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.
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.
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.
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.
Sinatra would be the Express equivalent for Ruby, and is very powerful and useful and illustrates these points. There is a lot more configuration with these types of things, but the tradeoff is the overhead that isn't bloating your stuff.
That, and I really think in hindsight the value of understanding things better and building 'from scratch' is immense.
Once I built my own 'CMS' using express and RethinkDB, I had to also set up on a templating system (so I chose React server-side). I ended up using a bunch of other tools or technologies as well. All of these were on my list, but I never really found a good excuse to look into them. But now I had to pick something (as opposed to settling for HAML in Rails, or any of the other 'popular' approaches, and actually figure out what the advantages and drawbacks were, as well as how to tie all these things together.
Not only was it fun in a way that building Rails sites often isn't anymore, it was incredibly educational.
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.
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.
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).
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.
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.
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.
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)
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?
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.
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.
Sounds like you're solving different problems than I am. May I ask what kind of problems you're solving, that the same framework works for all of them? Never mind, my question is really just bait, don't answer it.
My point is that there's a certain arrogance to watch out for, when we claim that our solutions will work for other people's problems, but we don't really understand what their problems are. I've shared my negative experiences with frameworks, but I can't speak universally. I can only suggest that people not use frameworks, based on the experiences I had. I'm not about to—for example—state outright that someone is doing things wrong just because they don't make the same choices I would make. This is the kind of attitude that I watch out for when mentoring junior developers who think code is "messy" and needs to be "fixed" just because it doesn't match the way they write code.
I'm very reluctant to learn any more frameworks because tomorrow's problems seem not to match the frameworks we chose yesterday. Again, this is just my personal experience, and you use different frameworks and solve different problems.
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.
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.
>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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
- 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!
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.
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...
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.
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.
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.
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.
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.
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."
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.
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.
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.
You've still created a defacto framework there by stating that your applications are built by integrating libraries a, b, and c in a particular way. You're also left actually maintaining that integration, and managing the entire stack for all applications using it.
Maybe that's a win for you and the extra flexibility is worth the effort, but that's probably not the case for most organisations.
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.
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.
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.
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
>"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.
> 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?
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?
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.
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.
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.
> 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?
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.