DEV Community: Mike Sherov

2020 Web Milestones

Mike Sherov — Thu, 23 Jan 2020 23:21:30 +0000

Article Status: a work in progress, expected to be shaped and augment throughout 2020. Think of this more as a wiki page than a fully formed article.

The other day, as I watched Chromium Edge roll out, I thought to myself “end of an era. A huge milestone in the history of the Web”. I then stepped back and realized that there’s actually a few big things happening this year. Inspired, I fired off a tweet asking about big upcoming Web changes. It turns out, a lot of big stuff is happening this year, and this post will attempt to document most of it. I encourage you to submit pull requests here to help welcome in the new and eulogize the old. With further ado, the list:

January

(-) Windows 7 EOL - The second largest version of Windows with the lion’s share of remaining IE11 users. Hopefully its end of life prompts users to move to Windows 10 and off IE11.
(-) EdgeHTML Rendering Engine EOL - Now that Edge is powered by Chromium, we have lost a renderer in the market. Moves the ecosystem from 4 main rendering engines “EdgeHTML, Webkit, Gecko, Blink” to 3 “Webkit, Gecko, Blink”.
(+) Chromium Edge Released - With Chromium Edge, folks on Windows 7 and Windows 8.1 finally have an upgrade path to a modern browser while still having IE Mode so legacy enterprise sites that require IE11 still work.
(+) Flow Rendering Engine and Browser Released - Just as we said goodbye to EdgeHTML, a new rendering engine and browser popped onto the scene: https://www.ekioh.com/flow-browser/ Moves the ecosystem from 3 main rendering engines “Webkit, Gecko, Blink” right back to 4 “Webkit, Gecko, Blink, Flow”.
(+) Web Components Everywhere - With Chromium Edge’s release, all major browser vendors are shipping Web Components V1, as per: https://www.webcomponents.org/
(+) ES Modules With Conditional Exports Unflagged in Node - It’s been almost 5 years since ES Modules were standardized, but compatibility issues between Common JS (the module system used in Node) and ESM prevented much progress for a long time. Finally, there is a path forward for Node Ecosystem to iteratively and deliberately migrate to ESM, unlocking “Universal” javascript for all. You owe the NodeJS modules team (https://github.com/nodejs/modules) a high five for making this happen.
(+) Deno goes 1.x - Deno is shaping up to be “the other server side javascript runtime”. Offering native Typescript Support, a default Secure environment, intentions to align with Web Standard APIs like addEventListener and others, and other philosophical differences from Node. Should be interesting to see how Deno influences Node and/or carves out it’s own space.

February

(-) Goodbye CSRF, Hello Default SameSite Cookies - Browsers default policy has always been “when making a request to example.com, send cookies for exmaple.com, even if the request originates from a site other than example.com”. This behavior enables a security vulnerability and tactic called CSRF, where an attacker can trick you into visit their site while you’re logged into example.com and then make malicious requests on your behalf. On Feb. 4th, this default behavior is changing to “when making a request to example.com, send cookies for exmaple.com, only if the request originates from example.com”. The number of CSRF vulnerable websites this fixes is immeasurable, but a whole class of vulnerability will suddenly stop working for attackers on this day. HUGE.

April

(-) Python 2 EOL - Books will be written about the Python community’s long painful transition to Python 3. But finally it will be a history book as of April 20th.

December

(-) Flash EOL - Adobe Flash pushed the entire web forward and served as a wakeup call to the Web community. You can probably say that HTML5 and a lot of the improvements to the Web that happened around that time were a direct response to Flash’s capabilities. All video sites, gaming sites, etc. ran Flash. Over time, the Web caught up (mostly), and Flash was banned from the iPhone, which practically forced the Web community to move on. Flash languished for 10 years, mostly appearing in headlines about it’s many security vulnerabilities. It’s EOL is December 31st. I’ll miss Flash.

Sometime This Year

(+) http/3 Ships Unflagged in Major Browser - Chrome, Firefox, and others are already shipping http/3 behind flags. Major CDNs like Cloudflare have support. Work is going on right now to bring http/3 to Node. At some point, it’ll hopefully get unflagged this year, and we’ll shave another few % of latency off the average http request.
(+) PHP 8 with JIT - PHP as a language and community is still productive and kicking. This year will see PHP move to a JIT which has potentially promising implications for performance, above and beyond all the impressive speed gains in the language since 7.0.

The Rise of Man In The Middle (MITM) Based Session Hijacking Attacks

Mike Sherov — Tue, 19 Nov 2019 13:02:00 +0000

Most websites offer personalized experiences powered by a “logged in” mode. In order to remember who a user is, sites place a cookie containing a unique identifier on the user’s browser. This is known as a session identifier. When the browser sends the next request to the site, it automatically includes the session id cookie, identifying the user so the site can customize the experience.

But what if an attacker steals a user’s session id? They’d be able to effectively log in to the site as the victim, viewing their potentially private information. If the site was a bank, this could allow them to make transfers! If it was a social network, the attacker could post on the victim’s behalf, or possibly even change the victim’s password, or email address. This is known as session hijacking. There are many ways to hijack a session, but let’s focus in on one of those methods.

A man-in-the-middle attack (often abbreviated MITM) is when an attacker intercepts a request between a user and the site they’re connecting to. If that request isn’t encrypted, an attacker can read the information it contains. That is, if the session id is unencrypted, a man-in-the-middle can steal it! Back in the “mostly wired” days of the internet, this type of attack was rare because hacking into a wired connection meant compromising a physical system. However, as free public unencrypted WiFi spread, man-in-the-middle session hijacking attacks became trivial. If you connect to public WiFi, or private WiFi using weak security protocols like WEP , the information you transmit over the air is not implicitly encrypted. That means if you connect to a site over http, which is also not encrypted, anyone else connected to that network can read the data you’re sending to that site. There are many freely available packet sniffers on the market that allow you to walk into a coffee shop, click one button, and see whatever unencrypted websites the other patrons are visiting.

You may be wondering how feasible MITM attacks like this are, as it may seem very rare. However, because this type of attack isn’t based on an attacker targeting a specific site, but rather an attacker targeting users on the same network as them, even small and low-value target sites fall victim to this attack. However, it isn’t only small sites that have exploitable vulnerabilities; almost every site has them. In fact, even the largest sites in the world were once vulnerable to session hijacking via a man in the middle attack.

Back in 2010, not many sites were fully https only. Sites knew they had to encrypt checkout pages to protect credit card numbers, and they knew to encrypt login forms to protect usernames and passwords; but most sites were still http everywhere else, allowing their session ids to be transmitted back and forth unencrypted in cleartext! This was even true for Facebook. That all changed in Oct. 2010 when Firesheep was released as a Firefox plugin. The software was a specialized packet sniffer that looked for unencrypted Facebook session ids, and with a nice, user-friendly UI, provided 1-click access to take over the Facebook account of anyone sharing the insecure WiFi network with the attacker! It was a user-friendly, purpose-built Facebook session hijacker. Firesheep was quickly expanded to support session hijacking on a laundry list of sites including Amazon, Google, Github, Twitter, and many other high profile sites who were vulnerable. Hundreds of thousands(!!) of people downloaded Firesheep at the height of it’s popularity!

Firesheep very quickly led to the “https everywhere” movement, with the EFF releasing the HTTPS Everywhere plugin, which changed the default behavior of Firefox to check if a site supported https, and if so, used it for every page on the site, as opposed to just login and credit card forms. While this was a nice workaround for users to fix the problem themselves, it did nothing to prevent the problem for users of other browsers, or those who didn’t know about this problem at all. Fairly rapidly, major sites worked to fix this issue by forcibly serving their entire site over https. This also accelerated adoption of HSTS, an http header that tells browsers to use https://, even if the user typed in http:// or left the protocol off altogether. A solution emerged: use https everywhere, redirect all http traffic to https, and use hsts headers so browser won’t even make an http request to begin with.

Ultimately, as web developers it is our duty to provide safe and secure experiences for all. Security should not be an afterthought, and it is our responsibility to ensure the sites we build are as secure as possible. This includes https everywhere. All the old reasons to avoid https are gone. Nowadays, certificates are free via Let’s Encrypt so there’s no additional cost. TLS encryption is fast, so there’s virtually no performance penalty. There are other, non-security related reasons to use https as well. http/2, which is a faster protocol than http/1.1, only works over https! There is also a growing list of https-only browser features. Lastly, this will prevent content from being marked as insecure in Chrome. Using https is free, performance-friendly, provides good UX, and prevents MITM session hijacking!

Because there are so many different web hosting providers, many different web server applications, and many different OSes, there’s no universal set of instructions on how to set it up. However, the EFF has released Certbot, which should automate the setup for a wide array of configurations. If that doesn’t work, a Google search for “how do I set up https on…” should yield good results. Don’t let the lack of universal instructions dissuade you. The benefits of https are worth it.

MITM based session hijacking attacks are a real threat to web users. Their prevalence has increased in the age of free public WiFi, and there are many documented, high profile exploits like Firesheep demonstrating their power. Thankfully, serving websites completely over https solves this specific exploit in a free, fast, and secure way. It may take some work to figure it out, but ultimately it’s worth it knowing your users will have one less thing to worry about when using your site.

Thanks to Adam Rackis, Gabriel McAdams, and Lars Moelleken for invaluable early feedback on this post.

The Humble Switch Statement

Mike Sherov — Wed, 25 Sep 2019 20:28:00 +0000

The switch statement has long been a staple in popular programming languages. It’s typically used to execute branching logic by comparing a value against multiple cases, and has at least one way of introducing subtle bugs: fallthrough. In this article, we’ll dive into the inner workings of this seemingly “simple” bit of syntax in javascript, discover how it works, and find use cases for it’s sharp edges. Keep in mind that this is all “toy code”, and may not be suitable for use in your codebases considering the relative obscurity of these edges.

Syntax Definitions

We’ll be using precise terms for each bit of syntax, so let’s start with some definitions. Consider the following code, and use the table below to map the syntax to it’s name:

switch ("a") {
  case "b":
    log("c")
    break
  default:
    log("d")
}

Code	Term
switch { … }	SwitchStatement
‘a’	discriminant
case ‘b’	SwitchCase
‘b’	test
log(‘c’)	consequent
default	SwitchDefault
log(‘d’)	consequent

Evaluating Cases and the “Inverted Switch”

In most typical cases, SwitchStatement is used to compared a computed discriminant against multiple literal SwitchCase tests, either integers or strings:

function speak(animalType) {
  switch (animalType) {
    case "dog":
      return "woof"
    case "cat":
      return "meow"
  }
}

In this snippet above, both "dog" and "cat" are strings literals, but that doesn’t have to be the case. The JS spec says that SwitchCase tests can be any expression, even function calls. Let’s rewrite our SwitchStatement to use function calls:

const getDogType = () => "dog"
const getCatType = () => "cat"

function speak(animalType) {
  switch (animalType) {
    case getDogType():
      return "woof"
    case getCatType():
      return "meow"
  }
}

Seeing that we can run functions in our SwitchCase tests, we can now invert the purpose of the SwitchStatement. That is, instead of comparing a variable against a set of literals, we can compare a literal, e.g. true, against a set of function calls. Consider the following code:

function log(logValue, returnValue) {
  console.log(logValue)
  return returnValue
}

switch (true) {
  case log("case 1", false):
    console.log("body 1")
    break
  case log("case 2", true):
    console.log("body 2")
    break
  case log("case 3", true):
    console.log("body 3")
    break
}

// output:
// case 1
// case 2
// body 2

Notice that case 3 is not in the output, because SwitchCase tests are executed in order only until one strictly equals the discriminant (a.k.a. “short circuiting” ), and then the corresponding SwitchCase consequent is executed. Any subsequent SwitchCase tests are not executed. This allowed us to “invert” the purpose of the switch! That is, we can compare a literal against a set of functions until one matches. A real world use case for such code might look like this:

function accessControlStatusCode(user, request) {
  switch(true) {
    case request.isForbidden():
      return 403;
    case !user.isLoggedIn():
    case !user.isAuthorized(request):
      return 401;
    default:
      return 200;
  }

Note that because order matters, a forbidden AND unauthorized request will display the forbidden error code. Also notice that there is a “fallthrough” from line 5 to line 6 which means that 401 is returned in either case… but maybe we’re left wondering if !user.isAuthorized(request): is called when case !user.isLoggedIn(): is already true. That is, we’re wondering if case !user.isLoggedIn(request): still “short circuits”. Let’s find out:

function log(logValue, returnValue) {
  console.log(value)
  return returnValue
}

switch (true) {
  case log("case 1", false):
    console.log("body 1")
    break
  case log("case 2a", true):
  case log("case 2b", true):
    console.log("body 2")
  // no break here
  case log("case 3", true):
    console.log("body 3")
    break
}

// output:
// case 1
// case 2a
// body 2
// body 3

Our rule still holds! SwitchCase tests are only executed until one strictly equals the discriminant, even if there is another SwitchCase directly underneath. Also note that we have introduced a “fallthrough” by not breaking after body 2, so that body 3 is executed! We can conclude the following rule about switch: switch will execute every SwitchCase test until one strictly equals the discriminant, and then will execute every following consequent, in order, until it encounters a statement like break, return, or continue. This rule makes for very interesting patterns when used intentionally, as you’re about to see.

Fallthrough

Several of the examples we’ve seen so far contain fallthroughs. At first glance, fallthrough just looks like one giant bug waiting to happen. With fallthrough, consequents that don’t end in a control flow statement like break; will then execute the next consequent, which is often a bug:

function speak(animal) {
  let sound
  switch (animal) {
    case "dog":
      sound = "woof"
    case "cat":
      sound = "meow"
  }

  return sound
}

Oops, now speak('dog') === 'meow'! This type of bug is so common that most linters include a rule for switch statements that forbids fallthrough unless a comment // falls through is added calling it out as intentional. If it’s so error-prone, why does switch even have fallthrough? We can say for sure that sequential SwitchCase’s (i.e. back-to-back SwitchCases with no consequent separating them) is a useful form of fallthrough, as we saw in our accessControl example, but are there legitimate uses cases for fallthrough after a consequent? The answer lies in the rule we discovered, which we can leverage to enter a set of transformations of data at any point. Consider, for example, a time scale conversion function:

function toSeconds(value, term) {
  switch (term) {
    case "years":
      value *= 365
    case "days":
      value *= 24
    case "hours":
      value *= 60
    case "minutes":
      value *= 60
  }

  return value
}

toSeconds(1, "minutes") // 60
toSeconds(1, "hours") // 3600
toSeconds(1, "days") // 86400

This example reveals the true nature of the humble switch statement. In many ways, it resembles a goto statement in it’s ability to allow you to jump to a specific “label” in a set of statements. goto has long fallen out of favor in moden programming languages, and maybe that’s a hint that this form of switch statement should remain in obscurity as well. It can be rewritten with a set of if statements or loops, and perhaps that’s better because less folks are exposed to purposeful fallthrough today.

Conclusion

Digging into basic language features is a good way to level up. As you saw, the switch statement is full of surprises. Features like fallthrough, short circuiting, and “inversion” make this statement powerful, but hazardous. Knowing of them will make you a better debugger, but exercising restraint in using them will ensure your code is more understandable and accessible to every member of your team.

What's the last thing you did that gave you impostor syndrome?

Mike Sherov — Thu, 25 Jul 2019 03:52:57 +0000

For me, it was releasing a course on https://egghead.io It made me realize that despite 16 years in software, I'm still a novice when it comes to instructing / teaching! I'm not sure I'm cut out for it, and I feel like an impostor. My ego is bruised but maybe that's a good thing...

How to Kill IE11 - What the Deaths of IE6 and IE8 Tell Us About Killing IE

Mike Sherov — Mon, 15 Jul 2019 16:43:44 +0000

"Internet Explorer needs to die."

This phrase has been uttered by countless software developers throughout the ages, but never has that statement been truer than it is right now. IE11 is the last mainstream browser that does not support ES6, a major update to JavaScript. The web has always worked on the principle of progressive enhancement, so this normally wouldn't be a problem, but the average JS app now leverages packages from the npm registry, and we find ourselves in a weird place. Even if our own app code is written in ES6+, most of the modules we rely upon are still targeting IE11 and ES5, and bring along bloated code and polyfills. IE11 needs to die so that module authors can ship small, faster ES6 by default, which benefits all of us!

In order to understand how best to kill IE11, we need to look back to how 2 previous versions of IE met their fate: IE6 and IE8. By examining the strategies employed to kill browsers, we can look at current efforts to sunset IE11. We can predict and evangelize for what may ultimately do it in, finally freeing the JS community from the burden of ES5.

Who Killed IE6?

The year was 2009 and Microsoft had a problem. Having released IE7 and IE8's release right around the corner, IE6's market share was still stubbornly high. You see, by that point IE6 had become a bit of bad branding for Microsoft, a symbol of the web's stagnation during IE6's dominance since its release in 2001, and a clearly inferior product to Firefox and Chrome, both of which had begun to make serious dents in IE's dominant market position. Compounding this problem was the many enterprise Windows clients who needed to stay on IE6 or IE7, having built web applications that only worked with their quirks. Microsoft needed a way to bury IE6 in a way that allowed enterprises to maintain their support.

Suspect 1: Automatic Upgrades to IE8

Knowing its users wouldn't upgrade on their own, Microsoft announced that in July 2009 it would automatically upgrade IE6 and IE7 users to IE8 via Windows update. Coupled with this upgrade were two affordances for enterprise users: the ability to block the automatic upgrade and a "compatibility mode" that allowed pages that were broken in IE8 to use IE7's rendering engine. So, was it successful? As you can see here, from 6/09 to 7/09, IE6 usage dropped from 24.6% to 15.6% in one fell swoop. It has been widely reported that the drop was due to a Youtube banner asking users to upgrade from IE6 to other browsers, and while that may have persuaded some users, the simple truth is that auto upgrade was the reason for this shift, and not armies of workers asking their bosses to upgrade.

Suspect 2: IE6 Countdown

In March of 2011, in seeing that auto upgrades to IE8 had a meaningful impact but that worldwide usage was still too high at 12%, Microsoft launched a marketing campaign to garner support for killing IE6. ie6countdown.com launched to say goodbye to IE6, track its demise, and to announce to the world that Microsoft themselves didn't want it around anymore. The goal was to get worldwide usage under 1%. Yet by June 2014, usage was still stubbornly high at 3.8%. However, there was a silver lining: most countries were <1% with the exception of China, which hovered at 12.5%. In order to finally get IE6 below 1% worldwide, something would have to happen to force Chinese users to upgrade.

Suspect 3: POODLE

At the time, most sites supported both SSL and TLS, two separate protocols that were used to power "https://" connections, with TLS being a safer, more modern protocol. That all changed on October 14th, 2014, when the Google Security Team announced a new vulnerability in SSL called POODLE. POODLE effectively
rendered all of the ciphers supported by SSLv3 unsafe, which meant SSL itself was no longer safe. Major websites like Twitter, and major CDNs like Cloudflare disabled SSL as a response. Any browser that could not talk TLS, like IE6, could not connect to those sites! This was the final blow against IE6, and by November 2014, worldwide IE6 usage was finally at 1%!

Verdict

It can be said that automatic upgrades from IE6 to IE8 put a huge dent in IE6 usage, but that POODLE finally put the browser to rest, causing major sites to literally block it from connecting. Let's compare this to how IE8 met its fate.

Who Killed IE8?

If the death of IE6 was frustrating, the death of IE8 was downright maddening. Yes, IE8 was leaps and bounds ahead of IE6, but IE8 was the last browser to be described as "old IE". IE8 still contained many non standard browser APIs, did not support ES5,was missing most of HTML5, and had no console built-in. If you remember the html5shiv, es5-shim, es5-sham, or alert-driven development, then you understand the pain. For reference, when jQuery finally dropped IE8 it dropped 30% in size. Lucky for the web development community, there were alternatives to IE8 that gave us hope that it may one day no longer plague us.

Suspect 1: IE9

Having just read that automatic upgrades to IE8 helped kill IE6, you might be tempted to say that IE9 helped kill IE8. Unfortunately, you'd be wrong. For IE6, there was always hope it would die via a simple upgrade because it wasn't a "terminal browser". Terminal browsers can't be upgraded without also upgrading the underlying operating system. Sadly, IE8 was the terminal browser for Windows XP. That is, if you wanted to upgrade to IE9 from IE8, you had to buy Windows Vista! That's right, you could get Firefox or Chrome for free... but for the ability to use IE9, you had to pay money to get Windows Vista or a new computer. Because of this, IE9 had little to do with the death of IE8.

Suspect 2: Chrome

The more obvious conclusion one could draw is that Google Chrome killed IE8. In a way, this is the right answer. Chrome has had an unbroken rise in market share since its release in 2008. Google plastered Chrome download prompts everywhere, including on its homepage, which also happened to be the most visited page on the internet at the time. Combined with an evergreen release strategy and several innovations above and beyond what other browsers were doing at the time, Chrome became an unstoppable force that pulled market share from everyone. However, this can be at best described as a slow shift. From it's peak of 29% in May 2011, IE8 would stay above 1% worldwide until September 2016.

Suspect 3: TLS 1.0/1.1 Deprecation

The PCI Security Standards Council is a body responsible for security standards for account data protection. If you want to accept credit cards from your application, you've likely done a PCI compliance audit. On June 30, 2017, the PCI SSC announced that in order to be considered compliant as of June 30, 2018, TLS 1.0 had to be disabled, and that TLS 1.1 was strongly discouraged. In a sense, the shockwaves from attacks like POODLE forced the industry to move onto progressively stronger security protocols. Many CDNs and sites followed suit and dropped TLS 1.0 and 1.1 similar to how they dropped SSLv3 when POODLE was announced. And similar to how IE6 didn't support TLS at all, IE8 only supported TLS 1.0 and TLS 1.1, and was cut off from ever accessing these sites. Once again, stronger security practices blocked IE from a large swath of the internet. This time though, IE8 was already under 1% of internet traffic. The TLS deprecation may have put a final nail in IE8's coffin, but it was already dead.

Verdict

It seems IE8 died a slow and drawn out death at the hands of Chrome, being stuck as the default browser for XP, destined to stay there until XP itself faded away.

How NOT to Kill IE11

Putting it all together, we see several strategies from IE6 and IE8 that we can apply to killing IE11 that won't work:

❌ Marketing Campaigns Like IE6 Countdown: As far as I can tell, this did little more than tell the world that Microsoft was ready to move on. Not effective. Besides, Microsoft has already told the world to get off IE11.

❌ Other Browsers Eating Market Share: Chrome is already dominant, and has been for years. At this point in time, IE11's graph looks like IE8's... that is, the competition is eating them at a slow and steady pace. There's nothing more we can do here.

❌ Increased Security Requirements: IE11 supports TLS 1.2, which likely won't be deprecated for many years to come. Nothing short of a vulnerability in TLS 1.2 would lead to its early demise. Besides, praying for a vulnerability in TLS to kill IE11 is bad faith! However, we have seen that big sites moving early on deprecations can have outsized impact on the internet as a whole.

So, what CAN we do to kill IE11? What will finally free us of ES5? What will kill the last of truly terminal browsers?

Killing IE11

As it turns out, the only thing that has ever truly worked is automatic upgrades. In order to do that, we saw that IE needs to be non-terminal, as we saw with IE6. We also saw that the replacement browser needs a plan to deal with existing enterprise users, as we saw with compatibility modes. So what do our prospects look like for IE11, assuming Microsft Edge as its replacement?

As of this writing, IE11 is a terminal browser on Windows 7, 8, and 8.1. Fortunately, with the move to Chromium as its rendering engine, Microsoft Edge will come to those versions of Windows, and in fact, preview builds are already available. This will finally unlock the opportunity for automatic upgrades from IE11 to Edge on those platforms!

As exciting as this prospect is, there are still enterprise customers who need IE11 compatibility that make up a large portion of the remaining IE11 holdouts. Once again, Microsoft is ahead of us and has already announced that Edge on Windows 7, 8, and 8.1 will have an "Internet Explorer Mode", which will allow IT admins to implement safe/blocklists for which sites should render using IE11 with the rest of the internet being rendered using Chromium!

Where does this leave us? While it is now technically possible, and it seems like the writing is on the wall, Microsoft has stopped short of announcing an automatic update plan from IE11 to Edge. All signs point to it being our best shot at being done with IE11 for good.

A Call To Action

So, what can we do?

First, we have seen that market leaders dropping technologies will cause shifts in browser usage. The key here is the technologies must be dropped (like SSLv3), and not just suggested to be dropped (like the Youtube IE6 banner). While it may seem unthinkable to suggest that Google, Facebook, and others to block IE11, once Edge comes out for old Windows, there's no good reason to not to force this upgrade. It'll add pressure to Microsoft to consider the auto upgrade idea. You (yes, you!) can support this movement by declaring you will resolve to block IE11 once Edge arrives on old Windows!

Second, you can ask your favorite open source package when and if it plans on dropping ES5 as its compile target. Just remember: be nice. Come from a place of curiousity and make no demands. Open source maintainers don't owe us anything, but asking politely about dropping ES5 may help kick up conversations and deprecations that may not have happened otherwise!

Lastly, you can advocate for automatic upgrades on social media using the #killIE hashtag. Microsoft has been very engaged with the web community, and discussing the issue publicly and the community's plans to drop support for IE may very well be a tipping point!

If we are successful, we will look back and say "Microsoft killed IE11 with automatic upgrades to Edge." Finally, we will stop compiling to ES5, and in some cases, stop compiling altogether. Finally, we will stop sending unnecessarily polyfills to browsers that don’t need them. Finally, we will have ES6 everywhere. Finally, Internet Explorer will be dead.

Thanks to Fred K. Schott and Brian Kardell for invaluable early feedback on this post.

Response to “Enabling Modern JavaScript on npm”

Mike Sherov — Tue, 04 Jun 2019 22:07:41 +0000

The Problem

In https://jasonformat.com/enabling-modern-js-on-npm/, Jason Miller lays out a problem:

given that the average JS application is composed of >50% 3rd party JavaScript,
And given that 3rd party code (which we’ll call library code) on npm still typically targets ES5 because it’s still the lowest common denominator,
And given that ES6 is more expressive and has a larger set of builtin functionality so it results in much smaller code than ES5,
That the average application, even if the first party code (which we’ll call application code) is ES6 and not transpiled to ES5, is much larger than it needs to be!

The Solution Landscape

Central to any solution here is the notion that library authors must feel free to publish ES6+ as the new lowest common denominator. Yes, it’s important to solve differential building across any version of JS, but I would specifically call out the ES5 - ES6 cliff as uniquely important because ES5 is the “Nevergreen Cliff”. That is, the last browser that isn’t Evergreen is IE11, and it doesn’t support ES6. All other version disparities will play out on shorter timescales with likely less urgency. Even still, a generic solve for any version of JS is important here. There will always be more cliffs.

We must also identify the players here:

Application developers, who need good tooling defaults so that they get small application bundles that still match their browser support statements.
Library authors, who need a reasonable guarantee from tooling authors that tooling will make it essentially effort-free for app devs to consume ES6, lest they get blowback and support burden from app devs who still need ES5.
Compiler authors, specifically Babel, Buble, TS, who need to know that if they can make it effort free for devs to consume es6, that the library authors will agree to actually publish ES6 as the main npm artifact of the library.

Solution Part 1 - Transforming node_modules

The crux of the problem is that the current class of compilers (we’ll use Babel as the example considering its prominence) don’t touch node_modules by default. Unless you explicitly tell Babel to, it won’t compile your node_modules. There’s good reason for this. 3rd party node_modules are all already valid es5, so running the compiler on them are effectively no-ops, and it slows your build to attempt to compile something that doesn’t need it! Also, because Babel isn’t just a JS to JS compiler and it in fact has a rich plugin ecosystem and you may be using experimental proposals in your code or React transforms in your code, running those transforms over node_modules doesn’t make sense either.

With this understanding, let’s take a step back now and imagine what we’d want Babel to do to enable the ecosystem to move onto es6:

Allow an app dev to specify target environment (available today as babel-preset-env). That is, an app should be able to say “no matter what version of JS all my code + dependencies are, I want to transform that to whatever version of JS is the lowest common denominator of these browsers / environments”.
Allow an app dev to specify other transforms to run on 1st party (or 2nd party) code. That is, in addition to saying what version of JS the output should be, the app dev should be able to say “my 1st party code is actually JSX, and also, these specific packages in node_modules I rely upon are actually TS”, etc.
Take all known stage 4 transforms (that is, all transforms that cam turn any ES6+ code to ES5), remove the transforms are not required by your target environment, and run those over all node_modules that aren’t already handled by step 2 above.

This would means that library authors who are using TS or Flow or JSX still have to transpile to JS, but not necessarily ES5! The library author becomes free to publish ES6 on the knowledge that prevalent tooling will downlevel their JS to the correct target.

Now, from a correctness perspective, I think this’d work, but how do we address build performance issues? As mentioned above, suddenly compiling all node_modules will definitely slow down builds. If library authors were willing to publish a machine readable file announcing what version of JS they are, similar to the “engines” field of package.json, Babel would be able to bail out of transpiling if it could determine that the library is a version of JS that is less than or equal to the version required by the application. In fact, Babel could theoretically produce this file. It could have a mode where instead of actually transpiling to es5, it just notes what transforms would not be no-ops and write those to a file, to be consumed by a future run of Babel later. For simplicity’s sake though, perhaps it’s simpler to write “ES2019” than “polyfill Array.flat, and run all ES2018 transforms, and...” This file would also help detect if the JS version of the library is a version that your version of Babel doesn’t yet transpile, and can warn the application dev to upgrade.

Solution Part 2 - ES6 Readiness Day

With Babel and the other compilers now behaving as described, we’d set our sights to library authors. How do we get them to stop shipping ES5, now that the compilers can help out here?

While we may think of npm as a vast sprawling treasure trove of dependencies at our fingertips, in reality, there are some really really common dependencies out there that make up a huge percent of what gets shipped to browsers these days: https://www.npmjs.com/browse/depende

If we could convince the top most depended on packages to switch, couldn’t we say we achieved the mission?

Thankfully, there is prior art... “Can I Use Python 3?” This is what happened with Python 3. Python 3 was a huge jump from Python 2, and for years the community was frozen on Py2 because very popular packages weren’t shipping Py3 yet. The community eventually banded together and began publishing websites that simply listed the top Python packages and whether they yet supported Py3: http://py3readiness.org/ https://python3wos.appspot.com/

Perhaps as a community, we could do similar... armed with buy in from the compiler ecosystem and a single request “please ship es6 instead of ES5, and the compilers will downlevel for you if necessary”, we throw up a site that tracks progress towards this goal for the top 500 npm packages. We set a date to shoot for. We declare Jan 1st 2020 (or some more reasonable date) as the date to strive for 50% (or some more reasonable percent). Of course, you can probably just get a commitment from the top 20 and a handful of profilic publishers and that’d be a huge head start :-)

Putting it All Together

In summary, if we first made sure compilers could transform any version of actual JS in node_modules (stage 4 syntax w no custom transforms) to the version required by the app dev, it unblocks library author’s ability to now publish in es6 without making app devs jump through configuration hoops to get a dependency. If we also provide a common format for libraries to declare the version of JS they are, we can overcome build speed issues. With that unblocked, we socialize the goal and get public commitments from top lib authors to move to es6 on an aspirational timeframe. Hopefully one day soon, downleveling to ES5 will seem as unnecessary as downleveling to ES3!

It would involve getting broad support from compilers (not just Babel, but also pika, Buble, Typescript, And others, along with maybe installers like Yarn or npm), and top package authors, and community advocates to band together. It wouldn’t be easy, but if we got agreement, it would work.

Of course, there is some nuance missing in the descriptions above, but as an overall strategy, this seems like a clear way to move the ball forward that isn’t “just wait for IE11 to die.” Because even then, with the ES5 cliff behind us, there will always be future cliffs, even if they are less severe.

Thoughts?

In Defense of the 10x Developer

Mike Sherov — Thu, 10 Dec 2015 00:00:00 +0000

One of the most persistent software development memes is making fun of recruiter-speak. You know, the type of language used by the clueless recruiter trying to communicate a challenging role. “This company is looking to hire a real ninja.” Or “rock star developer”. Or “10x developer”. It’s obvious to me that both “ninja” and “rock star” are embarrassingly aggressive and brogrammy terms to apply to the craft of software development, but “10x” seems like it’s worthy of a second look.

10x the Features?

At its roots, those who ridicule the concept of a 10x developer are interpreting 10x to mean 10x the amount of features or code. “Yeah, right, 10x! More like 10x the technical debt”. Seems like that joke at its heart is an insult to both the developer who thinks their only measure is their code output, and whoever that poor sap’s manager is, who’s actively using LOC or feature output as the only measure of success. That’s not what I’m defending. If you work somewhere where your only measure is feature output, quit yesterday. By all means. For the rest of us who have competent managers who view us holistically…

10x the Impact?

Another common attempt at deriding the 10x developer concept goes like this: “Really, it just happens to be that senior staff get chosen to work on more important stuff than juniors, and therefore, 10x devs don’t exist as much as 10x projects do”. This is certainly true, at least to some level at all companies. However, again, if you work in an org where there isn’t enough important work for everyone, and only the senior team can do the work, quit two days ago. The codebase should be well tested so you can practice collective ownership and business should get its priorities straight so that there aren’t wild discrepancies in importance for everyone.

10x the What?

If I’m not talking about LOC (or any other braindead metric for measuring software “output”), and I’m not talking impact, then 10x what? What is the 10x developer 10x better at than her colleagues? Quite simply: raising the effectiveness of those who sit around her. A true 10x developer helps her teammates accomplish their goals. A 10x developer takes the time to communicate challenges and solutions she encountered during the day so that her teammates may learn something new. A 10x dev gives thorough code reviews, talks face to face with the submitter of each PR to discuss best practices. A 10x dev makes tools the rest of the team uses. The joke I’ve heard to describe the 10x dev goes like this:

To be a 10x dev, make 5 2x devs.

If you are a 10x dev, it’s on you to make sure you’re working somewhere that can see it, nurture it, and get you on the road to being a 100x dev.

Conclusion

If you measure yourself, or worse, if your boss measures you by features built or LOC, quit.

If the seniors get all the glory because they’re the only heroes who get to work on high impact stuff, quit.

If you’re surrounded by 2x developers, chances are you’re a 10x developer. Make sure you work somewhere that recognizes that.

Shipping is Your Primary Feature

Mike Sherov — Wed, 01 May 2013 00:00:00 +0000

I’ll keep this one short and sweet, and just say this: The most important feature that your software can have is that it’s in the hands of end users. That’s where features are truly fleshed out through actual use.

Although I disagree with some of the points in the article, I can’t say it any better than Jamie Zawinski as quoted by Joel Spolsky in The Duct Tape Programmer (interesting article, about 5 minutes to read): “ But that’s not the point — you’re not here to write code; you’re here to ship products. ”

Idea for the day: remember YAGNI (You Ain’t Gonna Need It)

Writing Clear Code, Not Clever Code

Mike Sherov — Sun, 15 Apr 2012 00:00:00 +0000

In Practices of an Agile Developer, Andy Hunt and Venkat Subramaniam outline a huge list of ways to improve yourself as a software developer. While I found almost every tip in the book to be useful, I found one tip to stand out from the rest, considering it pointed out one of my particularly bad habits: “Write clear code, not clever code”.

One of my passions as a programmer is figuring out new and better ways to do the same thing. I love refactoring code and finding out what was being done in 10 lines, I could do in 3. Or as a better measure, doing something with one if else block instead of a triply nested if else statement. Usually this works out great. The code is simpler to maintain, and less complex for all involved.

However, in my endless pursuit of smaller, clearer code, I would often end up with smaller, more confusing code. In 2009, as a member of a 7 person agile team, it was very easy to measure how I was doing in this category: How often did another team member ask me what a piece of code did? Once I began looking at these problematic blocks of code, I noticed a pattern, and began to work on resolving the problem. It doesn’t matter what my particular problem was… what mattered was that I began looking for it!

Pay attention to your team members. Look into why they’re asking you about your code. Maybe there is something you do that makes perfect sense to you, but could be written clearer. Consider the next person who’s going to be looking at your code. Chances are, they’ll be happier looking at clearer code, not clever code. You’ll be happier too.