• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar

Dion Almaer

Software, Development, Products

  • @dalmaer
  • LinkedIn
  • Medium
  • RSS
  • Show Search
Hide Search

Archives for December 2017

Gearing up the Web for 2018

December 29, 2017 Leave a Comment

It’s the time of year when you reflect and refocus. With the recent news of Edge and WebKit bringing service workers to their people, it is hard not to reflect on the long journey of bringing rich, some may say app-like, capabilities to the Web.

❗️It's like we got huge present from web platform this holiday🎁

Safari Technology Preview release from @webkit says
"we’re excited to enable Service Workers by default in this release. Please test our implementation with your websites"
🎉🎉🎉https://t.co/tINheFZSzv

— Chrome Developers (@ChromiumDev) December 20, 2017

With 2017 sunsetting (in some ways: good riddance!), I thought back ten years to 2007. You may remember the simpler times where Arnold was the Governator in California, Mad Men and Flight of the Conchords were on the scene, and Steve Jobs showed us his new phone.

In the world of the Web, I was working on Google Gears.

Any excuse to get the zipper image back!

This was a pre-Chrome world where developers who were trying to bring bleeding edge desktop web apps (Gmail, Google Docs, etc) often reached to a browser plugin to deliver the functionality that they needed (Flash and Silverlight). We were seeing a resurgence in using HTML/CSS/ and JS to power the UI, using plugins to get access to some native capabilities — Remember XMLHTTPRequest was born as an IE ActiveX component.

Picture yourself with a Gmail that nailed spam and search so well that Eudora was tossed aside. One restriction though was the reliance of a tether to the Internet. A next obvious step was to take Gmail offline (including that great search!) and improve all of the perf (always an issue ;).

Gears brought us the modules to do just this, and it is fascinating to see which primitives we ended up with:

  • A Database module (powered by SQLite), which could store data locally
  • A WorkerPool module, which provided parallel execution of JavaScript code
  • A LocalServer module, which cached and served application resources (HTML, JavaScript, images, etc.)
  • A Desktop module, which let web applications interact more naturally with the desktop
  • A Geolocation module, which let web applications detect the geographical location of their users (Google Maps any one!!!)

How many of these are still needed to pull off a great web experience, worthy of the home screen addition from a loyal user, even as we have moved to mobile and beyond?

But a browser plugin wasn’t the ideal solution. You want the platform itself to grab onto good ideas and bake them in (hopefully learning from the implementations to come up with something much better). Also, 2007 remember….. with Safari on iPhone, and Jobs said “nope” to the plugin world (and thus the fall of Flash and Silverlight).

Let’s take a peak at the problems we were solving and what the solutions we now have available, with the new context of mobile, and where we can be heading in 2018!


Dealing with data

The Gmail team dealt with much pain on the bleeding edge as everyone worked out how to store (sometimes large amounts of) data correctly locally and sync it with the backend.

We quickly codified SQLite into the platform via WebSQL, which didn’t quite stick. There were issues with baking in an implementation into a standard, but I also wonder how much gas was lost from the effort because the world jumped into a “NoSQL” bandwagon. The many benefits of SQL have held the test of time, and with new innovations such as Spanner, I do sometimes wonder if it wouldn’t be kinda great to have SQL back in the client toolbox?

Instead we got the likes of DOMStorage and IndexedDB, as well as many solutions on top of our primitives. Today we see a lot of usage of Firebase (including the new Firestore which has offline support on the Web!) and there is also large mindshare in the GraphQL space, with great clients such as Apollo.

So, we have a lot of work going on with respect to data, both on the client and how to sync back to the backend, but I think we will see new patterns emerge in 2018 that will put everything together.

Working off thread

As we constructed richer applications through JavaScript, and accessing local capabilities like databases, we needed to be able to do this work away from the UI thread, else the apps became unresponsive. Thus, Gears brought us WorkerPool, which was morphed into the Web Workers standard.

Doing less work on the main thread continues to very much be a key bottleneck, especially in a world of low power CPUs! Phil Walton just posted on this from the vantage point of interactivity, and the lack thereof, and we have exciting work landing and in process.

Browser vendors are hitting this head on in their implementations, with large architecture changes (e.g. Quantum has a lot of this baked in) as well as tactical upgrades (e.g. image decoding happening elsewhere).

We are also seeing new standards that bake new abilities, from tweaks such as img decoding, and large additions such as the awesome Animation Worket that will truly change the game.

When it comes to new capabilities, we often follow the pattern of:

  • Step one: make it possible.
  • Step two: make it easier.
  • Step three: make it perform.

This is one reason I got excited about Surma’s exploration: COMlink, that gives you the same API across windows, iframes, Web Workers and Service Workers — speaking of which….

A Local Serv…ice

The browser was built as a client desktop application that sat on a nice fat university pipe. I remember that world fondly, where I had an Sun Ultra as my workstation, and I could also login to any machine on campus and have my X windows show up just they were.

The network was never perfect, but as it diversified, and our devices walked around with us, we needed to handle the lack of network progressively. The Gears LocalServer module came with a couple of cool features. One of them was the Gears JSON manifest file, somewhat akin to AppCache, that allowed for a declarative approach. Declarative APIs are great until you need to break out of the box. In that case you long for an imperative API that the declarative one builds on. LocalServer gave you a programatic API too, but it was much more restrictive than what we have today in the powerful Service Worker, where you get to fully own the networking layer. With this power comes great responsibility and is one that you need to think through up front, making sure that you have the correct kill switches in place, and processes to fully test.

Service Workers were a perfect example of the Extended Web in action. A powerful building block for us all to build on top of, including the web platform itself, as we have seen with Web Push and friends.

Native capabilities

When the Web is at its best, it allows you to reach the broadest set of users, but also allows them to experience it on their terms. This is why a UI change to make image picking better (often feeling more akin to other image picking on that particular device) can have a large impact. It is also why I have been a fan of extensions, allowing users to customize to break out of the A/B optimizing machines.

Gears had a Desktop module that allowed you to drop an icon for your web application that could now serve locally and store data via SQLite.

Home screen access is even more important in the world of mobile, so that is where we first saw this support via the Add To Home Screen API. This doesn’t mean that I don’t want it on my desktop too though, and I look forward to great desktop PWA support in 2018!

Gears drove some of these native capabilities, and in general I like to see developers being able to push the boundaries, and having the platform standardize the good ones later. This is one reason that I keen to see how developers use Trusted Web Activities, which gives you the ability to bridge native and Web in a new way.


Now we have seen how the specific Gears modules have baked themselves into the core platform. It is also interesting to look at the areas that weren’t a focus then, and how we are now going well beyond the issues of the day.

The Google Apps of the day were large codebases. Throngs of JavaScript were being flung, and Closure was the weapon of choice to keep the codebase sane. We got through the ES4 detour, and I am happy to see that with ES2015 we have put our requirements into the language versus comments.

Layout wasn’t as much fun back then. Without Flexbox, we had to result in a lot of tricks that required JavaScript, and we had to manually (read: use a lot of resources :/) check on what was in view versus using APIs from the Observer family (Check out Eric’s examples of the new ResizeObserver addition!).

These days we not only have Flexbox in the toolbox, but we also have the fantastic CSS Grid, and one fun way to master it is by “playing” with Dave’s Grid Critters.

https://mobile.twitter.com/trueadm/status/944908776896978946

When it comes to bringing capabilities wrapped up in native code, we now have WebAssembly at our finger-tips. I am particularly curious to see what gets wrapped and made available for the masses.

And what better way to do the wrapping that via Web Components. We have long dreamt of the ability to reuse rich UI components that were fully tested and had high quality accessibility support. It used to be frustrating to see an amazing YUI widget, that you couldn’t bring into Closure land. We are finally getting to the point where this is no longer an issue, and with SkateJS, Stencil, and Svelte joining Polymer and friends, we can share and compile like never before, and it is starting to feel like 2018 is the year of the Template Literal Libraries.

When you put this together, we can have the semantics of <something-cool> that could be wrapping rich UI and WebAssembly code under the hood.

We still have much to do, but the pieces are coming together to deliver rich experiences that can be constructed and combined by creators. In a world where we seem to spend more time consuming, I sincerely hope for 2018 to be a turning point for more of a read/write Web, and world.

Not only are we seeing the features come to light, we are seeing browser vendors coming together to implement them with haste, a huge difference from the time of Gears and ChromeFrame.

So, here’s to more green in 2018, something that I was excited about in the Chrome DevSummit keynote that I got to give with Ben:

I am curious to hear what you are looking for in 2018. It has been a lot of fun to read existing thoughts from the various end of year countdowns, and a big thanks to Mariko for inviting me to write this for http://web.advent.today/!

Can Syntactic Sugar be Nutritious?

December 11, 2017 Leave a Comment

When it comes to nutrition and food, there is nothing that we vilify more than sugar, as we find out how wrong we were with fat. As programmers, we often poo poo syntactical sugar, but two interactions that I witnessed reminded me look deeper.

The two stories were of Kotlin and ES6.

Once you kot, you can’t stop

Let’s start with Kotlin. There has long been excitement with the language, and when we announced our support at Google I/O there was a huge cheer, as this signaled that, not only will we not be doing anything that could harm Kotlin support, but that we would invest in making it great. Java isn’t going away, but everyone knows they can safely dig into Kotlin. I would go even further and say that you should at least be playing with it. Many top apps have been using it in production for some time, but if you aren’t quite ready for that, look for other areas to get your feet wet such as writing unit tests to get a feel.

Pat still wasn’t sold. Why bother with a new language? Functionally what can it do that can’t be done with Java? What about finding knowledgable engineers? Or the fact that we don’t have as much documentation for it yet? At a high level this is logical, but then something happened. Pat tried it, and after a weekend of hacking with Kotlin realized how productive and fun it was. As often happens, the expectation bar rose and it meant that going back to the verbose Java code seemed…. old fashioned. Less code, fewer NullPointerExceptions, and new libraries got the juices flowing in a new way, and it didn’t hurt that Android Studio was a nice helper along the way.

I don’t need no stinking classes

Devyn saw ES4 come and go. After years of working with JavaScript, with The Good Parts on the office desk, the notion of prototypical inheritance was a huge feature, and there was no need for class syntax.

CoffeeScript came around, and although Devyn actually liked many of the features (arrow functions, the role of spaces, rest…, lexical scoping) they never seemed worth the cost.

Then we started to see changes in JavaScript itself via ES6/2015, and Devyn was still skeptical. Do I really want to use babel in my flow and set things up for older browsers? Once again, a coworker pleaded with the TL to give it a go on a small project. Fast forward a couple months and Devyn is one of the biggest proponents on the team. When asked why, a huge turning point was the road from callback city, to promise mountain, to async/await lake. Finally, it was all making sense.

const makeRequest = async () => {
  try {
    // this parse may fail
    const data = JSON.parse(await getJSON())
    console.log(data)
  } catch (err) {
    console.log(err)
  }
}

Say what you mean

All of this was wrapped up in our project’s mantra: “say what you mean”. —Alex Russell

With this cleanup, we are moving developers closer to the point where they can cleanly say what they mean, without scaffolding getting in the way. Gone is some of the verbosity, and we can huffman encode things that we use all the time.

  • Don’t function make me function in my function chain
  • With custom elements we can get away from div div div divitis
  • Not having type information shoved in your face all the time gives your code space to breath (Dion (a Person) went home (a House))

It turns out that paper cuts really do matter. Speaking of types, one area that ES2015 has stopped short on is optional types, leaving room for TypeScript to become yet another example of something that many developers thought they didn’t want. Casey thought types only get in the way, and pattern matched “types” to “the way Java does types” (static, strong, and traditionally in your face), which happens far too often.

We have had myriad attempts of adding types in a variety of ways (beyond ES4). The Closure Compiler was one version, which has always been a phenomenal tool (to this day it normally beats the pants off of other tools when it comes to final code), but I always did a lil body shake when seeing context in comments:

/** @const */ var MY_BEER = ‘stout’;
/** @typedef {(string|number)} */

Pragmatic. But I admit to a preference of getting optional types into the language itself. Ideally even without type erasure!

One of the features in TypeScript that really tickles me is String Literal Types which allow you to get the benefit of enum without having to create enums.

String literal types allow you to specify the exact value a string must have. In practice string literal types combine nicely with union types, type guards, and type aliases. You can use these features together to get enum-like behavior with strings:

type Easing = “ease-in” | “ease-out” | “ease-in-out”;

Language features can often get rid of the need for more verbose patterns. These allow you to get around, or change fashion.

One fashion that comes to mind was when fluent APIs hit the scene hard with the growth of jQuery. I often like the way a chain looks, and they are very natural in the functional world, but when writing an API that has `return this` throughout feels a lil bit smelly to me at this point.

Dart fixes the itch without you needing to return this. Their cascade feature gives you the same flow and ability to ditch the object name shouting at you:

querySelector(‘#confirm’) // Get an object.
  ..text = ‘Confirm’ // Use its members.
  ..classes.add(‘important’)
  ..onClick.listen((e) => window.alert(‘Confirmed!’));

// and with nesting
final addressBook = (new AddressBookBuilder()
  ..name = ‘kris’
  ..email = ‘kris@example.com’
  ..phone = (new PhoneNumberBuilder()
    ..number = ‘123–456–7899’
    ..label = ‘home’)
    .build())
  .build();

Is this all nitpicky? Do you enjoy being on the flip side once you get there?

On the one hand, the hard part isn’t the syntax. If you understand the Android lifecycle thoroughly, you are good to go… picking Kotlin will be a (fun) breeze. On the other hand, your language is your expression, and you live with it for hours a day.

As I become more curmudgeon-y with age, I am trying to remember: at least give something a try before I come to a strong held belief.

I am much happier to have modern ES6/TypeScript, Kotlin, and Dart 2.0 to play with in 2017, and I look forward to more improvements, and richer support, in 2018. Some sugar over the holidays is OK isn’t it?

Primary Sidebar

Twitter

My Tweets

Recent Posts

  • I have scissors all over my house
  • GenAI: Lessons working with LLMs
  • Generative AI: It’s Time to Get Into First Gear
  • Developer Docs + GenAI = ❤️
  • We keep confusing efficacy for effectiveness

Follow

  • LinkedIn
  • Medium
  • RSS
  • Twitter

Tags

3d Touch 2016 Active Recall Adaptive Design Agile Amazon Echo Android Android Development Apple Application Apps Artificial Intelligence Autocorrect blog Bots Brain Calendar Career Advice Cloud Computing Coding Cognitive Bias Commerce Communication Companies Conference Consciousness Cooking Cricket Cross Platform Deadline Delivery Design Desktop Developer Advocacy Developer Experience Developer Platform Developer Productivity Developer Relations Developers Developer Tools Development Distributed Teams Documentation DX Ecosystem Education Energy Engineering Engineering Mangement Entrepreneurship Exercise Family Fitness Founders Future GenAI Gender Equality Google Google Developer Google IO Habits Health HR Integrations JavaScript Jobs Jquery Kids Stories Kotlin Language Leadership Learning Lottery Machine Learning Management Messaging Metrics Micro Learning Microservices Microsoft Mobile Mobile App Development Mobile Apps Mobile Web Moving On NPM Open Source Organization Organization Design Pair Programming Paren Parenting Path Performance Platform Platform Thinking Politics Product Design Product Development Productivity Product Management Product Metrics Programming Progress Progressive Enhancement Progressive Web App Project Management Psychology Push Notifications pwa QA Rails React Reactive Remix Remote Working Resilience Ruby on Rails Screentime Self Improvement Service Worker Sharing Economy Shipping Shopify Short Story Silicon Valley Slack Software Software Development Spaced Repetition Speaking Startup Steve Jobs Study Teaching Team Building Tech Tech Ecosystems Technical Writing Technology Tools Transportation TV Series Twitter Typescript Uber UI Unknown User Experience User Testing UX vitals Voice Walmart Web Web Components Web Development Web Extensions Web Frameworks Web Performance Web Platform WWDC Yarn

Subscribe via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Archives

  • February 2023
  • January 2023
  • September 2022
  • June 2022
  • May 2022
  • April 2022
  • March 2022
  • February 2022
  • November 2021
  • August 2021
  • July 2021
  • February 2021
  • January 2021
  • May 2020
  • April 2020
  • October 2019
  • August 2019
  • July 2019
  • June 2019
  • April 2019
  • March 2019
  • January 2019
  • October 2018
  • August 2018
  • July 2018
  • May 2018
  • February 2018
  • December 2017
  • November 2017
  • September 2017
  • August 2017
  • July 2017
  • May 2017
  • April 2017
  • March 2017
  • February 2017
  • January 2017
  • December 2016
  • November 2016
  • October 2016
  • September 2016
  • August 2016
  • July 2016
  • June 2016
  • May 2016
  • April 2016
  • March 2016
  • February 2016
  • January 2016
  • December 2015
  • November 2015
  • October 2015
  • September 2015
  • August 2015
  • July 2015
  • June 2015
  • May 2015
  • April 2015
  • March 2015
  • February 2015
  • January 2015
  • December 2014
  • November 2014
  • October 2014
  • September 2014
  • August 2014
  • July 2014
  • June 2014
  • May 2014
  • April 2014
  • March 2014
  • February 2014
  • December 2013
  • November 2013
  • October 2013
  • September 2013
  • August 2013
  • July 2013
  • June 2013
  • May 2013
  • April 2013
  • March 2013
  • February 2013
  • December 2012
  • November 2012
  • October 2012
  • September 2012
  • August 2012

Search

Subscribe

RSS feed RSS - Posts

The right thing to do, is the right thing to do.

The right thing to do, is the right thing to do.

Dion Almaer

Copyright © 2023 · Log in

 

Loading Comments...