Hacker News Reader

Comment by ppeetteerr | Hacker News Reader

Please don't stop learning frameworks. Frameworks are there so you don't have to repeat the work of others.

Frameworks are like languages: some come and go, others remain for a long time (Rails, Django come to mind). We've replaced domain languages with generic languages that work on multiple platforms (hello, JS!). It's no longer just the language that matters, but the framework as well.

You don't have to memorize a framework any more than you have to memorize the STDLIB of a language, but never stop learning about new frameworks.

View on HN

> You don't have to memorize a framework any more than you have to memorize the STDLIB

While that's a valid opinion, it also misses the point. A framework is the opposite of a library. A library is something you call from your code. A framework is something that calls your code. (Fill-in-the-blanks coding, if you will.). Those are different skills and different use cases. For the former you can consult the man page for a specific API, but the latter requires some domain knowledge.

> A library is something you call from your code. A framework is something that calls your code.

Libraries and frameworks do both of those things. A library is something you can call from your code, but is it not calling your code if it uses callbacks? If you're not calling built in functions of a framework then you probably have no need for it.

I think the main difference between libraries and frameworks is that libraries interact with the language, whereas frameworks generally exist in their own little world, attached to but not embedded with the language itself.

That is, frameworks have an ecosystem associated with it, whereas libraries are the ecosystem.

And then the issue becomes that the ecosystem is fragmented between frameworks and the language, and things become a lot less general (suddenly you need interop code to switch between the framework’s world and a language library, akin to ffi), and you start getting locked into the framework’s world view, which tends to be quite limiting. Particularly in that when what you want, and what the framework wants, conflicts, everything goes to hell.

I think in general frameworks should be avoided when it can be composed out of libraries, in the same fashion that libraries should be avoided when it can be composed out of simple handwritten code (eg avoid 10-line libraries, perhaps accept 1k, definitely consider 5k, assuming you’re actually making use of most of it).

Its only when the benefits are significant should you reluctantly accept a framework. But most go the other way — they start with frameworks and reluctantly leave it, not realizing there are distinct and heavy constraints that make the framework so convenient in the first place.

You guys are overcomplicating things. Frameworks generally force you to structure your code a certain way. Both frameworks and libraries provided added functionality so you don't have to code it. A library will not force you to structure your code a certain way.

I also have no idea why I was downvoted, what I previously said is correct. The Werkzeug python library works as a wrapper. Without you declaring a __call__ function it's not going to work. It needs to call your code to wrap it. Any framework ORM's are an example of code you're calling.

> Frameworks are there so you don't have to repeat the work of others... ... but never stop learning about new frameworks.

I hope you see the irony of this.

You might be limiting your point to web frameworks in a single language. Rails gave rise to CakePHP after all...

Even the web frameworks in a single language (e.g. Cake and Symphony) approach web dev in a sightly different way. Reading each is a great way to learn more about the language and how to approach the same problem using strategies.

> Frameworks are there so you don't have to repeat the work of others

You know what else is there so we don't have to repeat the work? Libraries. And they don't take the control of how my code is called from me.

Frameworks are there because except for Lisps language provide little mechanisms to reduce boiler plate so people want to avoid writing boiler-plate to pipe libraries together. However that doesn't have to be the case, take a look at Hunchentoot.

> You know what else is there so we don't have to repeat the work? Libraries. And they don't take the control of how my code is called from me.

Of course they do. Libraries want you to give data in one way, and they return data in another strictly formatted way.

Put a bunch of libraries together, that all know how to talk to each other via convention, and you have a framework.

>Put a bunch of libraries together, that all know how to talk to each other via convention, and you have a framework.

And if that language of communication is the programming language... you have a programming language! (Eg using stdlib types/objects/whatever)

Sure, but if I pass you a struct, having standard naming conventions for those struct elements is really nice. Having a standard way to do callbacks on observables is really nice. If a bunch of components are configured at run time using JSON or XML, having those components all use a similarly formatted markup language is nice.

Looking at web server frameworks, a lot of them boil down to "put things in these directories, use these naming conventions, and if you do the convenience functions we've thrown in will work nicely".

End result, instead of writing my own auth code for every endpoint, I throw some middleware in there and the auth happens for me. It all works because everyone agreed on how a bunch of library components are going to communicate with each other.

Are there some frameworks that are way too opinionated and heavy weight? Sure. When someone tries to make a meta-framework that can be configured to solve all problems (see: The Java ecosystem), horrible nightmares end up being written.

But the rise of small lightweight frameworks that are just an agreed upon glue for how components should work together? Eh, no big complaint.

> Frameworks are there because [...] people want to avoid writing boiler-plate

This really depends on how the framework was designed.

Some frameworks are really good at getting out of the way, and focus primarily on providing a library-like syntax (e.g. Flask for Python) with very little bundling of libraries. You can use a Flask instance inside of a desktop app as a library rather than piping to it Apache requests if you so need.

Larger, more structured frameworks exist for the developer to focus on the business logic and not worry about the context (networking, auth, sec, data store, etc.). They bring together multiple standard libraries that everyone agrees on and bundle them in a context instance the developer can confidently rely on. This, too, is a great tool.

And in LISPs you'd call a framework maybe protocol or driver. Same difference. A high-level "web request dispatching and handling" library will take just as much control over your code no matter how you call it... (See weblocks, clack etc in CL - they all very much limit your code)

I've taken a look and found https://edicl.github.io/hunchentoot/#easy-handlers

Yes, to be fair: hunchentoot is a webserver in CL, the "easy handler framework" is one option how to use it and I have never seen it in production - it is a convenient way to get started.

Reading the entire article he states to spend 20% of time on frameworks, libraries, and tools and 80% on "fundamentals". So he isn't against learning frameworks just don't make that the focus of your learning outside of your job because you'll learn the frameworks while trying to do your job.

I don't know about this author's day-to-day, but mine is not in the fundamentals of a language, it's in a framework.

Granted, a JS dev spends her day juggling libraries, but a Ruby dev (a Rails dev?), an iOS dev, an Android dev, etc, spends her entire day writing code for a framework, not a language.

I would even argue that software is 80% libs and frameworks and 20% fundamentals, but I digress.

I build some rather complicated things using Flask. Maybe 5% of total programming time in the last 6+ years has been spent writing code for a framework.

Now, Flask is a microframework, sure. But I see this in other work I do. Perhaps it’s the way I intentionally architect/design to have as little coupling of application with framework, but it’s an exceedingly rare event where I have to bother even thinking about the framework. At most, with a web project, it’s maybe when accessing a request or a session. Otherwise, I don’t write for a framework. I write applications that get a framework-powered web frontend, but all the work is in framework-agnostic code where it belongs.

I don't disagree that you might spend 5% in flask, but you also have auth, you have a data abstraction layer, you have session management, data persistence, tooling, and sec. All those libraries together is called a framework.

I know what a framework is, having been building with a handful of them for more than a decade. That a framework is used to deliver a web-based frontend has no bearing on intentionally designing and building a framework-agnostic backend.

For instance, auth happens via a library that is not Flask. Same for database models and persistence (that’s SQLAlchemy for the models, and a mix of ORM and straight SQL queries for db operations—again, not Flask/framework). This is starting to feel like splitting hairs, though. One of the great benefits of a microframework like Flask is that you get the freedom to design and write application code that ignores the fact that there’s a framework handling the request lifecycle. It makes for better code.

For an example of a non-microframework example, Phoenix takes this approach as well—that Phoenix isn’t your application, it’s just a web layer, and your application should be independent.

Reply on news.ycombinator.com