As you might have heard — Google I/O ’17 happened. And the Google Chrome Developers Team presented very impressive talks.
One of them caught my attention. This talks was give by Seth Thompson, Product Manager on the V8 Team and Chrome.
Seth covers the new features of V8 engine. And talks in depth about two main tradeoffs each browser should make — when it receives the JavaScript code.
First tradeoff is between fast startup and peak performance. Browser should decide whether it should start executing the JavaScript right away. Or wait — optimize it — and then reach the peak performance.
Second tradeoff is between memory usage and maximum optimization. Essentially it the decision that the browser should make — whether spend as much computing resources as possible to optimize JavaScript code. Or to go slower — for instance — if you’re running a mobile browser, and memory is an issue.
So the new V8 engine can essentially do both — depending on the context — it is able to decide on the fly — which combination of this tradeoffs is better at the particular moment.
What I especially enjoyed in that talk is the demo time. Seth is showing how you can easily debug your node applications right in the chrome DevTools.
Great Job, V8 Team, cool video. Really enjoyed it!
NPM 5.0
In our “Future is Now” section — the beloved node package manager NPM gets a MAJOR version update! Version 5!
Let’s look what the developer team has to say about this release:
npm takes a pretty big step forward, significantly improving its performance in almost all common situations, fixing a bunch of old errors due to the architecture, and just generally making it more robust and fault-tolerant.
Couple of Breaking Changes worth taking a look at:
* Existing npm caches will no longer be used: you will have to redownload any cached packages.
* npm install ./packages/subdir will now create a symlink instead of a regular installation.
* npm will — save by default now. Additionally, package-lock.json will be automatically created.
* npm cache commands have been rewritten and don’t really work anything like they did before.
The list of the New Features is longer then my leg!
There are Installer changes, changes in publishing and, as you might have guessed — complete cache rewrite.
Kudos to the guys from NPM — great job on the tool we need and love dearly!
Article of the Week
This week we’re going to take quite a spin at our section “Article of the Week” and will include TWO articles instead of one.
I just find these two articles kind of make sense together — you’ll see why in a minute.
First, very controversial post written by Alex Ewerlöf You might not need to transpile your JavaScript.
Following the footsteps of such websites as YouMightNotNeedJQuery.com and You Don’t Need Lodash/Underscore Alex is taking a look at how you could essentially write everything in native modern JavaScript.
The article starts with some statistical data on how modern browsers are actually installed on the 74% of the users’ computers. Then Alex is analyzing ES Compatibility Table and really boils down his argument to this one phrase:
If you’re transpiling your JavaScript to ES5, you’re making your code unnecessarily big and slow to support a minority of the users who will probably upgrade their system by the time you manage to configure your Webpack and Babel!
But, Alex is leaving us with this cute elephant in the room: ES6 Modules.
And THAT is why I’m including my second pick of the week. An article called The state of JavaScript modules by Johannes Ewald.
Now you see why these two fit together perfectly!
Johannes starts his article as an answer to some controversy that’s been going around about the state of Modules. Especially in node.js and the recent introduction of *.mjs file extensions.
So this article goes into great detail describing current implementations of modules in three main branches:
* in the browswers
* with web pack and similar transpilers (just talked about how we don’t need them)
* and in node.js
Very cool breakdown. What this boils down to — is that as of may 2017 modules are natively supported in all major browsers. You should use them!
And the question as to transpile or not transpire — I leave to you.
Library of the Week
Ok, this week we take a closer look at Preact!
For those who didn’t hear about this — just a quick recap of the features.
This list is directly from the landing page
1. Closer to the Metal
Preact provides the thinnest possible Virtual DOM abstraction on top of the DOM. It diffs Virtual DOM against the DOM itself, registers real event handlers, and plays nicely with other libraries.
2. Small Size
Yep, it’s tiny 3kb is awesome.
3. Big Performance
Because it’s so close to the metal — it’s blazingly fast. It’s one of the fastest Virtual DOM libraries out there, thanks to a simple and predictable diff implementation.
OK, sounds great — but can it do anything? Being so tiny?
It turns out it can!
4. Instantly Productive
props, state and context are passed to render()
Use standard HTML attributes like class and for
Works with React DevTools right out of the box
As virtually any javascript framework the first demo — is a to-do list.
And the code is really slick, es6 ready, very concise and easy to understand.
If you want to dive right into it, I have a perfect introduction for you from JSConf Europe — and it’s done by the creator of the library — Jason Miller.
Tool of the Week
The tool of the week is Birdview.
Very nice, nifty tool to fit a visual overview of the complete web page into your viewport. It comes as a standalone chrome extension, which is very cool.
And of course you could take a look at the source code in JavaScript as well.
Some very cool examples — of how the common websites like youtube, twitter, the verge — are actually looking from this perspective.
Action Steps
Please like that video if you liked what I talk about here. Leave your feedback.
Click that subscribe button right away.
See you all next week!
