When in doubt, trust the browser

Presented at Fronteers, Dec 12 2019 at De Kien, Kortrijk.

As a front-end developer, you're always confronted with making choices. In this talk I cover the benefits you get for free when considering W3C standards or standard browser API's instead of reaching for the latest framework or library.

This was a test run of a more theoretical talk I want to base on this. Any feedback is very much appreciated.

Transcript

1. When in doubt, trust the browser
2. I'm Pieter Beulque Front-end Developer
3. Show what's possible without the trusted npm install Goal of today
4. Let's build a tweet embed
8. Let's start!
9. Custom Elements Defining a re-usable component
10. Custom Elements Create your own <html-elements> Progressive enhancement dream Initializes whenever a node is added to the DOM Anything is possible!
14. Custom Elements There's a very good introduction on Google Developers' Web Fundamentals
15. Shadow DOM King of the castle
16. Shadow DOM Isolate component's DOM Scope component styles
17. Shadow DOM Isolate component's DOM Scope component styles
19. <header> <footer> <section>
23. Also <header> Also <footer>
24. Shadow DOM :host <slot> & ::slotted()
25. Shadow DOM :host
26. Shadow DOM <slot>
27. Shadow DOM
28. Shadow DOM There's another very good introduction on Google Developers' Web Fundamentals
29. Browser support Both can be polyfilled: github.com/webcomponents/polyfills All evergreen browsers Edge starting January 2020 No Internet Explorer
30. Use it in production?
31. Custom Elements Yes, but… Have been using it for 3 years Has its limitations Wouldn't use it for applications
32. Shadow DOM You could, but… Falls short compared to frameworks Feels clunky
33. My thoughts Great to sprinkle Javascript on top of content websites More accessible out of the box than a everything-in-JS approach Probably run into limits when using for applications
34. North star Custom Elements as a compile target ✨ Stencil & Svelte already support this.
35. Let's move on
38. Internationalization API Intl.RelativeTimeFormat
39. Internationalization API Format dates, numbers and plurals The browser already has all languages Your browser knows your user's preferences
40. Internationalization API new Intl.RelativeTimeFormat( 'en', ).format( value, unit )
41. Internationalization API new Intl.RelativeTimeFormat( 'en', // Any valid locale ).format( value, // A number, positive = future, negative = past unit // 'months', 'days', 'years', … )
42. Internationalization API new Intl.RelativeTimeFormat('en').format(1, 'day') in 1 day new Intl.RelativeTimeFormat('nl').format(-1, 'year') 1 jaar geleden new Intl.RelativeTimeFormat('fr').format(0, 'month') dans 0 mois
43. That's not very human new Intl.RelativeTimeFormat('en').format(1, 'day') in 1 day new Intl.RelativeTimeFormat('fr').format(0, 'month') dans 0 mois
44. That's not very human new Intl.RelativeTimeFormat( 'en', { numeric: 'auto' } ).format(1, 'day') tomorrow ce mois-ci new Intl.RelativeTimeFormat( 'fr', { numeric: 'auto' } ).format(0, 'month')
45. Browser support There's a polyfill from Polyfill.io: github.com/andyearnshaw/Intl.js/ Chrome, Firefox and Opera No Safari No Edge or Internet Explorer
46. Use it in production?
47. Internalization API Definitely! Save bandwidth on translation files All edge cases handled automatically Locale 'default' uses your user's preferences
48. 1 + 1 = 2 Let's recap
49. Let's build a reusable, standalone component that turns a time into a human-readable, relative time
56. Define attributes to watch for changes Run the formatter on every change
57. Define attributes to watch for changes Run the formatter on every change
58. Zero dependencies. Self-contained. Re-usable. 20 LOC.
59. OK, I cheated a little. The code that calculates the date difference adds another 30 lines.
60. All in a single file?
61. ES Modules Do you really need a bundler?
64. The browser knows what to do.
65. Browser support Everywhere but IE & UC Browser Serve bundle as a fallback, thanks to nomodule
67. Progressive Enhancement is beautiful And browsers are amazingly good at it.
68. Use it in production?
69. ES Modules Yes, with caution Definitely needs HTTP/2 No problem for small amount of modules Watch out for huge dependency trees
70. North star ES Modules as a bundling target ✨ Rollup & Parcel already support this.
71. One more thing
72. Built-in lazy loading Unofficial, Chrome-only
73. So remember…
74. When in doubt, trust the browser
75. Thank you! Questions? @pieterbeulque