python开发web框架_选择Web框架：php，python还是node.js？ 开发人员的个人感想。
python开发web框架
Having spent the last 20+ years operating mostly in the CMS universe, the time has come for me to see what else the web development ecosystem has to offer, and what has changed in the recent years. In my half-year journey, searching through the plethora of web pages and fora, going through docs and tutorials to dozens of frameworks, I realised that the issue of "what to choose" for the next project is a problem facing so many developers. So, taking into account that everything I write here is my personal opinion, resulting from a particular time and context, here are my reflections on the choices available.
在过去20多年 的时间里，我 主要在 CMS 领域中工作，现在是时候让我看看Web开发生态系统还可以提供什么，以及最近几年发生了什么变化。 在我的半年旅程中，通过搜索大量的网页和论坛，遍历文档和教程以及数十种框架，我意识到下一个项目的“选择内容”是许多开发人员面临的问题。 因此，考虑到我在这里写的所有内容都是我的个人看法，是由于特定的时间和环境所致，这是我对可用选择的反思。
The rumblings below are not to be read as anything else but my personal opinion on what I found to work for me. I do not intend to suggest what is the best way forward for you - as far as I know, there is no such thing as the best way forward! Creating software is a kind of a divergent task that has many possible paths, and none of them can be objectively called "the best one." One thing I am certain of is that whatever might "look best" today will be outdated and replaced by new tech very soon.
下面的隆隆声不应该被理解为其他任何东西，而是我对我发现对我有用的东西的个人看法。 我无意为您建议最佳的前进方式-据我所知，没有最佳的前进方式！ 创建软件是一种分散的任务，它具有许多可能的途径，而且没有一个可以客观地称为“最佳途径”。 我可以确定的一件事是，今天可能看起来“最好”的一切都将过时并很快被新技术取代。
(
)
框架来去去去 (Frameworks come and go)
I read this phrase on some websites, and it struck me as a very useful observation. There have been so many frameworks in the past, and most of them are today either gone or so obscure that no one bothers to use them. Other frameworks had their great place in history, and are also very much gone - but not forgotten! A couple of frameworks, like jQuery, have been extremely influential on the whole ecosystem of web development tools, and they changed the world. They changed the world, and can now rest in peace and glory! Fewer developers use jQuery, because it changed the javascript so much, that it is not needed anymore in most use cases where it was applied in the past - e.g., to ensure cross-browser compatibility of the front-end code.
我在一些网站上读了这个短语，这使我震惊，这是一个非常有用的观察。 过去有这么多框架，而今天大多数框架已经消失或模糊不清，以至于没人愿意使用它们。 其他框架在历史上占有重要的地位，也已不复存在-但并不被遗忘！ jQuery之 类的两个框架 对Web开发工具的整个生态系统都具有极大的影响力，它们改变了世界。 他们改变了世界，现在可以安息与荣耀！ 更少的开发人员使用jQuery，因为它对JavaScript的更改如此之大，以至于在过去使用它的大多数用例中，不再需要它-例如，以确保前端代码的跨浏览器兼容性。
Another aspect to the "coming and going" of the frameworks is that if your project is expected to live for several years, you may not necessarily want to experiment with newly discovered gems, no matter how shiny! In our world, not just digital, a simple rule seems to work almost every time: an older, more mature product (or service) has a better chance of surviving another day, than a younger product. Of course, only until the next technological disruption takes place, and makes that product obscure. For me, the conclusion was to put more weight towards the older tech stack - and in the universe of three kings: Python, PHP, and JS, for the server-side PHP is a clear winner in that category. People may say "PHP is dead," but my objective observation is that over 80% of all websites are powered by PHP. Not bad for a "dead" language. Node.js, while certainly a rising star, is the youngest one, and only time will tell if 10-20 years from now it will match the survival rate of PHP.
框架“来来去去”的另一个方面是，如果您的项目预期寿命数年，那么无论多么闪亮，您都不一定要尝试新发现的宝石！ 在我们的世界中，不仅仅是数字世界，一条简单的规则似乎几乎每次都能奏效：较老的，更成熟的产品（或服务）比较年轻的产品有更好的生存机会。 当然，只有在下一次技术破坏发生之前，该产品才变得晦涩难懂。 对我而言，结论是将更多的精力放在较旧的技术堆栈上-并且在三大类之王中： Python ， PHP 和 JS ，因为服务器端PHP显然是该类别的赢家。 人们可能会说“ PHP已经死了”，但是我的客观观察是，所有网站中有80％以上是由PHP驱动的。 对于“死”语言来说还不错。 Node.js 虽然肯定是一颗冉冉升起的新星，但它却是最年轻的，只有时间才能证明从现在起10到20年后它是否会符合PHP的生存率。
Another aspect of framework popularity is the size of the community (i.e., how easily you can get help? How many people before you stumbled onto a similar problem and asked for a solution on a Stack Overflow? Interestingly, there seems to be a correlation between how popular a framework is and how well it is documented.
框架受欢迎程度的另一个方面是社区的规模（即，您获得帮助的难易程度？在偶然发现类似问题并寻求堆栈溢出解决方案之前有多少人？有趣的是，两者之间似乎存在相关性框架的受欢迎程度以及文档的完善程度。
前端 (Front-end)
When it comes to front-end, you have just two basic choices: generate your pages on the server-side, or use full-blown JS engine to run your front-end. You may want to choose some full-stack JS solutions like Meteor. However, you should be aware that the creators of Meteor have pretty much abandoned it's further development, focusing on GraphQL for the last couple of years. Since October 2019 Meteor has a new home, where it may start growing again. You may also consider approaches like Vue+Nuxt or Vue+Quasar, which support SSR (server-side rendering), but these, in fact, trick you into setting up a back-end node.js server, while claiming to be front-end solutions. To me, it meant that they the SSR solutions employing tricks like hydration of the content, and client-side takeover, are useful mostly if you plan to use JS for your back-end development.
对于前端，您只有两个基本选择：在服务器端生成页面，或使用成熟的JS引擎运行前端。 您可能想要选择一些像Meteor这样的全栈JS解决方案。 但是，您应该意识到，Meteor的创建者已经放弃了它的进一步开发，而在过去的几年中一直专注于GraphQL。 自2019年10月以来，流星有 一个新家 ，它可能会再次开始增长。 您可能还会考虑 支持SSR（服务器端渲染）的 Vue + Nuxt 或Vue + Quasar之 类的方法 ，但实际上，这些方法会欺骗您设置后端node.js服务器，同时声称自己是前端的解决方案。 对我来说，这意味着如果您计划使用JS进行后端开发，那么使用诸如内容混合和客户端接管之类的技巧的SSR解决方案就非常有用。
Realistically, it is not possible to escape JS in the frontend these days, e.g., for reactivity, animation, and ajax calls. All one has to choose is one of the available toolset ecosystems, e.g., jQuery, Angular, React, Vue, etc. My personal choice was Vue, but only because I found it easiest to learn and most pleasant to use.
实际上，这些天不可能在前端逃脱JS，例如，用于响应性，动画和Ajax调用。 所有需要选择的就是可用的工具集生态系统之一，例如jQuery，Angular，React，Vue等。我的个人选择是Vue，但这只是因为我发现它最容易学习并且使用起来最愉快。
As of the beginning of 2020, a new approach is gaining popularity - server-fetched partials. A technique used e.g., on GitHub site, uses ajax calls to dynamically replace parts of the page with new content. As a result, the page is both dynamic, replacing only part of the page content with each update, and at the same time, server-side rendered.
截至2020年初，一种新方法越来越流行- 服务器获取的偏件 。 例如，在GitHub站点上使用的一种技术使用ajax调用来用新内容动态替换页面的某些部分。 结果，页面既是动态的，则每次更新仅替换页面内容的一部分，并且同时在服务器端呈现。
前端--dev工具 (Front-end --dev tools)
In the old days, you could just code your CSS and JS, include it in the head of the HTML page, and push it to deployment. Not any more. With tools like webpack available to the developer, even if you use a non-js stack for your backend, you may not be able to escape the necessity of using a bit of node.js tooling for pre-processing your stylesheets and scripts. If you want your assets compiled, scripts minified, and optimised for fastest page loading (e.g., using code-splitting techniques), as of today, you may need to include some node.js-based tools to ensure smooth compilation of your assets. Some non-js frameworks include a simple set of tools to assist you with this - e.g., PHP's Laravel includes Laravel-Mix which installs all required node modules for you.
在过去，您只需编写CSS和JS的代码，然后将其包含在HTML页面的顶部，然后将其推送到部署中即可。 不再。 使用开发 人员 可用的 webpack之类的 工具 ，即使您在后端使用非js堆栈，您也可能无法摆脱使用一些node.js工具预处理样式表和脚本的必要性。 从今天开始，如果您希望对资产进行编译，对脚本进行最小化和优化以实现最快的页面加载（例如，使用代码拆分技术），则可能需要包括一些基于node.js的工具以确保资产的顺利编译。 一些非js框架包括一组简单的工具来帮助您解决此问题-例如，PHP的 Laravel 包含 Laravel-Mix ，该 工具为您 安装了所有必需的节点模块。
后端 (Back-end)
First of all, I decided to skip Ruby and Java in my search for the next framework to use. Why? Ruby - because it is still a niche solution, after so many years, so I do not expect it to suddenly gain popularity. Java - because, (a) from my experience many years ago, Java typically usually requires more lines to achieve the same solution compared to Python/PHP/JS, but most of all, because there is no big choice of cheap java hosting out there. Granted, there are some options, but most likely, you'd have to go with a VPS - and for me, it was not a preferred choice.
首先，我决定 在寻找下一个要使用的框架时 跳过 Ruby 和 Java 。 为什么？ Ruby-因为经过了很多年，它仍然是一个小众的解决方案，所以我不希望它突然流行起来。 Java-因为（a）根据我多年前的经验，与Python / PHP / JS相比，Java通常通常需要更多的代码来实现相同的解决方案，但是最重要的是，因为那里没有廉价的Java托管的大选择。 当然，有一些选择，但是最有可能的是，您必须使用VPS-对我来说，这不是首选。
So, three kings left on the stage: Python, PHP, Node (JS).
因此，舞台上剩下了三个国王：Python，PHP，Node（JS）。
Initially, I wanted to drop the PHP from the list - it was supposed to be dead, right? I also despised the fact that a typical PHP app is not a long-running process; it re-starts from scratch for every single request - not very optimal, right? That's why JS solutions looked so advantageous in tests measuring how many "Hello world" requests per second you can squeeze out of your app.
最初，我想从列表中删除PHP-它 应该已经死了 ，对吧？ 我还鄙视了一个典型PHP应用程序运行时间不长的事实； 它会针对每个请求从头开始重新启动-并不是非常理想，对吧？ 这就是为什么JS解决方案在测试每秒可以挤出您的应用程序多少“ Hello world”请求的测试中如此优势的原因。
Given that I spent a couple of years focusing on data science, Python looked like a decent choice to me. Sadly, it was an alien body to pretty much all other developers I cooperated with. And it did not work that easily with front-end frameworks like Vue (e.g., Flask Jinja templating system had a conflict using {{ syntax }}). In fact, I was not able to find that many pros of using Python against using Node.js. The only exception was when the application used a lot of data analysis or machine learning tools, like sci-kit, pandas, etc. - then Python would be my first choice.
考虑到我花了几年时间专注于数据科学，Python对我来说似乎是一个不错的选择。 可悲的是，对于我与之合作的几乎所有其他开发人员来说，这都是一个陌生的机构。 而且，对于像Vue这样的前端框架，它也不容易工作（例如， Flask Jinja模板系统在使用{{语法}}时发生冲突）。 实际上，我找不到使用Python而不使用Node.js的许多专家。 唯一的例外是，当应用程序使用大量数据分析或机器学习工具（例如sci-kit，pandas等）时，那么Python将是我的首选。
Then I turned my search towards Node.js universe. I studied Feathers, Sails, Strapi, plain Express & Koa, Meteor. All in all, I decided to give Strapi and Feathers a solid try. I liked them both until I stumbled onto three issues that actually made me turn away from Node.js:
然后，我将搜索转向Node.js Universe。 我学习了 羽毛 ， 帆 ， Strapi ，普通 Express ＆ Koa ， 流星 。 总之，我决定尝试Strapi and Feathers。 我都喜欢它们，直到我偶然发现了三个实际上使我远离Node.js的问题：
- The size of the node_modules folder. It's like a black hole! An empty app scaffolding takes anything between 200 Mb and 0.5Gb. And once you start adding modules to do this and that... enormous, and without a really good justification! Moreover, once you try to deploy the app, most of these modules go onto the target server, too - effectively, I would have to reserve at least 1-2 Gb per application, no matter how tiny! I did perceive it as a problem, given that on a shared server I was able to host 10+ PHP/CMS sites. So, costs would actually go up, rather than down, and I'd have to purchase many more. node_modules文件夹的大小。 就像一个黑洞！ 空的应用程序支架需要200 Mb和0.5Gb之间的任何空间。 一旦您开始添加模块来完成此任务，那……就很大了，而且没有充分的理由！ 而且，一旦您尝试部署该应用程序，这些模块中的大多数模块也都将进入目标服务器-实际上，无论多么微小，我都必须为每个应用程序至少保留1-2 Gb！ 考虑到在共享服务器上我能够托管10个以上PHP / CMS网站，我确实认为这是一个问题。 因此，成本实际上会上升而不是下降，而且我不得不购买更多的东西。
- The complexity of deployment. Ok, I admit, I'm lazy - but going through the steps to deploy a Strapi or a Feathers app, got me rather discouraged. I do tend to use web tools on an ad-hoc basis, rather than for huge projects, which you deploy very rarely and then only maintain. In my particular setup (and I realise I'm quite atypical here), when I expect to deploy 10+ small apps each year, it was a strong argument against choosing this path. 部署的复杂性。 好的，我承认，我很懒惰-但是逐步执行部署Strapi或Feathers应用程序的步骤令我颇为灰心。 我确实倾向于临时使用Web工具，而不是用于大型项目，因为这些项目很少部署，然后只能维护。 在我的特定设置中（并且我意识到我在这里非常不典型），当我期望每年部署10个以上的小型应用程序时，强烈反对选择这种方式。
- Most of my current stack is PHP+CMS. I had to create a number of additional, small tools dedicated to special support tasks (which is the main reason I started the whole research of the web frameworks), so mixing it with either Node.js or Python was a bit more difficult than adding another PHP tool to the stack. 我当前的大部分堆栈都是PHP + CMS。 我必须创建一些专用于特殊支持任务的其他小型工具（这是我开始整个Web框架研究的主要原因），因此将其与Node.js或Python混合要比添加多一点。另一个PHP工具。
Following a number of conversations, I turned again towards PHP. Here, my choice seemed to be easy: go for Yii, Symfony, or Laravel. I dropped Yii as the less popular one. Then I got stuck with a choice of Symfony vs Laravel. Symfony is smaller, which I liked - a scaffolding of a basic app with authentication was about half the size of Laravel, and about one-tenth (!) the size of most Node.js frameworks. Well, almost... I soon realised that to use Laravel Mix, I have to download the Node.js stack as well - but at least it stays on the dev end, absent in the production environments.
经过多次交谈，我再次转向PHP。 在这里，我的选择似乎很容易：选择 Yii ， Symfony 或 Laravel 。 我放弃了Yii，使其不再那么受欢迎。 然后我选择了Symfony和Laravel。 Symfony较小，我喜欢-带有身份验证的基本应用程序的机架大约是Laravel的一半，大约是大多数Node.js框架的十分之一（！）。 好吧，差不多...我很快意识到，要使用Laravel Mix，我也必须下载Node.js堆栈-但至少它留在开发人员端，而在生产环境中却没有。
Based on the data available online, Symfony is supposed to be less popular than Laravel. However, that turned out to be huge misinformation. Why? Because Laravel uses Symfony! So, quite naturally, frameworks and CMS systems like Laravel, Drupal, Joomla, which use Symfony, actually should be added to the numbers describing the popularity of Symfony. Furthermore, Symfony got me with its documentation - the best one I have seen for any framework. With a massive library of videos, and each of the videos with full transcription.
根据在线可用数据，Symfony应该不如Laravel受欢迎。 然而，事实证明这是巨大的错误信息。 为什么？ 因为Laravel使用Symfony！ 因此，很自然地，使用Symfony的Laravel，Drupal，Joomla等框架和CMS系统实际上应该添加到描述Symfony受欢迎程度的数字中。 此外，Symfony还为我提供了其文档-这是我所见过的关于任何框架的最佳文档。 拥有庞大的视频库，并且每个视频都有完整的转录本。
Surprise-surprise, in the end, I decided to go with Laravel. After a bit of further research, and after getting through a couple of tutorials for both frameworks, this article helped me make my decision: PHP Frameworks: Choosing Between Symfony and Laravel
最后，我决定和Laravel一起去。 经过进一步的研究，并通过了两个框架的一些教程后，本文帮助我做出了以下决定： PHP框架：在Symfony和Laravel之间进行选择
And the rationale was very personal and very subjective - Laravel works well with Vue.js (which I chose as my front-end framework), and it requires less code to achieve each of the typical core tasks, compared to Symfony. And, as I already told you, I'm lazy - so that made my choice ;-)
而且其理由非常个人化且非常主观-Laravel与Vue.js（我选择作为我的前端框架）配合得很好，并且与Symfony相比，它需要更少的代码来完成每个典型的核心任务。 而且，正如我已经告诉您的那样，我很懒惰-因此，我做出了选择;-)
Ed: To learn more about the author, please visit his Experts Exchange Profile Page.
埃德：要了解有关作者的更多信息，请访问其 专家交流资料页面 。
python开发web框架