Dion Almaer

Software, Development, Products

Web Development

Slicing through the Web with seamless Portals

On native devices, I find myself naturally following the pattern of:

  • home screen
  • launch app
  • back to home screen
  • launch app
  • repeat

Sure, there are times in which I will bounce from app to app, but it often feels heavy, and most of the time it is an app showing some Web content.

On the Web this happens too (new tabs), but I really feel like I am surfing the Web when I am flowing through experiences…. tap to tap to tap. This can allow me to get a task done across multiple services in an enjoyable way.

You can also feel this when you see experiences that compose together. We get this naturally through SDKs that will embed on pages, which may use iframes or direct embedding. I remember the mashup generation, where there was an explosion of wiring things together. I loved playing with Yahoo! Pipes in this vein too, and feel like composable blocks can enable a lot of innovation.

However, the “C” in SLICE deserves more love. The flowing nature of the Web, and the way that pieces can be entwined is pretty special. It is what makes it feel like a real Web after all vs. a series of domains with launches as the entry point to them all.

This connectivity, sometimes loosely coupled where sites can be embedding or linking to you without you having to know, and sometime explicitly coordinated between a couple parties, gives us our commons.

One of the reasons that Alex Russell speaks so strongly on the performance of the Web is because of this commons and how we effect each other. Every time a user interacts with a web site it ticks some state on how they feel about the overall experience of the Web. As you surf through three connected sites, if the second one is really slow, what is the impact? How much does it matter than the other two were instant? This is subtly different to the general bar on a platform based on the quality of the individual experiences.

If there is a huge variety in interactions, will will be more likely to see more composition? I already feel like I used to browse around more, and we had classics such as web rings that are the perfect example of one site flinging you on to the next, building momentum. Now it feels like the motos operandi is often “keep users in my experience!” which I know is particularly due to dominant monetization models. This gets me thinking about attribution systems baked in that would incent links out again.

The Empty, White Page

The other side of the user experience, is the advent of the SPA. While it is hard to load it up without causing a huge initial load, once up and running, you the developer have full control over routing and navigating throughout your experience.

Stuart Langridge gave a great talk on this that is typically entertaining to boot. He talks about one of the key problems with flowing between experiences, in that we tend to break the linkage with a bright white empty screen when going between domains.

This is like being blinded as you surf, and makes you feel disconnected as you navigate.

What if we could setup lovely hand-offs between navigations? What if you could use these across your own site or set of sites without being forced into an SPA architecture or PJAX is just on your own?

This is why I am excited about Portals. We finally have a way that will fix up the seams in interesting overlapping ways. Each side of the navigation can talk to each other, enabling a lot of new innovation again in how your surf.

Finally, you can get fantastic UX, with a very loosely coupled architecture and codebase. This is huge, especially for large teams. We have built up so much machinery in the name of allowing a massive site with teams for each of /product, /checkout, /search, bundle, build, and ship separately. Or across subdomains, or different sites in a shared portfolio.

This is why I am excited on having us work together to build out Portals and I hope you have a play and give the community feedback. And partnered with web packaging, you can be flowing through the Web like Spiderman through Metropolis consuming packages from a close by CDN.

We are always building out capabilities to help you get the most from the native platforms your users are on, but I *really* love thinking about what makes the Web special and different, and I think there is so much more that be done through this notion of the Web and composition.

One browser to rule them all?

Sizzy is the latest custom browser for a particular niche, this time design. Blisk is another that targets developer use cases. Ironically, it’s tagline is “One browser to rule them all” when, in fact, maybe it paints an alternative picture.

Time for an Eclipse

I remember a trip that Ben and I took to Ottawa. It was in the winter, and happened to occur at the same time as a visit from Obama (so, you know, in the good old days ;). We were visiting the core team at IBM behind Eclipse (and SWT and OSGI and ….) such as Steve Northover. The topic was web based IDEs, since we were working on Bespin and they were building Orion.

They were great to talk too, because they have so much experience in the world of tooling, having worked on them for decades.

One of the lessons I learned was that Eclipse was originally a foundation. If you look at the layers: SWT as a native widget toolkit, OSGI as a way to dynamically modularize, and Eclipse as the IDE bits…. you had a way to customize and build an IDE. Maximum flexibility.

But many Java developers downloaded Eclipse and used it. Many appreciated it, but many also found it far too confusing (Perspectives?). The IDE platform was being used as the end product. Since then, custom IDEs have been build with Eclipse, using the power of the platform but delivering a custom and opinionated view for it’s users.

I reflected on this as I played with niche browsers and wondered….

What if we had more browsers in our lives, not less?

What most think of as their “browser” is the Web platform with a product surrounding, and integrating with it. The main feel of the browser hasn’t felt that different for awhile. You still see the URL bar up top, still use tabs, etc.

A browser expected to be baked into an operating system, but we still see new browsers looking to innovate and find their own niches, such as funding models and verticals. So far, the browser itself feels familiar.

Unless you consider the “app browsers”. The apps that deeply embed the Web as a core part of their experience, such as Twitter, Facebook, Google’s Search app, and on and on. These have taken a particular view that is less of a blank slate that allows you to put in a URL (well, or search, or leap from a new tab page that has a feed too… ok there is some innovation there!).

Imagine how a browser would be different if it was oriented in a particular way? E.g. a developer browser that didn’t focus on speed for users, but on getting you as much data to help you debug and develop?

Just as with Eclipse, there are many ways to get there. You can customize through plugins, or you can have a seperate distro that is fully setup and ready.

It does make me wonder though…. can we find a new bar that allows for much more innovation in the product space, while we all work together to push the web platform forward, in a way where developers can ship to reach as many users as possible.

What would you like to see?

The Truth about Web Components and Frameworks

Have you noticed that there is a regular community.nextTick() that involves heated discussions around “Web Components vs. Frameworks” in some form or another.

It can be frustrating to see the same topics repeatedly pop-up, but I find it interesting to dive into why it does so.

A pattern I often see is a tension where we want to reduce a topic to a simple black and white abstraction, but when we fail to do so, we bounce off to fight another day.

Reductions and Abstractions

We are pattern matchers, and predictors of the future at our core. Much of our progression as a species has been in building up abstractions that allow us to model the future. So, it isn’t surprising that we try really hard in science and engineering to find abstractions.

Often science and math give us a purity of abstraction, whereas engineering has us in the complex muck where we hunt for patterns that are hiding in the world of a massive number of variables.

Early abstractions start out leaky. As we climb to the next level we need an escape hatch to where we are safe and knowledgeable. How much assembly was written in the early years of C vs. today?

Over time, if an abstraction is solid, we will be able to basically ignore a layer, at least in the main. There are a huge number of programmers that have never learned the assembly layer, and the machine layer below. Some may bemoan this at times, but if an abstract is good, many will get by.

NOTE: I still think it is optimal to understand one layer below (and one above if applicable!) as Glenn used to say..

How does this relate to Web Components and Frameworks?

Right! I contend that we are in a messy state of abstractions not being clean here, and the desire to find black and white is hitting up against the world of grey.

The simple to understand views are these:

  • Web Components lost and are unnecessary. Just use the component model in your framework of choice!
  • Web Components are all you need. <Components> all the way down baybee!
  • Use Web Components for UI leaf nodes, and an app framework to glue it together…. it all just works!
  • A company should only allow one framework to be used, and thus reuse is at that framework level!

In the real world, one of these could be true for one form of truth, but they miss all of the nuance and ignore many other forms of truth, such as:

  • For many apps, simple orchestration using Web Components, beyond leaf nodes is fine
  • For many apps, it is overkill to build reusable Web Components, and that’s fine
  • It is rare to see a company (of size) keep every application on the same version of the same framework, and this approach has many many trade offs
  • Sometimes companies buy other companies, and they come with code and legacy
  • It’s ok to experiment with new frameworks and new paradigms, it’s how we progress
  • Web Components aren’t the only way that you can share code, and that’s fine
  • Gluing between component models isn’t fun, but it’s also fine
  • There are very different roles. If you are a vendor of components you will think very differently about how you scale the component set and who you want to target

We can go on and on and on. It’s messy, and it can also work. The environment is changing around us (browser support, evolving libraries, new paradigms such as the recent “compilers”).

I think it is only a good thing for the platform to give us a way to define <our-components>, and I love seeing the interop change over time.

But at the end of the day, what I care most about is that we can be productive, and our ecosystem has content that users love (which includes, but isn’t solely subject to, performance… have you setup performance budgets?).

Do we have all of the components we need to move fast? Tooling? Can we fix bundling to not be a nightmare for developers?

If we can honestly look at ourselves and feel like we are doing the right thing there, the rest is gravy.

It’s OK living in the gray. It’s OK not having worked out the perfect abstractions, yet.

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