今日推薦開源項目：《只是看著 blockrain.js》
今日推薦英文原文：《The Lost Art of Vanilla JavaScript》
今日推薦開源項目：《只是看著 blockrain.js》傳送門：GitHub鏈接
推薦理由：這個項目是一個可以在瀏覽器上運行的俄羅斯方塊。作為消遣自己動手定製材質外觀或者玩上一會自然挺不錯，不過這次興許有別的消遣方法——這個項目還實現了自動遊戲，也就意味著你完全可以看著兩個機器人互相競爭（你應該不會想加入這麼快節奏的遊戲的……）而不需要自己出手，興許作為等待頁面載入時的一種新的打發時間的方式會是個新穎的點子。
今日推薦英文原文：《The Lost Art of Vanilla JavaScript》作者：Danny Moerkerke
原文鏈接：https://medium.com/better-programming/the-lost-art-of-vanilla-javascript-c11519720244
推薦理由：有了基礎才能更好使用那些現成的工具
The Lost Art of Vanilla JavaScript
When programming became gluing libraries together
A couple of months ago, I did a talk on Web Components for a tech company where most attendees had no prior experience with them. It was a very fun and well-received talk that ended with a round of questions from the audience that lasted over half an hour.Near the end, someone asked me if this meant that we were going back to the days of what he called 「jQuery-like spaghetti code,」 due to the raw DOM manipulation code I had shown. I could see some others nod in agreement, and this reaction really got me thinking.
Apparently, code that isn』t part of some framework or library but is just what we call 「vanilla JavaScript」 is perceived as bad and 「spaghetti code.」 This shouldn』t even come as a surprise.
A whole generation of developers got started using frameworks and starter kits that come with a whole bunch of dependencies out of the box. Just run npm install and tweak the code templates to your needs.
While this can be a good place to start, we do need to realize there』s more to programming than gluing third-party libraries together.
I』m Not Against Dependencies
Let me first make it clear that I don』t advocate against the use of dependencies. In fact, I have quite some experience with multiple front end frameworks.I do, however, encourage you to ask yourself if you really need these dependencies for your next project before you think about which ones to use.
This is a very important question to ask yourself. It』s a question that I feel is not asked enough, if it』s even asked at all.
The Fallacy of 「Don』t Reinvent the Wheel」
You probably heard this many times already. As a developer, you shouldn』t 「reinvent the wheel,」 but instead, you should use a library that already does what you』re trying to build.This is good advice when you need a database ORM, for example, because it doesn』t make sense to write that from scratch when there are already good ones available.
The problem is: Where do we draw the line when deciding what to code ourselves and when to use a third-party dependency?
In 2016, the developer of the left-pad package decided to remove all his packages from NPM over a legal issue, and he almost broke the internet by doing so. It was illustrative of how insane the reliance on third-party software has become.
The only job of left-pad is to pad out the left side of a string with zeroes or spaces. The package consists of only a few lines of code, and it can be written by a junior developer in a few lines as well. In fact, it has already been deprecated in favor of the standard String.prototype.padStart(), yet thousands of projects depended on it.
And it gets even worse. The package isarray consists of only four lines of code and checks if a given argument is an array. Of course, this is meant for older browsers that don』t support the native Array.isArray() method, but this could literally be written in one line of code by any developer.
Coding that yourself is not 「reinventing the wheel.」 There』s really no need to have this as a dependency in your project.
We Have No Idea What We』re Using
Still, people argue that it』s better to use already available third-party modules — even when they』re very small — because these have been 「battle-tested」 and are 「proved solutions.」The question is: Are you sure?
Do you know that a dependency is a well-tested and proven solution, or do you just assume it is?
Do you really know all the stuff that』s in your node_modules folder?
I don』t, and probably nobody does. In all honesty, you don』t have to, but at least you should think about what to install as a dependency and what to code yourself.
Do you really need a bloated library to make simple HTTP calls when there』s already fetch in every modern browser? Or a large date parsing library that you can write yourself in a few lines of code and that does only what you really need?
It seems like a whole generation of developers are too insecure to write and use their own code, and instead, they resort to gluing libraries together that they assume to be well-tested and bug-free.
But this is a false sense of security.
How Did We Get So Insecure?
Why are we as developers so afraid to trust our own code and rather use other people』s code we think is better and more secure?After all, these people publishing their open-source code on Github are also developers, just like us. They』re not perfect either, and they might also write code that has bugs. Yet we choose to trust in them and not ourselves.
I understand that you don』t want to write a library like RxJS or React yourself, for example. These are large libraries that have been around for years, have many contributors, and are well-tested. I wouldn』t recommend reimplementing these unless you want to learn from it.
But for smaller functionality that you can easily code yourself and fully adapt to your own needs, I would recommend to write this yourself. At least you can easily modify and fix it when needed.
I guess the insecurity in developers to write their own code comes from years of using libraries and frameworks that have hidden the native JavaScript platform from us. This already started with jQuery and got worse with the emerging of frameworks like Angular and React.
These are abstractions that, by their nature, are perceived as complex. Because of that, developers tend to use these as black boxes.
Again, I』m not anti-framework and I do see the value they bring. But now, it seems like there』s a whole generation of developers that only know how to program using a framework and have little-to-no knowledge of the underlying platform. They wouldn』t know how to work with the raw DOM because they have hardly been exposed to it, if ever.
I』ve been involved in a couple of evergreen projects where the first question was which framework we should use, not if we even should use one. The default assumption was that a framework was needed, and the main argument was that a framework would provide everything we needed and we shouldn』t reinvent the wheel.
The irony is that many of these people didn』t have enough knowledge of the native platform to tell whether or not the chosen framework was a good choice in the first place.
It』s understandable that the complexity of these frameworks is intimidating, especially for beginning developers. They』ll tend to use them as black boxes without understanding how they work internally.
Frameworks don』t encourage this either since their job is to make programming easier to get started with by hiding low-level details and APIs.
This creates dependence on the framework, which in turn doesn』t help in giving developers the confidence to code things themselves.
Using Dependencies Is Outsourcing Your Business
When you』re using a dependency in your app, you』re basically outsourcing that part to some other developer, and so you better be sure that person is doing a good job.If you have a business and you outsource customer service to some other company, you』d be in big trouble if they』d mess it up. What if they have a different idea of what good customer service is?
You probably wouldn』t let that happen, and you should treat the dependencies in your app in the same way. That doesn』t mean you need to read all of your dependencies』 source code, but at least you should have a solid idea of how it works.
Know the Foundation
But to be able to do that, you should first have a solid understanding of programming in vanilla JavaScript, since that』s the foundation of it all.Front end frameworks definitely bring value, but also complexity and overhead. I』ve been through the pain of learning and implementing several frameworks, and I can tell you that you need to make sure the effort is worth it.
There』s no reason not to use the native platform, and you』ll be surprised to see what it has to offer nowadays.
Don』t just parrot the people saying you shouldn』t reinvent the wheel. Learn the foundation first, and then decide whether or not you really need that library or framework.
You』ll be a better developer for it.
下載開源日報APP：https://openingsource.org/2579/
加入我們：https://openingsource.org/about/join/
關注我們：https://openingsource.org/about/love/
