Five Frontend Things Friday #4

by ✨ Kevin B. Ridgway ✨

Here are five things in the Frontend Engineering world, that I found interesting…

  1. The Mindfulness of a Manual Performance Audit - Chip Cullen over on the always wonderful alistapart.com site says, “As product owners or developers, we probably have a good handle on which core assets we need to make a website work. But rarely is that the whole picture. How well do we know every last thing that loads on our sites?” A good read on frontend performance.

  2. Announcing Storybook 3.0 - Storybook is a really cool UI playground that you can install via NPM, it’s great to test out React components outside of your codebase. They’ve gone 3.0 and that comes with Webpack 2 support among other features.

  3. The Modern JavaScript Tutorial - Ilya Kantor created this cool site that says, “How it’s done now. From the basics to advanced topics with simple, but detailed explanations.” There are some good beginner resources out there for folks, this is a nice intro to advanced tutorial on JavaScript.

  4. CSS in JavaScript: The future of component-based styling - Jonathan Z. White, a JavaScript Engineer at Airbnb writes on his Medium blog, “By adopting inline styles, we can get all of the programmatic affordances of JavaScript.” A good tutorial on the barebones way to do this in React, why it’s a good idea, and he sprinkles in some design tips which I don’t always see in JavaScript articles - I like that he did here.

  5. Redux Logic Flow — Crazy Simple Summary - Trey Huffine on Medium writes, “It seems like every blog post about Redux is thousands of words when all that’s needed is a dead simple example of the logic process to refer to. Thus, I created this crazy simple summary.”

Keep Rising,

Kevin B. Ridgway

Like this list? Want to get it in your inbox? Sign up for newsletter!

podcast

S01E02 - Progressive Web Apps

by ✨ Kevin B. Ridgway ✨

Progressive Web Apps

Progressive Web apps, how we got here, and how to get started.

Going to talk a little about the history of JavaScript applications, and how we got here, and what tools you can use today to start developing Progressive Web Apps.

These applications are accessed via a web browser like other websites, but offer more dynamic interactions resembling native mobile and desktop apps.

  • Speed, time to interaction on the page. Twitter Lite, for example, is interactive in under 5 seconds over 3G on most devices. Most of the world is using 2G or 3G networks; a fast initial experience is essential.
  • Supports notifications
  • Desktop or native mobile app like experience in the browser
  • Responsive web design so appears like an app for any screens size

From a technical standpoint that means:

  • renders in the browser, and responds like more native apps
  • Served from a CDN (content delivery network), static content, and the shell of the application is cached
  • You can have your site work offline, and have background sync, and push notifications
  • The IndexDB API
  • Service worker is a programmable network proxy, allowing you to control how network requests from your page are handled.
  • with web notification API, can notify users like native apps
  • usually client-side routing, so there isn’t entire page reloads
  • obviously async JavaScript requests (AJAX) for loading data without reloading a page

The immediacy of a desktop application and the portability and accessibility of a website.

Fear, Uncertainty, and Doubt

Before 2015:

  • Analytics libraries like Google Analytics required entire page loads to work properly.
    • Between 2009 to 2015, Google Webmaster Central proposed and then recommended an “AJAX crawling scheme” using an initial exclamation mark in fragment identifiers for stateful AJAX pages (#!).

Post 2015:

  • In 2 015, Google deprecated their hash-bang AJAX crawling proposal.
  • don’t believe the hype which I will link to in the show notes
  • That method is officially deprecated. See link in the show notes.

As of 2015 hash-bang urls as they were called, or fragment urls, are out, you don’t need to do this, or use phantomjs to render the site for you at all. You can even use Google Search Console (Used to be called google webmaster tools) to preview how Google would see your site whether it’s a Single Page App or not.

SPAs in 2017

  • It’s really a new term that is coming to the forefront, and more web technologies being considered part of this new term. Mostly being pushed by Google.
  • Let’s talk about the initial checklist
    • same thing, rebranded by Google: https://developers.google.com/web/progressive-web-apps/checklist
      • Site is served over HTTPS
      • Pages are responsive
      • The start URL (at least) loads while offline (using service worker)
      • Metadata provided for ‘Add to home screen’
      • First load fast even on 3G
        • https://developers.google.com/web/fundamentals/performance/prpl-pattern/
        • PRPL is a pattern for structuring and serving Progressive Web Apps (PWAs), with an emphasis on the performance of app delivery and launch. Addy Osmani from Google is spear-heading this pattern, and is looking for feedback.
          • It stands for:
            • Push critical resources for the initial URL route.
            • Render initial route.
            • Pre-cache remaining routes.
            • Lazy-load and create remaining routes on demand.
      • Site works cross browser
      • Page transition don’t feel like they block on network
      • Each page has an URL
    • Exemplary Progressive Web App Checklist
      • Site’s content is index by Google
      • Schema.org metadata is provided when appropriate
      • canonical urls are provided when necessary
      • Pages use the History API; don’t use page fragments (#! hash bangs anymore)
    • User experience: content doesn’t jump when page loads for example
    • Performance: loads very fast on 3G
    • Caching: site uses cache-first networking
    • Push notifications: not being aggressive
    • Additional features: credential management API, Payment Request API

How do I dive in, and get started with PWAs? Start with https://github.com/developit/preact-cli

  • 100/100 Lighthouse score, right out of the box (proof)
  • Fully automatic code splitting for routes
  • Transparently code-split any component with an async! prefix
  • Auto-generated Service Workers for offline caching powered by sw-precache
  • PRPL pattern support for efficient loading
  • Zero-configuration pre-rendering / server-side rendering hydration
  • Support for CSS Modules, LESS & autoprefixer
  • Monitor your bundle/chunk sizes with built-in tracking
  • Automatic app mounting, debug helpers & Hot Module Replacement
  • In just 4.5kb you get a productive environment: preact, preact-router
  • 1.5kb of conditionally-loaded polyfills for fetch & Promise

Go try this out, it’s an npm install away. Then 4 commands to start playing with a Progressive Web App.

Keep Rising, Keep getting better at your craft. See you next time.

—

Resources

You should follow @theriseoffee on Twitter.
Download MP3 (15.9MB)

Five Frontend Things Friday #3

by ✨ Kevin B. Ridgway ✨

Here are five things in the Frontend Engineering world, that I found interesting…

  1. Jumping in: Front-end development from the middle of the project - A must read. Drew Bell, an engineer from Postlight talks about what Front-end development really is, and why it’s nuanced from other engineering disciplines. Couldn’t agree more.

  2. What is the Future of Front End Web Development? - Chris Coyier on his CSS-Tricks takes a stab at what the future holds for us. I’d like to see more pieces like this from folks. Talking about the larger picture, thinking more deeply - and less about the new hotness.

  3. Progressive Web Apps The Right Way - Cody Arsenault from the KeyCDN blog writes, “Since progressive web apps were introduced by Google back in 2015, they have been setting new standards for user experiences. While we are awaiting broader browser support, all developers should start learning how to take advantage of this exciting new way of building apps.” Good intro to progressive web apps, and how to build them.

  4. Anecdotes about frontend and backend engineering - Malte Ubl, Tech Lead of the Google AMP project, describes a situation I’d found between the roles of ‘frontend’, ‘backend’, and ‘fullstack’ engineer. Starting up a new team, I remember how people get very attached to their titles, and technologies. In the end, we should all find places to be experts, to be kind, and communicate well.

  5. UI Component Playbook A 5-step guide to designing and engineering frontends with components - Dominic Nguyen, Product design at Chroma talks about how our frontends are getting more complicated. What should we do? Break the larger UI problems into smaller ones (components), and build them up (into a library) that’s reusable. Starting to see this as a trend towards standard practice.

Keep Rising,

Kevin B. Ridgway

Like this list? Want to get it in your inbox? Sign up for newsletter!

Five Frontend Things Friday #2

by ✨ Kevin B. Ridgway ✨

Here are five things in the Frontend Engineering world, that I found interesting…

  1. JSConf EU 2017 Videos - JSConf is always a high-quality conference with great speakers. Check out their youtube playlist (more videos added daily) of the recently completed EU 2017 conference.

  2. Rearchitecting Airbnb’s Frontend - spoiler alert migrating a large codebase from Rails to SPA (single-page-app) based on React. Great talk of product side decisions, and performance for a SPA.

  3. How we built Twitter Lite - more big players jumping into PWA (Progressive Web Apps) scene. Worth a read to see what they chose to use, and why.

  4. Writing Tidy Code - from Harry Roberts (CSS Wizardry). Been following Harry for a long time, and he always has excellent advice. Love getting into the weeds like this one, in one’s craft. Some would argue that this is silly minutia, I would disagree. If you think of your job as your craft, these things matter.

  5. What the heck is the event loop anyway? - speaking of your craft. Do you know how the JavaScript Event Loop works? If you’re one to think in terms of first principles, this is an excellent talk to watch. Philip Roberts talks about his journey in understanding this core part of JavaScript.

Keep Rising,

Kevin B. Ridgway

Like this list? Want to get it in your inbox? Sign up for newsletter!

Five Frontend Things Friday #1

by ✨ Kevin B. Ridgway ✨

Here are five things in the Frontend Engineering world, that I found interesting…

  1. Prepack - Partial evaluator for JavaScript - From Facebook, a tool for making JavaScript code run faster (early still, not for use in production).

  2. Yes, React is taking over front-end development. The question is why. - Gives a fairly good explanation for this in the beginning, then gives code examples.

  3. Preact.js - Fast 3kB alternative to React with the same ES6 API. If you’re looking for a VDOM implementation without all the abstraction, you must try this out. Been using it for a year or so, and have had many successes.

  4. Javascript Is a Buffet, Not the Enemy - Chris Heilmann - Must see if you’re just getting into JS dev, or you’ve been doing it for 15 years. I think this puts the current ecosystem in the correct light.

  5. Getting started with CSS Grid Layout - Nice list of resources for this new kind of layout system in CSS, that started six years ago as a proposal, and now has landed in latest major browser versions.

Keep Rising,

Kevin B. Ridgway

Like this list? Want to get it in your inbox? Sign up for newsletter!

A Podcast

by ✨ Kevin B. Ridgway ✨

Two ideas smashed together for me recently. One is that The Rise of Frontend Engineering needs a podcast. And second, that I should do the first episode on something I use daily - Chrome Dev Tools.

Credit goes to Justin Jackson of MegaMaker.co. On his latest podcast episode, he talked about how he started the podcast. It clicked for me, I had started a podcast some time ago, that was put on hiatus when my wife and I had our first child. And when Justin talked about his podcast, it made me think, that I know how to do that, and I bet I could get The Rise of Frontend Engineering’s up pretty quickly (30 minutes). I was partly right! (4 hours). So thanks to Justin for the inspiration.

The second thing was that I recently posted a long answer on Stackoverflow about how to use Chrome Dev Tools. I thought, this is something I use every day, and is an invaluable tool for me. I have a lot of experience with it, why don’t I share some of that knowledge? Made perfect sense to do it here.

Check out the first episode of The Rise of Frontend Engineering Podcast

podcast

S01E01 - Chrome Dev Tools

by ✨ Kevin B. Ridgway ✨

A short stroll through Chrome Dev Tools.

Show Notes

Dev Chrome Tools

Disclaimer: Chrome 58 is the version of Chrome/Dev Tools I used when doing this episode. If you are on the stable version of chrome - it’s updated roughly every two-three weeks for minor releases, and every 6 weeks for major releases. So ye be warned, what I may say, where things may be, etc, could change if you’re listening tooth’s in the future.

What is Chrome dev tools?

How do I access it?

  • Select More Tools > Developer Tools from Chrome’s Main Menu.
  • Right-click a page element and select Inspect.
  • Press Command+Option+I (Mac) or Control+Shift+I (Windows, Linux).

Getting Started

Three dots vertically stacked on top of each other.

  • Click on this menu and hover over the three icons that are shown to the right of ‘Dock side’.
  • Choose your poison, personal preference
  • sometimes choose right side, when going into device emulating for example, some people choose the pop out window

Elements

Right click select ‘inspect’

  • Styles panel (double click, and change any value).
  • Computed panel, (double click on the box model picture where there are values, you can change these!)
    • First thing at the top is a visual representation of the box model of the element you selected.
    • You can edit all the values around the box model!
  • Below the box model visual, is a list of the actual computed CSS properties, meaning after all the applied styles, these are the ones that ‘won’, and are applied to the element after the cascade.
    • You can click the ‘Show all’ checkbox, and it will even show you the browser-specific styles applied to the element in question. Meaning you can see what you may need to override to get the styles you want for that element.

Console

  • You can just start typing JS functions, things in global scope are here, and can be called
  • If jQuery is on the page you’re inspecting, for example, you can type $(‘selector’) and it will show that element in the console
  • Hit enter to do command
  • Multi line script you’re typing in? Hit shift+enter to go down a line, but not execute what you already typed in.
  • You are running in the context of the page of you’re on.
    • Type ‘document.body’ hit enter…it’s the html of the page, hover over things here in the console, and see those highlighted on the page
    • You can do things to the webpage here
    • document.body.style = ‘background: yellow’; will show the background of the page you’re looking at with yellow
  • Refresh the page, things are lost, if you’re saving/running things here.

Sources

Where JavaScript can be debugged.

Command or Control P to open file. Any file loaded on the page, image, JS, font, video.

Left panel organized by domain, with the top one being the page you’re looking at in the browser.

  • Next things might be extensions you have loaded in chrome
  • The domain at the top is what your current page is, the other domains below are what assets that may have been included on this page from other domains such as google analytics for example.
  • Can click through folder/file hierarchy here.
  • You can edit this files in place (refresh will blow your changes away), and save them if you choose.

Find a CSS file, click on it. is it all on one line?

  • Click on the curly braces in the lower left hand corner, pretty formatted for you!

You should follow @theriseoffee on Twitter.
Download MP3 (14.6MB)

wonderfulwebpack

Webpack: What are Webpack Outputs?

by ✨ Kevin B. Ridgway ✨

I wrote about what entrypoints are in Webpack. Now let’s talk about outputs of Webpack!

Here is the simplest part of a Webpack config that is only one output:

1
2
3
4
//webpack.config.js
output: {
  filename: 'bundle.js'
}

This is the simplest of outputs; it’s one static name. There are other options that are dynamic that we can talk about in another post. You can read further about output, in the documentation site.

Outputs are simply the static assets that Webpack spits out after processing. These are the things that the browser will load when you link to them in your project. In this case, just one JavaScript file would be loaded in the browser called ‘bundle.js’.