惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

F
Fox-IT International blog
Recent Announcements
Recent Announcements
D
Docker
IT之家
IT之家
B
Blog
Jina AI
Jina AI
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
博客园 - 【当耐特】
Google DeepMind News
Google DeepMind News
F
Fortinet All Blogs
量子位
C
Check Point Blog
Microsoft Azure Blog
Microsoft Azure Blog
罗磊的独立博客
博客园 - 司徒正美
李成银的技术随笔
美团技术团队
Blog — PlanetScale
Blog — PlanetScale
雷峰网
雷峰网
The GitHub Blog
The GitHub Blog
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
J
Java Code Geeks
T
The Blog of Author Tim Ferriss
酷 壳 – CoolShell
酷 壳 – CoolShell
MongoDB | Blog
MongoDB | Blog
P
Proofpoint News Feed
L
LangChain Blog
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
Y
Y Combinator Blog
大猫的无限游戏
大猫的无限游戏
有赞技术团队
有赞技术团队
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
V
Visual Studio Blog
T
Tailwind CSS Blog
H
Help Net Security
Engineering at Meta
Engineering at Meta
小众软件
小众软件
B
Blog RSS Feed
Stack Overflow Blog
Stack Overflow Blog
月光博客
月光博客
M
Microsoft Research Blog - Microsoft Research
宝玉的分享
宝玉的分享
人人都是产品经理
人人都是产品经理
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
GbyAI
GbyAI
H
Hackread – Cybersecurity News, Data Breaches, AI and More
Last Week in AI
Last Week in AI
Martin Fowler
Martin Fowler
Stack Overflow Blog
Stack Overflow Blog

Secret Weblog

Becoming More Xee: A Modern XPath and XSLT Engine in Rust Looking for new challenges! Repeat Yourself, A Bit The Curious Case of Quentell The Humble For Loop in Rust The Humble For Loop in JavaScript Don't Look Down on Print Debugging Question Best Practices I Was a 1980s Teenage Programmer Part 5: Achieving Assembly I Was a 1980s Teenage Programmer Part 4: The Call of Assembly The Tooling Shift I Was a 1980s Teenage Programmer Part 3: MSX-2 JavaScript: when you need two ways to do it! Empowering Programming Languages Bloat and Retrofuturism Refreshing my Blog Again Random Rust Impressions Apilar: An Alife System I Was a 1980s Teenage Programmer Part 2: Olivetti M24 I Was a 1980s Teenage Programmer: the Alphatronic SolidJS fits my brain Is premature optimization the root of all evil? Framework Patterns: JavaScript edition Roll Your Own Frameworks Looking for new challenges Framework Patterns Secret Weblog Highlights Refactoring to Multiple Exit Points mstform: a form library for mobx-state-tree Seven Years: A Very Personal History of the Web Looking for new challenges Morepath 0.16 released! Is Morepath Fast Yet? Introducing Bob Strongpinion Punctuated Equilibrium in Software Morepath 0.15 released! Impressions of React Europe 2016 Morepath 0.14 released! Morepath 0.13 now with Dectate Dectate: advanced configuration for Python code JavaScript Dependencies Revisited: An Example Project The Incredible Drifting Cyber A Brief History of Reselect The Emerging GraphQL Python stack Thoughts about React Europe Build a better batching UI with Morepath and Jinja2 GraphQL and REST Server Templating in Morepath 0.10 10 reasons to check out the Morepath web framework in 2015 A Review of the Web and how Morepath fits in Morepath 0.9 released! Better REST with Morepath 0.8 Morepath 0.7: new inter-app linking They say something I don't like so they must be lying! Life at the Boundaries: Conversion and Validation BowerStatic 0.4 released! Morepath 0.6 released! Morepath 0.5(.1) and friends released! New HTTP 1.1 RFCs versus WSGI Against On Naming In Open Source My visit to EuroPython 2014 Morepath 0.4.1 released (with Python 3 fixes) Morepath 0.4 and breaking changes Announcing BowerStatic Morepath 0.3 released! Morepath 0.2 Morepath Python 3 support The Call of Python 2.8 Morepath 0.1 released! WebOb and Werkzeug compared Morepath: from Werkzeug to WebOb Racing the Morepath: SQLAlchemy Integration The Centre Cannot Hold Breaking Morepath Changes Morepath Update How to do REST with Morepath Morepath Security the Gravity of Python 2 #python2.8 discussion channel on freenode Alex Gaynor on Python 3 Morepath Documentation Starting to Take Shape Back to the Center Morepath App Reuse Implementing Grok Grok: the Idea Why Linux Works for Me On the Morepath Reg, Now With More Generic! The New Zope as a Web Framework Jim Fulton, Zope Architect Renewing Zope Object Publishing The Weirdness of Zope The Rise of Zope My Exit from Zope Reg: Component Architecture Reimagined JSConf EU 2013 impressions Obviel 1.0!
web frameworks considered useful
Martijn Faassen · 2010-04-15 · via Secret Weblog

There is a a strain of thought in the Python web development community these days that considers web frameworks a bad idea. Even beginners are sometimes told: why do you need a framework anyway? Just build your app from scratch with WSGI! Or just compose your own out of existing libraries and tools!

I'm going to argue that frameworks are useful. I'm going to argue that we should normally not be telling beginners to avoid frameworks. And I'm going to argue that experienced developers should carefully consider whether their perspective isn't warped a little by their experience, and that frameworks can be useful for them too.

Frameworks get in your way

I want to do something that should be simple, and would be simple if I just did it at a low level. But because the framework forces a certain way of working on me, it becomes needlessly difficult. I have to create workarounds, and it sucks.

Frameworks can get into your way, as they've made certain choices. How much they are constraining depends on the framework, your experience with it, and what you're trying to accomplish.

But if you picked the right framework for the job, regularly the task you're trying to perform is something that a framework makes very easy. The first time around you use a framework for something that it is good at, you're going to be impressed at how easy it was to accomplish your task. Before long however, you might become so used to the benefits that a framework brings that you won't even notice what the framework is doing for you anymore; it's now in the background. And humans are very attuned to pain, so the pain points are going to remain. You're going to remember the ugly workarounds better than the times when things just worked.

I think frameworks get in the way for beginners less than they do for experienced developers. Beginners need to learn the basics, and having a framework can be a useful guide to gain an understanding of the basics and how they go together. An experienced developer will understand all that already, and is more likely to work on more challenging projects where the choices that the framework made are not the right ones. But does that mean that the framework is wrong for all tasks, and that we should tell a beginner not to use them at all? And does it really mean that experienced developers shouldn't use frameworks at all anymore, either? What about those tasks where the pain is minimal? And what if you are working in a group that includes beginners? And may it be that your time is more productively spent improving the framework to make the pain go away, instead of avoiding it entirely?

Building from scratch feels more productive

A developer might argue to the last point: no, I am a lot more productive if I build something from scratch, and list a whole range of things they've built up in a short amount of time.

And of course building something from scratch can feel very liberating, and sometimes it is the right way to go. But frequently you will only feel more productive - if you're spending time to reimplement the features of the framework you discarded, you might be productive in implementing those features, but what about the task you're actually trying to accomplish? What about the web app you're trying to build? And how much code that only you understand will you end up trying to maintain?

There are cases where you may feel a lot more productive, because you're having more fun, when you actually aren't. We all know programmers like to reinvent wheels. Reusing existing code may be more painful, but it isn't necessarily less productive, although of course it can be.

And seriously, do we really think beginners without much experience of frameworks have enough knowledge to be able to build their web apps from scratch and do it well?

Don't use a framework, just reuse existing building blocks

Lots of people would agree with me that building things from scratch is not the way to go. But, they'll argue, people can just assemble the components they need for their application themselves, instead of using a framework.

And it's true: there are a lot of building blocks available these days, and that's good. There are libraries and middleware and components and so on to do everything from interfacing with a web server to talking to a database. Instead of picking a ready-made pre-assembled framework, you can instead pick and choose the best of breed components that are out there and use those to develop your application. Since you are doing it, it may be better suited to your requirements than any pre-assembled framework can offer. You'll understand it better too.

I believe there is a lot of value in this approach. The Python web development world has been moving in this direction for a while; there's the emphasis on WSGI, and there is the emphasis on easily distributing and combining libraries. I'll note that the Python web framework development has been moving in this direction too, because web framework developers are also aware of the benefit of sharing useful components with each other.

But does this mean we should recommend to everyone all the time to just ignore frameworks and assemble the bits themselves? No.

The obvious case where this is a bad idea is in the case of beginners. A beginner will have little understanding of how components can go together. A beginner will have no way to evaluate components. A beginner is usually much better off to use a pre-assembled framework where these choices have already been made. The beginner can find information in a one-stop shop: they'll learn about the template language and the approach to databases of the framework in one place, and they'll see not just descriptions of the bits and pieces but also how they go together. This means that they won't have to do this integration themselves anymore; they'll see examples. There's also a community where they can ask questions.

These reasons for a beginner to use a pre-assembled framework also frequently apply to more experienced developers. You don't always have time to go out and assemble components together, and figure out how to make it work. Sure, what you might end up with might be slightly better suited to a particular task than a pre-assembled framework, but is it really always worth the effort? Do you really want to make all those choices each time, for each app you build? And you'll still be stuck with the maintenance burden - the glue code you wrote of course, but also the assembly itself: what if there are newer releases of the components you are using?

Finally, these smaller components are often quite complex frameworks too - and if you integrate them yourself there might be less unity of vision than a good framework can offer, and the whole might end up harder to understand.

The burden of assembling and integrating best of breed components can be shared: that's what the developers of a framework do. And if you base your work on a pre-assembled framework, it's likely to be less work for you to upgrade, because the framework developers will have taken care that the components in the framework work together in newer versions. There is also a larger chance that people will write extensions and documentation for the this same assembly, and that is very likely something you may benefit from in the future.

So it often makes sense to share the assembling and integration of components in an open source fashion just like it makes sense to share the components themselves. An assembly is not just a collection of loose parts, it can be a new thing, with a vision of it own.

Conclusion

All the points above are true: frameworks can get into your way, using a framework (especially when wrestling with it) can feel less productive than building something new from scratch, and reusing components yourself is often more flexible.

But frameworks can also take care of a lot of issues for you, even though after a while you only feel it when they are in the way. Frameworks make choices for you so you don't have to make them all the time. Frameworks can save time. Frameworks offer an integrated whole so you won't have to worry about the rest of the world for a while. Good frameworks will also be flexible enough to handle a huge amount of tasks more than adequately.

So, there is a place for web frameworks. It makes sense to recommend web frameworks to beginners. It also makes sense for experienced developers to consider using a web framework. It's not always the right tool for the job, but it often is. By all means let's discuss the particular pain points of frameworks, doing things without a framework and assembling components yourself. But let's not forget the benefits that web frameworks bring to many of us.