Skip to content

Instantly share code, notes, and snippets.

@addyosmani
Last active November 14, 2017 13:11
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save addyosmani/0d95f754d7b10ab465512020d75aaf66 to your computer and use it in GitHub Desktop.
Save addyosmani/0d95f754d7b10ab465512020d75aaf66 to your computer and use it in GitHub Desktop.
blinkon7 - rough discussion topics

Frameworks and tooling

ES2015 Modules.

How do you deploy them? What does this look like for Blink + Babel, frameworks? We've got nomodule coming. This looks like:

<script type="module" src="app.js"></script>
<script nomodule defer src="bundle.js"></script>

Is it realistic for someone to deploy code this way by the end of 2017? What are the benefits of doing so? Are there any? If Blink optimises modules, is the best-case that they're still only as fast as ES5 <script>? If not, is nomodule even useful?

What if we think about it as nomodule bundle is your transpiled 'legacy' bundle for older browsers? Maybe that becomes more useful. So your <script type="module" src="app.js"> is your raw ES2015+ code in ES module format and your legacy bundle contains transpiled ES2015. The trickiness here is ensuring the browsers hitting the type=module path have a complete implementation, but a partial one.

TIL Safari has already implemented nomodule in addition to their import() and modules support.

There's also a discussion to be had around what all of this even means for components you're writing that are distributed through npm.

preset-env

What do we need to do to make this a thing in 2017? Usage numbers growing, but it would be great if more people shipped only transpiled features that were needed. Modern browsers have pretty good support otherwise. Anything we can do to bake these in to [framework]-cli for each framework?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment