10 ms·

Frameworks Don't Make Much Sense

136 points by th0ma5 11y ago

dools 11y 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.html http://www.workingsoftware.com.au/page/Kill_your_index.php.h...
- jon-wood 11y 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.
  - dools 11y 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.
    - jon-wood 11y ago
      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.
ludamad 11y ago
The author doesn't mention using frameworks for prototyping, isn't that useful for deploying earlier?
marcus_holmes 11y 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 11y 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 11y 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.
    - deleted 11y ago
      [deleted]
  - sanderjd 11y 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.
onion2k 11y 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.
- Johnie 11y 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 11y 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.
    - deleted 11y ago
      [deleted]
    - 11y ago
elliotec 11y 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 11y 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-wood 11y 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.
- matt4077 11y 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.
  - mercer 11y 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.
cenal 11y 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 http://www.browserling.com) for those of you who need browser based testing.
- greggman 11y 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 11y 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...
  - esailija 11y 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.
Johnie 11y ago
I'm curious about how large of a team/organization and size of the codebase the framework vs anti-framework camps fall on.
leohutson 11y 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 11y 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 11y ago
    Yes. Thus, in one program, you can use multiple libraries, but not multiple frameworks.
    - AstralStorm 11y ago
      Sometimes you can and it is not even too hard to make them interoperate. This begs the question why would you want to though.
  - leohutson 11y 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 11y ago
Higly specialized do, general purpose bloatware don't.
franciscop 11y 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/ http://umbrellajs.com/
- maxwin 11y 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 11y 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.
  - esailija 11y ago
    jQuery is not a framework, it's a collection of helper functions for the DOM.
  - franciscop 11y 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 11y 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.
hoodoof 11y 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?
- dietrichepp 11y 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.
  - hoodoof 11y 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.
windlep 11y 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 11y 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."
  - raverbashing 11y 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 11y 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 11y 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.
- aikah 11y 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 11y 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 11y 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 11y 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 11y 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).
raverbashing 11y 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.
aikah 11y 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 11y ago
I too like to come up with rationalizations of my NIH syndrome.
ChrisDutrow 11y 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 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.
- matt4077 11y ago
  I think that article is indeed written by a simple=minded freak who's in the extreme minority.
Walkman 11y ago
This guy did not used Django yet. It does so much for you it's incredible. Huge productivity boost.
RangerScience 11y 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 11y 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.
- ChrisDutrow 11y 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.
tarsinge 11y 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
AstralStorm 11y 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.
- esailija 11y 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.
  - AstralStorm 11y 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 11y 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 11y 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 11y 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 11y 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 11y 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 11y ago
Frameworks are framing libraries are liberating :)
MrPatan 11y 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 11y ago
Man, it sounds as if the author has suffered from js framework hell and thinks all frameworks for all languages are bad.
stevesun21 11y 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.
deleted 11y ago
[deleted]
rawfan 11y ago
The author seems to be a big fan of re-inventing the wheel all the time.
- esailija 11y ago
  Duplication is preferable to using the wrong abstraction.
  - AstralStorm 11y ago
    So don't choose a bad framework?
- deleted 11y ago
  [deleted]
JDDunn9 11y 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 11y 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/
- ludamad 11y ago
  I certainly hope no one prefers hardware solutions to small abstractions :)
poosanth 11y ago
Very anecdotal and personal.
jameshart 11y 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 11y 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 11y ago
I completely agree, but this attitude gets you in trouble unless you're the boss.
frik 11y ago
Frameworks are all or nothing. It's better to use libraries. That's also the right kind of abstraction.

136 points by th0ma5 11y ago

dools 11y 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.html http://www.workingsoftware.com.au/page/Kill_your_index.php.h...

jon-wood 11y 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.
- dools 11y 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.
  - jon-wood 11y ago
    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.

ludamad 11y ago

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

marcus_holmes 11y 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 11y 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 11y 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.
  - deleted 11y ago
    [deleted]
- sanderjd 11y 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.

onion2k 11y 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.

Johnie 11y 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 11y 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.
  - deleted 11y ago
    [deleted]
  - 11y ago

elliotec 11y 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 11y 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-wood 11y 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.
matt4077 11y 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.
- mercer 11y 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.

cenal 11y 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 http://www.browserling.com) for those of you who need browser based testing.

greggman 11y 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 11y 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...
- esailija 11y 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.

Johnie 11y ago

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

leohutson 11y 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 11y 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 11y ago
  Yes. Thus, in one program, you can use multiple libraries, but not multiple frameworks.
  - AstralStorm 11y ago
    Sometimes you can and it is not even too hard to make them interoperate. This begs the question why would you want to though.
- leohutson 11y 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 11y ago

Higly specialized do, general purpose bloatware don't.

franciscop 11y 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/ http://umbrellajs.com/

maxwin 11y 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 11y 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.
- esailija 11y ago
  jQuery is not a framework, it's a collection of helper functions for the DOM.
- franciscop 11y 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 11y 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.

hoodoof 11y 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?

dietrichepp 11y 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.
- hoodoof 11y 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.

windlep 11y 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 11y 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."
- raverbashing 11y 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 11y 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 11y 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.

aikah 11y 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 11y 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 11y 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 11y 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 11y 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).

raverbashing 11y 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.

aikah 11y 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 11y ago

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

ChrisDutrow 11y 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 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.

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

Walkman 11y ago

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

RangerScience 11y 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 11y 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.

ChrisDutrow 11y 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.

tarsinge 11y 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

AstralStorm 11y 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.

esailija 11y 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.
- AstralStorm 11y 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 11y 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 11y 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 11y 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 11y 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 11y 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 11y ago

Frameworks are framing libraries are liberating :)

MrPatan 11y 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 11y ago

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

stevesun21 11y 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.

deleted 11y ago

[deleted]

rawfan 11y ago

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

esailija 11y ago
Duplication is preferable to using the wrong abstraction.
- AstralStorm 11y ago
  So don't choose a bad framework?
deleted 11y ago
[deleted]

JDDunn9 11y 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 11y 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/

ludamad 11y ago
I certainly hope no one prefers hardware solutions to small abstractions :)

poosanth 11y ago

Very anecdotal and personal.

jameshart 11y 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 11y 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 11y ago

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

frik 11y ago

Frameworks are all or nothing. It's better to use libraries. That's also the right kind of abstraction.