用户堆栈 内核堆栈_使用无聊的堆栈的优点

用户堆栈 内核堆栈

A person asked me a question a few days ago. The person wanted to start a blog, and they decided to write their own platform for it, using Angular in the frontend.

几天前有人问我一个问题。 该人想创建一个博客，他们决定使用前端的Angular为其编写自己的平台。

My reply was that if the goal was blogging, then they had to scratch that idea, and use an off the shelf solution.

我的回答是，如果目标是写博客，那么他们必须放弃这个想法，并使用现成的解决方案。

That must have been badly received, as I didn’t get a reply, but my point is this: if you want to create a blog and be serious at it, then use the most boring and bulletproof thing you can find. Definitely don’t work on your blog infrastructure if you want to do any serious blogging.

那一定是很不受欢迎的，因为我没有得到回复，但是我的意思是：如果您想创建一个博客并认真对待它，那么请使用您能找到的最无聊和最防弹的东西。 如果您想进行任何认真的博客开发，绝对不能在您的博客基础结构上工作 。

The tech must go out of the way, you should only focus on the content.

科技必须走开 ，您应该只关注内容 。

Otherwise you’ll spend most of your free time tweaking the blog platform (which - let’s be clear - no one except you cares about) instead of writing content. No one cares about that infrastructure.

否则，您将花费大部分的空闲时间来调整博客平台(我们很清楚- 除了您所关心的人，没有其他人 )，而不是编写内容。 没有人关心这种基础设施。

If you want to make a video, are you going to write a YouTube clone first? Can it handle 100M simultaneous visitors? Reminds me of people wanting to write video games and starting to build a physics engine first, never ending the game in the process.

如果要制作视频，是否要先编写YouTube克隆文件？ 它可以同时接待1亿游客吗？ 让我想起了一些人，他们希望编写视频游戏并首先开始构建物理引擎，但从未停止过该过程。

I use Hugo, a static site generator.

我使用的是静态网站生成器Hugo。

Hugo is the best one for me as it’s focused on blogging and markdown. It is boring. Its templating language is boring. It’s so boring that when I have to tweak something I fall asleep. I love it.

Hugo对我来说是最好的，因为它专注于博客和降价促销。 真无聊 。 它的模板语言很无聊。 太无聊了，以至于当我不得不调整某些东西时我就睡着了。 我喜欢它。

The best feature of Hugo is that it’s fast, I think mostly thanks to the use of Go under the hoods. Looks like a boring feature these days.

雨果(Hugo)的最大特点是速度快 ，我认为这主要归功于引擎盖下Go的使用。 这些天看起来像无聊的功能。

“Look at Gatsby, it’s so fancy and shiny!”

“看看盖茨比，它是如此奇特而有光泽！”

Gatsby (just used as an example, nothing against it) is already too much fancy for my taste, even though it’s a great tech. Why? It makes you focus too much on the tech and less on the outcome. As a developer, you might feel that is awesome, but it’s not. React, GraphQL, it’s all a bit too exciting.

盖茨比 (仅用作示例，没有什么反对)对我来说已经太花哨了，尽管它是一项很棒的技术。 为什么？ 它使您过多地关注技术而不是结果。 作为开发人员，您可能会觉得很棒，但事实并非如此。 React，GraphQL，这太令人兴奋了。

It reminds me of Redux, and people excited about the demo with “time travel”, a really useful feature for day to day coding [end of joke]. People happily overcomplicated their apps just to use a shiny tech.

它让我想起了Redux ，人们对“时光旅行”的演示感到兴奋，这是对日常编码[笑话结束]真正有用的功能。 人们只是为了使用闪亮的技术而使应用程序过于复杂。

Let’s talk about prefetching for example. Do we really need prefetching when a static site is already as fast as possible? Are our blog visitors asking for it? What are the cons? What can go wrong?

让我们谈谈例如预取。 当静态站点已经尽可能快时，我们真的需要预取吗？ 我们的博客访问者是否要求它？ 缺点是什么？ 有什么问题吗？

Remember Murphy’s law: “Anything that can go wrong will go wrong”

记住墨菲定律：“任何可能出错的地方都会出错”

I once talked to a person that started a blog using Gatsby only to realize they didn’t enable server side rendering, even though they though they had it enabled, which made the blog nearly invisible to Google (yes I know they execute JS sometimes, but bear with me, stick to boring server side rendering).

我曾经与一个使用Gatsby创建博客的人交谈，只是意识到他们即使启用了服务器端渲染也没有启用服务器端渲染，这使该博客对Google几乎不可见(是的，我知道他们有时执行JS，但请忍受， 坚持无聊的服务器端渲染 )。

In an average blog, you get an average of 1.1 / 1.2 page view per user. This means the vast majority of your users are going to come to your site, probably via Google, take a quick look and go away. Do you really need to prefetch all your links? Why waste all that data and power?

在一个普通的博客中，每个用户的平均页面浏览量为1.1 / 1.2。 这意味着您的绝大多数用户可能会通过Google进入您的网站，然后快速浏览并离开。 您真的需要预取所有链接吗？ 为什么要浪费所有这些数据和电力？

Let’s stop going against Gatsby, I really like it as a tool to make websites and apps.

让我们停止反对盖茨比，我真的很喜欢它作为制作网站和应用程序的工具。

My point was that to start a simple blog, you don’t need probably 80% of what it does. Use a simpler tool, a tool made just for blogging, and definitely don’t write your own.

我的观点是，创建一个简单的博客可能不需要80％的工作。 使用更简单的工具，该工具仅用于撰写博客，并且绝对不要自己编写。

This applies to more complex applications. Should you use the technology you know since 10 years, or should you jump on that cool tech you know nothing about, but everyone talks nicely about? Should you use Rails, or Elixir? Should I write my next app in TypeScript or Reason? C, Go or Rust?

这适用于更复杂的应用程序。 您应该使用已经使用了10年的技术，还是应该跳起一无所知的酷技术，但是每个人都很好地谈论？ 您应该使用Rails还是Elixir？ 我应该用TypeScript还是Reason编写下一个应用程序？ C，去还是生锈？

Lots and lots of man hours are lost forever as we collectively jump from old library to new library and from old framework to new framework. Think jQuery, Backbone and Ember, plus all the gazillions ones that came before or after them. Think AngularJS vs Angular. Think all the PHP frameworks that came before Laravel took the PHP world by storm. Remember the NoSQL “revolution” that made us all reconsider using MySQL in favor of fancier and more flexible database systems? Turns out SQL is still going strong.

随着我们集体从旧图书馆过渡到新图书馆，从旧框架过渡到新框架，很多时间都浪费了。 想想jQuery，Backbone和Ember，以及之前或之后的所有专精。 想想AngularJS与Angular。 想一想Laravel席卷PHP世界之前的所有PHP框架。 还记得NoSQL的“革命”使我们所有人重新考虑使用MySQL来支持更高级，更灵活的数据库系统吗？ 事实证明，SQL仍然很强大。

“Just use MySQL, the boring tech revolution is here” Marty Weiner, Reddit CTO, 2016

“只要使用MySQL，无聊的技术革命就在这里”，Reddit CTO Marty Weiner，2016年

Most of the tools that developers consider industry standards are built by huge companies like Google and Facebook and they are perfect for their needs. A small team or solo developer might happen to have the same needs, but is that likely? Or is it all driven by the peer pressure and hype? Or by marketing?

开发人员认为行业标准的大多数工具都是由Google和Facebook等大型公司构建的，非常适合他们的需求。 一个小的团队或一个单独的开发人员可能碰巧有相同的需求，但这可能吗？ 还是全部由同伴的压力和炒作驱动？ 还是通过营销？

Is the thing you want to do perfectly achievable with plain JavaScript and the DOM APIs, or do you really need to rewrite all your application in React and spend days trying to make Webpack do what you want? Sometimes that’s a great choice, sometimes a less than perfect one. Working with the DOM APIs feels boring, but that might make your app much faster, while everyone else in the engineering circle says it’s going to be a mess, you might ship it in 10x less time and it might work 10x better.

您是否想用纯JavaScript和DOM API完美地完成事情，还是真的需要在React中重写所有应用程序并花几天时间尝试使Webpack满足您的要求？ 有时候，这是一个不错的选择，有时候却不是一个完美的选择。 使用DOM API感觉很无聊，但这可能会使您的应用程序更快，而工程界的每个其他人都说这将是一团糟，您可以将其交付时间减少10倍，并且可能将工作时间提高10倍。

One rule is that you know the pitfalls of your platform, the grass is always greener on the other side of the fence, and you like to imagine new platforms being 100% perfect. That never happens, and the devil is in the details.

一个规则是，您知道平台的陷阱，篱笆另一侧的草地总是绿色，并且您想像一下新平台是100％完美的。 那永远不会发生，魔鬼在细节上。

Details that maybe you mastered in years of investing in that stack that now looks boring to you, because you are an engineer! You like challenges! You don’t want to miss out on the opportunity to learn new things!

您可能已经在多年的投资中精通了一些细节，但现在看来对您来说很无聊，因为您是工程师！ 你喜欢挑战！ 您不想错过学习新事物的机会！

You can still do it.

您仍然可以做到。

I think that you should always experiment, create side projects, but when it comes to critical platforms (like your blog platform, that’s critical if you are serious at it), the boring tech is better. And understanding this concept is part of becoming a senior developer.

我认为您应该始终进行试验，创建辅助项目，但是当涉及到关键平台(例如您的博客平台，如果您认真对待它就很关键)时，无聊的技术会更好。 理解这个概念是成为高级开发人员的一部分。

翻译自: https://flaviocopes.com/boring-stack/

用户堆栈 内核堆栈