• 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 October 2016

It’s Game Time for the Web

October 24, 2016 Leave a Comment


I hope you watch Alex’s latest presentation showing how the computer in your pocket massively under performs due to the fact that the battery size limits how much we can fully utilize what is available, especially when married to the fact that there are major issues of heat dissipation and the fact that some of the tricks that the OS employs (e.g. boot up the cores when launching an app) don’t fully apply to loading a new web app within a browser.

Just as he sciences the shit out of the mobile devices that our users have and their constraints, we need to do the same as web developers on doing everything that we can to build experiences that work.

I mentioned in my own talk this week that I feel the Web is still evolving from the world of desktop apps to mobile. The browsers are ahead of the pack, getting a lot of optimizations around how to work in that environment. With Progressive Web Apps we have gotten the key capabilities we need to be mobile native, with more coming there too. But what about our frameworks and other end user code? Sometimes it feels like Alex is being “anti-framework” when he pushes on what he is seeing in the real world, but take a closer look. He isn’t ranting about particular frameworks, he is just frustrated to see the common outcomes where grabbing a framework these days often doesn’t end with a great experience out of the box.

The frameworks that we have also have to be optimized for the same mobile constraints, and we need to build new patterns. The good news is that this has been happening. The first real PWA was Flipkart’s mobile commerce app, and it is very much React. They just made sure that they optimized it for mobile performance, and continue to do so. A large reason for Angular 2 to exist was to re-think core pieces to allow for good mobile performance. And of course Polymer did the same, resulting in examples such as Shop that have traces good enough for Alex to cry a tear of joy.

Our priority is mobile performance

The Web is such more than just mobile, but the core existential threat lies here right now. If you can’t paint something quickly and then become interactive shortly after the user may have already moved on. Your mission is to get a first load going in 3 seconds on 3G, and it’s hard. If the user is coming back again you have hopefully gotten a service worker up and running and you can get down to 500ms, especially if you can use data from the cache first while you wait on fresh data from the network.

Given that this is our mission, and it is a real challenge, we need to use as many tricks and illusions as possible. Smoke and mirrors are time honored tradition in computing, both for users and for development. A user doesn’t need to comprehend that the computer is running through a slew of tasks and only repainting the cursor at the last minute before the user would notice. A developer doesn’t have to concern himself about the assembly that is running, or the physical work that is being done as they read from a socket. These abstractions allow us to get closer to the user and build things at the right level of complexity.

The power of build and deploy time abstractions

One of the great things about the early web was its simplicity. You could throw up and edit some <markup>, hit refresh in the browser, and iterate away. There is something so alluring to this, and whenever we put build steps between our source and deployed artifacts people get queasy. But why?

Development iteration time

if it takes real time to go from hitting save in your editor and being able to see and work with the changes you will not be able to stay in the flow. Over time though we have built tools that not only make the time short, but allow for hot deployment so you don’t even need to always refresh your experience and navigate to where you were.

Debugging

When something is going wrong you need the illusion of seeing the problem in your source artifacts. You can’t troll through obfuscated craziness and manually tie back to the source. With tools such as source maps we get to solve these important problems.

So, while I love the idea of making quickly changes to HTML, CSS, or JavaScript and not having tools doing too much magic in between, I am sorry, for where we are right now I think that we need to embrace build and deploy tools even more.

Why would I want this abstraction that gets in the way? Do hard work where you have time. The Web is in an extreme situation. When you send down your first page load the browser has to bootstrap a lot in a short time window:

  • Download resources, finding and getting dependencies
  • HTML => DOM
  • CSS => styling and layout
  • Evaluate and execute JavaScript
  • and much more

Oh, and it has to do this progressively as information is streaming in (which is also the blessing that means that if we don’t fight the platform we can get AMAZING performance).

The fact that the browser has to do this all so quickly means it has to make real trade offs. Think of an image compressor or a compiler. With those tools you can choose the level of optimization based on the trade offs that you want to make. When in development you are looking for compile speed, and for debugging symbols to be available. For a production build you would happily let the computer crunch like crazy because the time that you have is basically infinite in comparison.

Why wouldn’t we want to use this time to crunch on our web apps like crazy? This is where we can learn from the world of games. Games is another area where performance is always top of the list, so game engines and developers use as many tricks as possible. They may go ahead and run assets through a pipeline that pre-renders shadows and various formats. They will trade off disk size and duplication for runtime performance in a heart beat.

With the Web we need the tools to optimize for initial load, subsequent loads, and general runtime performance. Thus you can imagine tools doing extra work to get the initial load bundles optimized at the wazoo. You see this with code splitting with tools such as webpack and browserify. It can still be a lil bit of a pain, but if you don’t do this and are lazy (in a bad way) then you end up with a 2+MB bundle.js.

When you are running around a world in a game, the engine only needs to show you what you can see. It wouldn’t make sense for it to render the entire world would it? This is what we need to do in our web apps. We don’t have to preload the entire “world” of the application. Now, we may not want to load up the next part of the app just when the user asks to go there. It could be nice to have the data needed and ready for the room next door, especially if you can predict that the user will be going in there. Prefetching, HTTP/2 server push and other tricks like this can make sure that we are balancing not loading too much at the same time with making sure things are ready for you just in time.

We have some of the tools coming together now, but there is a lot of room to get better and also do more to let a developer work at a nice conceptual level that doesn’t push this baggage front and center. What do I mean here? One of the reasons I think developers like the React style of development is the mental model. Given state in the form of data, when I run through React I get back a certain running application. This style let’s me write really nice tests where I can say “I expect this view tree to come back given this state”. It kinda gets you back to the original web where every click rebuilt the entire world. The user experience hit that took was massive, but it sure was easy for developers to deal with! I am looking for more and more tools that give developers this consistency whilst doing a lot of optimizations behind the scenes.

I sometimes wake up with crazy dreams where the deployment system is smart enough to understand what optimizations to send down to a given browser with the current context. We have used compilers to spit out different versions for various architectures, so we could consider doing the same here. We could even gather analytics, run experiments, and change the deployment bundles based on real world usage (far out there I know). Black boxes can be scary, and when they go wrong that can be frustrating, but given the diversity that we see in the world I don’t see a better way to deal with the problem that giving right in. After all, we can’t expect developers to be able to test on every device, on various os’s, with various browsers, all with various versions, and on global cell networks that are incredibly variable. Human’s can’t solve this problem. We are sending unoptimized crappy experiences to users every day and we can do better.

It may change over time

The severity in the problem with the mobile Web makes me feel like we need to attack this with aggressive build and deploy step solutions. However, this may change over time. You can imagine a future where the entire globe has incredibly fast connections and devices with impressive capabilities for all. It may make sense to then have a world where there isn’t so much of a black box and dev source is much closer to production source. This may happen, or we may always be then just pushing the bar and always be playing some level of catchup where this is somewhat needed. All I know for sure is that we need this right now.

App Stores are different

It is interesting to compare the problem to native mobile platforms. By having the explicit install step we get to bypass some of these issues, but not all of them. It is common to have duplicate assets that need to all first be downloaded and then taking up space. I don’t want 6 sizes of content for various devices and sizes. I don’t want to download various native binaries that I don’t need. And, I really don’t want to download the huge amount of code and assets for $THAT_FEATURE that I never use in the application. We are starting to see better modularization and having app stores only send down what is needed, and I expect to see more of this, even though it adds complexity. The simple “one app with everything we have” approach, which is the default, is akin to the reload web in my opinion…. we will get past it onto a better world.

In conclusion

I hope that you now understand why some of us are speaking so strongly about the mobile constraints and the Web. Fire up Chrome DevTools and do a trace on a real device (Moto G4 + chrome:inspect), run WebPageTest on a Nexus5/Moto G config, and see how you are doing. Run Lighthouse on your application. If you aren’t there yet, take the time to setup your dev infrastructure so it do the hard work to get the experience up to snuff. Your users will thank you, and so will your business metrics.

Spinning a good Yarn with friends

October 11, 2016 Leave a Comment

What's your #yarn #hack? Reply and we will include it in an upcoming blog 🙂 #DarnGoodYarn #YarnHack pic.twitter.com/waGaL5iHmm

— Darn Good Yarn (@DarnGoodYarn) October 10, 2016

I am really excited about Yarn, the new package manager that works with npm (and bower soon) in an optimized manner for JavaScript and the Web.

https://code.facebook.com/posts/1840075619545360

After you `npm install -g yarnpkg` away, do a side by side comparison of installing a module using npm and yarn. Thanks to features such as its caching and parallelism approach you will be happy to see the dramatic speed up.

Then add to that the other benefits such as:

  • Security: checksum packages to verify integrity of packages.
  • Reliability: thanks to the lockfile and deterministic algorithm, installs are guaranteed to be reproducible.
  • Network Resilience: A single request failing won’t cause an install to fail. Requests are retried upon failure.
  • Flat Mode: Resolve mismatching versions of dependencies to a single version to avoid creating duplicates.

It’s a great new tool for us to explore, but what I am actually most excited about is how it came to be.

It's very easy to underestimate the value of coalition building on the web. Ultimately we all share similar goals.

— Tom Dale (@tomdale) October 11, 2016

We somethings see frameworks and corners of the Web community have some NIH going on. Sometimes this has been exacerbated by the fact that the platform has made it hard to interop (e.g. component models) and other times it is due to different opinions.

The Web wins though when we find common ground and work on solving problems together. This is a great example of just that.

You could imagine a world where we had reactpm, emberpm, polymerpm, etc etc. We would throw up our hands shouting FATIGUE. Not this time though. This time members of the community discovered what folks were all working on and decided it would be better for all to collaborate.

I am optimistic that we have the start of a great solution for web packaging, and I also hope that this is the first of many truly community projects across frameworks, browsers, and devs in general to solve our shared problems.

Many thanks for everyone involved in making this happen.

#StrongerTogether 😉

I want to go back to the 1950s of Web Development

October 5, 2016 Leave a Comment


These posts hit a nerve across the community.

Some violently agree, and others argue that diversity is good and that life isn’t that bad!

I find that there is truth to both sides, and it reminds me of folk who talk about the golden era of the 1950s in the US. It isn’t hard to look at the current political climate and long for another time. Remember the white picket fences? Life was so good! Those glasses sure are rosy though, and when you take them off you see a society that had huge problems, some of which we have made important progress with even though we can see that we have a long way to go. Is 2016 really so bad when you look at the data?

There was a time in which we could develop for the desktop browser and reach our users. It was a great time, especially if we put those glasses back on. There was some level of simplicity that was very useful, but what about the fact that:

  • As great as the reach of the desktop web was then, it is a FRACTION of who we can reach globally today
  • We couldn’t bring the Web with us wherever we went, we had to go plug into the matrix like battery sucking animals
  • The browser capabilities were weak, and thus many of the experiences were also far inferior to what we have today. Remember when we were pioneering desktop web apps and the pain we had to go through to make something great across the variable browsers?

The problems that we have to solve now are far broader and the UX bar is much higher. We now have a vast array of form factors and capabilities to deal with and all of this change has happened while we pivot an underlying browser platform that was built for very different purposes.

It has always been hard to do complex experiences on the Web. When I use the frameworks of today, while I understand that there is a paradox of choice, I also feel so grateful.

If I could show Dion Of Web Past time travel debugging, with real user errors coming in that I can capture and clone a version of that world and see what was going on…. opening up Chrome DevTools to see rich information to debug?

We went from throwing up some code to a few servers that we monitored, to a mature world where we have a deep understanding of scaling, A/B testing, rich monitoring, and progressive primitives to allow us to improve our experience using all of the capabilities available to us.

The parts that resonate with me though are still there:

  • The getting started experience is too hard.
  • Going from prototype to production involved a lot of work, littered with choices.
  • The system is evolving quickly under you, with layers upon layers.
  • It needs to be easier to make performant UI.
  • Having something work well on mobile, especially mobile for the next billion users, takes an immense amount of work.

We need to work together as a community to attack these issues and up level us all so we can be productive at meeting “what’s possible”. We are still going through the growing pains of mobile on the Web so it makes sense that there is still much to do across the board.

We need to violently debate as a community, but we also need to push each other here as we can’t wait for one person to make the Web great again, and sometimes I wonder when I see certain storms…. are we missing something bigger?

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...