无题

I finally reconstructed the base functionality of the video player web app I’ve been trying to build, formerly in React, now in Svelte.

最后，我重新构建了我一直试图构建的视频播放器Web应用程序的基本功能，该应用程序以前是在React中，现在是在Svelte中。

It’s been a decent experience so far, given that this is my first attempt trying to build something using the Svelte, but I can’t shake the feeling that it just doesn’t feel quite right in the way that React did. This may very well be simply because I’m not used to it, and after all, the main reason I taught myself React in the first place was because it just didn’t make sense to me.

到目前为止，这是一种不错的体验，因为这是我第一次尝试使用Svelte构建东西，但是我无法撼动这种感觉，就像使用React那样感觉不太正确。 这很可能仅仅是因为我不习惯它，毕竟，我首先自学React的主要原因是因为它对我来说没有意义。

However, while Svelte does make sense to me, it just feels more confusing. I really think it’s that I miss React’s top-down dataflow, among some other things. It was just simpler to conceptualize. Information was always going one way; I could always find the origin of a piece of data in a component, a parent component, or fed to it through a reducer. With Svelte’s bindings and the way it uses stores, it kind of feels like data is just being thrown every which way, which of course is just a matter of perception. But it was easier to conceptualize the flow of data with React, I feel. The dataflow of my Svelte app reminds me of my early Angular apps (and I admit, the fact that I was new to each framework likely has a lot to do with it).

但是，尽管Card.svelte(Svelte)对我来说确实有意义，但感觉更加混乱。 我真的认为，我想念React的自上而下的数据流等等。 概念化起来更简单。 信息总是以一种方式前进。 我总能在组件，父组件中找到一条数据的原点，或者通过化简器将其馈送给它。 有了Svelte的绑定及其使用存储的方式，就好像感觉数据正以任何一种方式被抛出，这当然只是一种感知问题。 我觉得用React概念化数据流更容易。 Svelte应用程序的数据流使我想起了我早期的Angular应用程序(并且我承认，我对每个框架都是陌生的，这可能与它有很大关系)。

Still, while I really miss the philosophy behind React’s dataflow, I also really resonate with the philosophy behind Svelte’s compiler-based approach and lack of virtual DOM. I could technically recreate the one-way dataflow in Svelte but that doesn’t seem idiomatic so I’m going to keep trying to get used to this way first. Things may be better once I’ve internalized it better (and once I learn how to write good Svelte).

尽管如此，虽然我真的很想念React数据流背后的理念，但我也确实与Svelte基于编译器的方法背后的理念以及缺乏虚拟DOM产生了共鸣。 从技术上讲，我可以在Svelte中重新创建单向数据流，但这似乎不是习惯用法，因此我将继续尝试首先习惯这种方式。 一旦将其更好地内部化(并且一旦学习了如何编写出色的Svelte)，事情就会变得更好。

I will say, though, that it hasn’t taken very long for me to run into bugs in Svelte and its tooling. The functionality of my video player app depends on control of the video currentTime, which technically Svelte can bind to. However, I'm getting inconsistent behavior when attempting to update the currentTime while the video is playing (when clicking on a component corresponding to a specific timestamp) and it appears I'm not the only one. The issue was reported as fixed, but it's still showing to be a problem in my Firefox (while mysteriously working fine in Chrome).

我会说，我花了很长时间才遇到Svelte及其工具中的错误。 我的视频播放器应用的功能取决于对视频currentTime控制，从技术上讲，Svelte可以绑定到该视频。 但是，在播放视频时尝试更新currentTime时，我的行为不一致(单击对应于特定时间戳的组件时)，看来我不是唯一的。 据报道，该问题已解决，但在我的Firefox中仍然显示出问题(尽管在Chrome中运行正常)。

Additionally, when I enable lang="ts", it takes issue with me binding to currentTime, saying it should be currenttime. I've just had to disable TypeScript in that component for the moment, which would be much more annoying if I relied more on the language.

另外，当我启用lang="ts" ，绑定到currentTime表示我应该为currenttime 。 我现在只需要在该组件中禁用TypeScript，如果我更多地依赖于该语言，这将更加烦人。

Again, I’m willing to bear through these issues in the present for the sake of familiarizing myself with the framework. Once I have a spare moment, I may try my hand at fixing the issues myself.

再次，为了使自己熟悉该框架，我愿意在当前解决这些问题。 有空的时候，我可以尝试自己解决问题。

Anyway, I finished this rudimentary clone of my original React app and after peeking through the Dev Tools of both apps, I made two immediate observations:

无论如何，我完成了我原始的React应用程序的基本复制，并且在浏览了两个应用程序的开发工具后，我立即观察到了两个发现：

1. Both apps were running at nearly 60 fps. I’m not sure I’d ever actually measured the FPS of the React version, but regardless, this isn’t entirely surprising to me. I’d done decent optimizations on the React rendering so it was pretty fast for the use case. “Fast enough.” But fast enough (at least, for now) or not, I could tell that React was maybe not the best tool for the job. Like I said, the app relies a lot on the video time which obviously is constantly changing. A framework that by default tries to re-render entire DOM trees whenever state changes is probably not the best to handle this sort of thing

1.两个应用程序都以近60 fps的速度运行。 我不确定我是否曾经实际测量过React版本的FPS，但是无论如何，这对我来说并不完全令人惊讶。 我已经对React渲染进行了不错的优化，因此在用例中它非常快。 “足够快。” 但是，无论是否足够快(至少到目前为止)，我都可以说React可能不是最佳的工具。 就像我说的，该应用非常依赖视频时间，而视频时间显然在不断变化。 默认情况下，尝试在状态变化时尝试重新渲染整个DOM树的框架可能不是处理此类问题的最佳方法

The React version runs at 60fps, yes, but it does so with the update function for the currentTime state throttled to every 200ms, and with a lot of shouldComponentUpdates. Svelte gives me the same thing without needing all the boilerplate. The React version just uses component state and currently utilizes the currentTime state in one area, making it easy to optimize. Imagine if I was putting it in a global store; I'd need to define custom shouldComponentUpdates everywhere. With Svelte, none of that is necessary.

React版本以60fps的速度运行，是的，但是它通过将currentTime状态的更新功能限制为每200ms来执行此操作，并且具有很多shouldComponentUpdate 。 Card.svelte给了我同样的东西，不需要所有的样板。 React版本仅使用组件状态，并且当前在一个区域中使用currentTime状态，因此易于优化。 想象一下，如果我将其放在全球商店中； 我需要在各处定义自定义的shouldComponentUpdate 。 使用Svelte，不需要这些。

That’s why, as soon as I heard of Svelte, I wanted to rebuild this app with it. Not because there were any current problems with performance, but because I knew what was all going on behind the scenes and it pained me. When Rich Harris said, “As engineers, we should be offended at all that inefficiency,” it really spoke into my soul. I don’t want my entire app trying to diff itself every 200ms even if most of it gets blocked by shouldComponentUpdate. And believe me, shouldComponentUpdate has always been my best friend.

这就是为什么，当我听说Svelte时，就想用它重建这个应用程序。 不是因为当前性能存在问题，而是因为我知道幕后发生的一切，这让我很痛苦。 当里奇·哈里斯(Rich Harris)说： “作为工程师，我们应该因效率低下而受到冒犯”，这的确使我深感不安。 我不希望我的整个应用程序尝试每shouldComponentUpdate一次自我比较，即使大多数应用程序shouldComponentUpdate由shouldComponentUpdate阻止。 相信我， shouldComponentUpdate一直是我最好的朋友。

Svelte binds to currentTime with requestAnimationFrame under the hood, and everything still runs at 60fps (again, for now). There's still a ton of room for improving performance down the line if I ever need to. But who knows? Maybe I'll never even need to.

Svelte通过requestAnimationFrame绑定到currentTime ，并且所有内容仍然以60fps的速度运行(现在还是这样)。 如果我需要，还有大量的空间可以提高性能。 但是谁知道呢？ 也许我什至不需要。

2. The bundle size was nearly 80kb. 80kb? Well that’s a decent amount below the React version’s ~200kb, but still an order of magnitude higher than what I expected. Well, in retrospect, there was an obvious answer to this dumb question. I first tried creating a new starter Svelte app just to make sure my memory wasn’t failing me and this was in fact abnormal. Built it — bundle size was about 5kb. Okay, so I wasn’t crazy.

2.包大小接近80kb。 80kb？ 嗯，这比React版本的200kb以下还不错，但是仍然比我预期的高一个数量级。 回想起来，这个愚蠢的问题有一个明显的答案。 我首先尝试创建一个新的入门级Svelte应用程序，以确保我的记忆不会让我失望，而这实际上是不正常的。 构建它-捆绑包大小约为5kb。 好吧，所以我没有疯。

I tried adding a video element and some handlers/bindings to it. Maybe there was some extra Svelte machinery (75kb of it…?) that needed to be included when handling media elements and wasn’t considered in most demos that didn’t use video.

我尝试向其中添加视频元素和一些处理程序/绑定。 也许在处理媒体元素时需要包括一些额外的Svelte机制(其中的75kb…？)，并且在大多数不使用视频的演示中并未考虑到。

Nope. Still negligible bundle size.

不。 捆束尺寸仍然可以忽略不计。

I started removing things from the main Svelte app, which was ballsy considering I hadn’t committed anything to git at this point. Nothing changed.

我开始从主要的Svelte应用程序中删除内容，考虑到目前我还没有对git做出任何承诺，这非常容易。 没有改变。

Wait, how big is lodash? About 75kb, it turns out. That could be it.

等一下，lodash有多大？ 事实证明，大约75kb。 可能就是这样。

I removed lodash imports. 5kb. Merde.

我删除了lodash导入。 5kb。 默德。

But wait, I had barely imported anything, just a handful of things like import { times } from 'lodash', so why was it including the whole bundle? This is 2020-- isn't tree-shaking a thing?

但是，等等，我几乎什么也没导入，只是import { times } from 'lodash'类的东西，那为什么要包括整个捆绑包呢？ 这是2020年-摇树不是一件事情吗？

Well it turns out this person on StackOverflow had the same question. This is how I learned that the normal lodash module on npm isn’t actually an esmodule and thus can’t be tree-shooketh. I can’t be the only person who never realized this, especially since at my last company we had also used the full lodash module unless we were also using babel-plugin-lodash and/or lodash-webpack-plugin and I just never noticed.

好吧，事实证明这个人在StackOverflow上也有同样的问题。 这就是我了解到的，npm上的普通lodash模块实际上不是esmodule，因此不能成为树梢的。 我不能不是唯一一个从未意识到这一点的人，尤其是因为在我上一家公司中，我们还使用了完整的lodash模块，除非我们也使用了babel-plugin-lodash和/或lodash-webpack-plugin ，但我从未注意到。

So PSA: WebPack can’t tree-shake your lodash unless you use it with one or both of the above plugins, or you use the esmodule version of lodash aka lodash-es.

因此，PSA：除非您将lodash与上述一个或两个插件一起使用，或者您使用esmodule版本的lodash aka lodash-es ，否则WebPack不能摇晃您的lodash。

I re-added the bits using lodash into my code, this time drawing from lodash-es, et voilà: 7.5kb. There's the bundle size everyone knows and loves.

我使用lodash将位重新添加到了我的代码中，这次是从lodash-es等绘制的：7.5kb。 每个人都知道和喜欢的捆绑包大小。

Meanwhile the React version has been awfully quiet with its 200kb.

同时，React版本以其200kb的声音非常安静。

Of course, my intention isn’t to bash React or promote Svelte. At least, not in all cases, and not for everyone. For example, I personally wouldn’t suggest Svelte to a new frontend developer. I would instead direct them to React, because even though React also does a lot behind the scenes, it was still essentially all JavaScript.

当然，我的目的不是打击React或推广Svelte。 至少不是在所有情况下，也不是每个人。 例如，我个人不会将Svelte建议给新的前端开发人员。 相反，我将它们定向到React，因为即使React在幕后也做了大量工作，但本质上仍然是所有JavaScript。

Which brings me to the main thing I miss about React. Bearing in mind that JSX just gets translated into function calls, React was just JavaScript. All that time working with React didn’t just make me good at React — it made me good at JavaScript.

这使我想到了关于React的主要内容。 考虑到JSX只是被转换成函数调用，React只是JavaScript。 与React一起工作的所有时间不仅使我精通React，而且使我精通JavaScript。

Svelte is not JavaScript — it’s Svelte. It’s its own language and gets compiled to a separate set of instructions that aren’t immediately obvious from the code you write.

Svelte不是JavaScript，而是Svelte。 它是自己的语言，被编译成单独的指令集，这些指令从您编写的代码中不会立即显而易见。

It was one thing to use React’s synthetic events: onClick still feels like attaching a real event handler to a real element. But Svelte's bind: isn't like anything in HTML or JavaScript. You can get used to exporting your props as variables at the top of a file, but it doesn't feel like JavaScript. There's so much in there that boils down to "Because Svelte" and I'm not saying that's a bad thing, but I miss just being able to rely on my JavaScript knowledge to get me by.

使用React的综合事件是一回事： onClick仍然感觉像是将真实事件处理程序附加到真实元素上。 但是Svelte的bind:与HTML或JavaScript中的任何东西都不一样。 您可以习惯于将props作为变量导出到文件顶部，但是感觉不像JavaScript。 里面有很多东西可以归结为“因为Svelte”，我并不是说那是一件坏事，但是我想念仅仅依靠我JavaScript知识来帮助我。

En tout cas, my main goal here is to keep learning about and acquiring tools that fit various use cases for software development. I’m learning Svelte because the paradigm it espouses strikes me as a particularly useful and important one, especially for this application, and maybe especially for modern web development. My high school music theory teacher told our class that learning various theory concepts was essentially just adding to our “bag of tricks”, and I think of these programming tools and paradigms the same way. For now, I just think Svelte is the best tool for this job.

En cas cas ，我在这里的主要目标是继续学习和获取适合各种软件开发用例的工具。 我正在学习Svelte，因为它支持的范例对我来说是一个特别有用和重要的范例，特别是对于此应用程序，尤其是对于现代Web开发。 我的高中音乐理论老师告诉我们的班级，学习各种理论概念本质上只是在增加我们的“花招”，而我对这些编程工具和范例的看法也是如此。 就目前而言，我只是认为Svelte是完成这项工作的最佳工具。

Write Medium in Markdown? Try Markdium!

用降价写中号？ 尝试Markdium ！

翻译自: https://medium.com/@amvd/no-title-a2aa5eaee120