Todo-MVP：或者“为什么你不应该使用 Web 框架” - 复仇

Todo-MVP

今年早些时候我写道：

为什么你不应该使用 Web 框架

David Wickes · 2018年7月26日

#webdev #framework #beginners #react

这引起了一些骚动。我想，用“褒贬不一，但充满激情”来形容大家的反应或许更礼貌一些。

因此，点燃蜡烛总比诅咒黑暗要好，我想介绍一个我一直在进行的小项目，名为Todo-MVP，以此来展示我的一些想法。 咆哮谈论过。

但首先，我将回顾一下原始帖子，并尝试回应一些更常见的批评^。1

礼貌回顾

我认为 Web 框架会给项目带来一些额外的复杂性，将控制权从使用框架的开发者手中夺走，交给编写框架的人。因此，我们被迫采用特定的应用程序架构和配置方式，而这些方式可能并不适合我们的需求或目的。在项目开始时，我们可能意识不到这一点，但等到意识到这一点时，我们就会深深地“嵌入”在框架的体系中，很难做出必要的更改。

更严重的是，对框架的依赖会形成一种恶性循环；当我们缺乏从简单的库构建 Web 应用程序的技能时，我们就会转向使用框架来构建我们的网站，而当这不可避免地以某种方式让我们失望时，我们就会寻找另一个同样不合适的框架^。2

一个特别令人震惊的例子是使用前端 JavaScript 框架来呈现纯 HTML 内容，而这些内容可以轻松地托管在静态站点服务器上。

最后，“框架优先”的思维模式吓得人们不敢尝试编写没有框架的应用程序——他们自然而然地认为这一定很难，因为如果不是这样，那么一开始就不会有框架了。这并非事实。理解和使用一组编写良好的库来构建应用程序与使用框架一样容易，而且你不会让自己面临上面列出的问题^。3

回应批评

有些人似乎认为我想用 C 语言或汇编语言编写所有代码。不，虽然这可能很有趣，但从时间角度来看效率可能不高。4^我的问题主要在于框架。一个好的框架定义可能是：

你调用库的代码，框架调用你的代码。

如果您想了解更多细节，请阅读Stack Overflow 上的这个问题。不过，如果您还没猜到的话，在我看来，库（大多数情况下）都是好东西。所以——使用库（最好是那些具有良好抽象的库），避免使用框架。

另一些人声称，如果不使用框架，他们“最终会自己构建一个框架”。这种情况不太可能发生，除非他们想要优化以生成多个具有相同结构的应用程序。你不会“构建一个框架”。

您将构建的只是最初尝试构建的应用程序，仅此而已。如果您做得正确，它将足够灵活，可以在未来进行更改和扩展。

在这次演讲中，Adrian Holovaty 的表达比我更好——他的演讲流利、有礼貌，而且爵士吉他弹得更好：

Todo-MVP

因此，为了证明我的真知灼见，我写下了以下文字：

这是我对TodoMVC理念的看法，但我没有使用各种前端框架来构建 Todo 应用程序，而是尝试使用用不同语言编写的各种 Web 服务器来实现。

它们都实现了相同的 API，使用 HTTP 网络调用来控制应用程序。并且它们都渲染相同的 HTML 元素，并且可以使用相同的 CSS 进行样式设置。

我在这里试图证明，你不需要框架- 你几乎不需要任何库 - 来构建一些可行、可用且你可以理解并反复构建的东西。

这个想法并不是要构建一个完整的应用程序 - 在现实生活中，你会想要提供一些持久性（比如数据库）、单独的用户会话、身份、授权......我很乐意在这个例子中跳过所有这些，但根据你的需要实现它们应该并不困难^。5

可以在todo-mvp.com找到其中一个实现的运行实例。

Todo-MVP 需要你

是的，就是你！

请帮帮我！你能不能花点时间，用你选择的语言构建一个简单的实现？即使别人已经用你喜欢的语言实现了，你也可以再做一次，但要演示不同的库、不同的方法——如果你想演示它是如何工作的，甚至可以使用框架。

阅读贡献指南，编写实现，运行验收测试并获取拉取请求。

另外——所有东西都有改进的空间！如果你有才华，欢迎写一些精彩的 CSS，帮我发现并修复可访问性问题，或者帮我写一些文档……

有太多事要做😉

1. 你真的应该读一读原来的评论和批评——其中一些是喜剧黄金（以一种好的方式！）。  ↩

2. 这也导致了在架构模式方面出现群体思维（框架思维）。你的应用程序可能不太适合 MVC RESTful CRUD 应用程序，但你很可能需要使用框架来构建这样的应用程序 。↩

3. 框架的真正意义或许在于强制你遵循项目结构和架构。如果你真的想要这样，那好吧，尽管去做。但我并不认为这是一个好的价值主张 。↩

4. 但从你的薪水来看，它可能会非常高效——继续向孩子们收费！  ↩

5. 或者使用外部服务——IDaaS 越来越受欢迎 。↩