Forem: Abhishek Ghosh

Playing with video scrubbing animations on the web

Abhishek Ghosh — Sat, 28 Dec 2019 18:00:00 +0000

Videos are but a sequence of consecutive images (or frames) with small differences being painted in rapid succession to provide the illusion of motion. Before folks can chase me with pitchforks angered at the gross oversimplification of what goes into storing and playing digital videos of this age - the keyframes, the deltas, the interpolation and all the intelligent algorithms that allow us to encode every required bit of information into a much more compressed format as opposed to a naive sequence of full frames images - allow me to capture the intent of my conversation: all animation for that matter, digital or otherwise, is built on this basic founding premise.

For normal video playback, the primary input variable is nothing but a synthesized numerical value that is repeatedly updated in accordance to how we human beings perceive the passage of “time”. Given a specific value, we know which frame to display. Done repeatedly, we have motion picture.

It’s not hard to imagine that this input variable can be fed in by other sources apart from the so customary time-axis. What about space co-ordinates? Say the user’s scroll position on a page? Or any action that the user takes which can be crunched through a mathematical function and reduced to a value on a number line? Such patterns are fairly well established and sometimes commonplace. Occasionally, they help build quite the creative user experience. Apple Inc., for one, has time and again exhibited their affinity for such patterns, most recently with their Airpods Pro website.

So far every time, almost to a fault, implementation details have revealed that to present us with such animations, a large set of images representing individual frames are downloaded and selectively displayed in rapid succession on the screen in response to an input signal such as a scroll event. That’s downloading a lot of image files whose content vary very little incrementally from one frame image to the next by design. In the process of doing so, are we throwing all the advancements we’ve made together as a tech community in the world of video compression, out of the window?

From my understanding, this is mostly because of the limitations of Web API (or a lack thereof) that would allow us to efficiently go back and forth to paint a specific frame from a video loaded on a web page in a manner that is fast and responsive. The sentiment is perhaps shared and the limitation is acknowledged too.

With all that being said, this article is an attempt to proverbially dip my feet into the water of how we build such experiences and hopefully be able to share some learnings from a bunch of quick prototypes of potential web video frame extraction and scrubbing techniques within the confines of existing limitations of today. The overarching theme is trying to extract necessary frames out of a video either on the client (in-browser) or aided by a server (as in the example above), such that they can later be used to provide a video scrubbing experience based on page scrolling.

All of this comes available with live demos and source code.

The final video used for the purpose of these demos is taken from a public list of samples that I found and is a 1280x720p resolution 15-second-duration video with a download size of ~2.5MB. My tests were run on Chrome 78 on 2015 15” Macbook Pro (desktop) and Chrome 78 for Android on a Oneplus 5 (Snapdragon 835 SoC with 8GB RAM) mobile phone, all over a fairly good WiFi connection.

Approaches

#1: video-current-time (demo)

This mechanism simply loads the video in an HTML5 video tag and sets the currentTime property of the loaded video to scrub it when scrolling. We do not specifically extract out frames from the video, instead, we just let the normal video playing experience on the web take care of it and see how it does.

This somewhat worked out on high-end devices (such as my 15” Macbook Pro) especially with a not-too-high quality video, or perhaps as long as the browser is fast and powerful enough to be able to quickly seek back and forth and paint the frames out of the provided video. But it can’t be trusted beyond that. As expected, on mobile devices (even on a decently well-to-do phone such as a Oneplus 5 which I use as my primary mobile device), this was quite miserable with no frame updates happening when the scrolling is in motion, till the UI thread has had the breathing room to update pixels on the page. I also have a hunch that the browser (tested on Chrome 78 for Android) may be purposefully doing things (mobile optimisations?) that it doesn’t do on the desktop version that makes this mechanism not work well on the mobile browser.

It’s important to realise that browsers internally do a lot of magic to understand and optimise what’s the best way to display a video and update it on a page… and unless we’re making the browser’s life easy, it’s going to leave us feeling stupid.

I’ll admit that the videos I had been playing around with we’re not per se additionally optimised and specifically encoded in a way to facilitate extremely fast seeking - and we mayanecdotally know that it may have been possible achieve a better experience if we were to do so - but the frame drops I observed were stupendous; drastically falling apart as I went about increasing the resolution of the video (even at 720p) which with the intent of the type of experience we’re trying to build here, will probably be quite hard to sacrifice if we want to build a great experience.

#2: video-play-unpack-frames-canvas (demo)

So the two-line tactic did not work out. Great. Let’s evolve from there.

What we do here is load the video in a hidden HTML5 video tag and unpack video frames from it by starting to play the video and then listening to timeupdate events at regular intervals on thevideo element being fired as it’s being played, at which point we pause the video and grab the current frame by painting the outcome on an OffscreenCanvas element and collecting the frame’s image bitmap from its 2D context. When done, we start playing the video again, looping through the process until the video has come to an end.

The basic idea is to generate a set of static images from the source video by the end of this exercise. We use an OffscreenCanvas for possible performance benefits on top of a normalcanvas element, but that would work as well.

This mechanism works in principle but is not a very smart thing to do for an obvious reason: the time to extract out the frames is bound to at least the duration of playback of the video. If you need to extract out some frames from a 15-second video, be prepared to wait for at least those 15 seconds, no matter how fast your video is downloaded or even cached! On top of that, it would also take some additional time for all the amount of javascript work that’s happening. On my test setup, our 15-second 1280x720p video took a bit more than 18 seconds to extract out 244 frames on my 15” Macbook Pro on Chrome 78 whether the video was cached or not on the browser. That’s a lot of time!

Once the extraction of frames is done (a set ofImageBitmap objects representing the frames is retained in memory), for scrubbing we figure out the correct frame to paint based on the input signal (scroll position) and then draw the correct frame on a visible canvaselement on the page.

The scrubbing part itself worked out fairly well - it was fast enough to scroll and scrub around without any visible lag on pretty much all devices (desktop and mobile) I tested on. Retaining a representation of frames in a set of image bitmaps in memory which can be painted rapidly on acanvas (as opposed to trying to encode and put them into img elements that are then chosen to be displayed or hidden in quick succession) must have contributed significantly in making the scrubbing experience smooth by making the browser do less work.

#3: video-seek-unpack-frames-canvas (demo)

This is quite similar to approach #2 above but it tries to eliminate the glaring video playback duration wait problem by performing seek instead of play while extracting out frames. Quite obvious really when you think about it.

In the current prototype, a predefined number of frames are unpacked, but this can also be easily changed to a frame-rate based approach rather than overall count.

Once frames are extracted, the scrubbing experience works the same.

Turns out, this is indeed much faster! On the same test setup, the same 15-second 1280x720p video took about 9 seconds to extract out 244 frames (first hit) and 6 seconds when the video was cached (subsequent hits). That’s a 2x-3x improvement for the same number of frames.

But yeah. I’d agree that 6 seconds in itself is not a number to proudly strive for.

#4: video-seek-media-stream-image-capture (demo)

Again, this is largely similar to the above approaches #2 and #3 in terms of seeking through the video using an HTML5 video tag. But instead of pausing and drawing it on a canvas context to extract out the frame’s image bitmap data, I wanted to check if we could usecaptureStream()on the video element to capture the video stream and then we use the captured stream’sImageCapture interface to grab the image bitmap data of a frame at the desired point in time. Well, it works.

For scrubbing, the same approach is followed.

I’d be honest - while the approach to useMediaStream APIs had originally somehow struck me as more elegant in concept, in reality, this turned out to be a bit of a bummer! It was slower than approach #3 performance-wise, taking as much as 12 seconds (first hit) and 9 seconds (subsequent hits when the video was cached) which is about a 1.3-1.5x degradation compared to directly drawing the video element in an OffscreenCanvas and extracting out the image bitmap from it, on the same test setup. Now I am not 100% certain that I’ve not made any fundamental mistakes in terms of best practices for using these streaming APIs (I believe I haven’t goofed up), in retrospect, this was perhaps to be expected due to all the internal complexity that browser has to take care of to open a media stream and then do things with it. That’s okay - I don’t quite believe this use-case is something that the MediaStream APIs are intended to solve anyway.

#5: video-server-frames (demo)

This is basically what we discussed in the beginning. Take the Apple Airpods Pro example above. Other people have tried toreplicate it as well.

Perhaps the simplest mechanism of all, it relies on the server to provide a bunch of video frames as images that are downloaded and scrubbed through.

This works out really well when you know upfront what exact content (the video and hence the image frames) you’re going to load and scrub through exactly, which is legitimately a fair assumption to make in the use-case we’ve been discussing here. You can pre-generate and store a set of frames easily at build time on your server or CDNs and serve them when required by the client. Within the context of discussed use-cases it goes along well with another great software design principle I love and quote from time to time: Avoid doing at runtime what you can do at design time.

For the same number of frames (244) which were pre-computed and delivered from the server, the network bytes transferred was about 20% larger (~3MB as opposed to ~2.5MB video), but getting the frames ready for scrubbing took about 2.5 seconds (first hit) and 1.3 seconds (subsequent hits when the frame images were cached) which is 3x-4.5x faster than having to download the video and then extract frames from it as fast as we can (approach #3). I should mention though that all of this happened over a HTTP/2 connection (which is today’s reality) to the same CDN (which surely worked out in favour of having to make those 244 requests).

Initially, it seemed that downloading an image sprite with a bunch of frames as opposed to individual requests for every frame would a good idea, but it turned out to be very tricky. Based on the actual frame images and parameters like how many frames to fetch, sprites can actually degrade the performance by visibly increasing size of downloads or at least reduce flexibility. In a world with HTTP/2, distinct images fare better - we could even prioritise certain frames and bootstrap the scrubbing experience faster.

#6: video-wasm-ffmpeg-extract

Definitely an idea to pursue, although I haven’t yet been able to test this in action.

The idea is to exploit WebAssembly to have an in-browserffmpeg module loaded which can then be invoked to extract out frames pretty fast. This should be possible today in theory with projects likeffmpeg.js.

Honestly, I tried going through this but have so far given up having faced several difficulties with compiling low-level modules into a build of ffmpeg.js that would be necessary for this experiment - somehow, the default ffpmeg.js builds are not built with the required options needed for performing frame extracts. Oops!

I do hope to try again in the future and write another blog post on how that goes.

One sure shot thing to consider though - for typical small-sized videos or when the actual content in question is known not to be very dynamic in nature, this sounds like a fairly over-engineered idea. For one, the WASM library build for ffmpeg.js itself is humongous in size (~14MB) to have it downloaded and instantiated before any actual work can happen, which is fairly cost-prohibitive for what I had been trying to achieve here. This might, however, breakeven for other frame extraction use-cases which fit the bill better - say we’re dynamically changing a lot of video content, scrubbing through them, saving them back and so on (for eg. in an in-browser video frame extractor and editor).

The Verdict

From the numbers, sending out pre-computed frames from the server (approach #5) turned out to be the most efficient for practical network and device conditions that such use-cases be exposed to in terms of overall cost-benfit, complexity and user experience. So, looks like Apple’s approach was right given the circumstances. Otherwise, if I have to compute it on the client though, I’d go with approach #3.

As for users with constrained network connection and device power, I strongly think that such experiences shouldn’t even go out to such users. Probably find alternate experiences for them that provide more value. For the sake of completeness, I did try out on slower network connections, #5 still worked more reliably than trying to pull a video which somehow got stuck or kept buffering.

On a high-level, one of the major costs we’re trading off here is the network consumption vs. device compute. From the observations, it clearly seems that unless the total download time (factor of size and round-trips) of our image frames is not massively larger than the video (so much as to reach a point of inflex), it distinctly works out in favour of downloading pre-computed image frames rather than the video and then compute out the frames from it. A progressive enhancement to our approaches #2 through #4 could definitely be that we store the computed frames in a cache locally and avoid having to generate them every time the page is loaded, but still, the initial costs far outweigh the benefits when we know what content (the video and hence the frames) is to be scrubbed. The other obvious trade-off is the choice of the flexibility of the content itself - but that’s not really a problem if our content is not truly dynamic.

Given the state of Web APIs, and use-case in question, pre-computed frames from the server is probably the best way to go about it now for production scenarios. That’s the opinion I’m going to stick with for now.

As a bonus, this also opens up pathways for adapting experience parameters such as with the number of frames to download (animation frame-rate), image format or compression level etc. which can be easily negotiated with the server to only download what will be used for an optimal experience on that specific device, based on information on client-side capabilities (device computation power, memory, network speed, data-saver modes and so on) as compared to having to download one of few pre-defined video and then extract usable pieces (some frames) from it.

Do you have other approaches in mind? Do share in the comment below - I’d be excited to give them a try!

Future

In a future where native browser support to unpack frames from a video fast and efficiently, or at least some native API on the browser that provides the capability to write custom logic to do perform efficient processing on video streams (think codecs) become a reality, this is to hoping that we’ll not have to be limited to the current antics. But it’s perhaps a bit too early to clearly say.

Perhaps there is hope with WebCodecs?

Bonus

While playing around with these experiments, I decided to quickly hack up together a video frame extract tool that can take any video that is uploaded as input and extract out frames from it, conveniently downloaded as a bunch of JPEG images within a single ZIP file.

It isn’t an extremely powerful tool as such but is a little bit configurable, such as how many frames to extract or at what frame rate and gets the job done simply and fairly well.

Be sure to check it out! I’m also eager to listen to any feedback there is.

Chrome Dev Summit 2019: Everything you need to know

Abhishek Ghosh — Sat, 14 Dec 2019 00:00:00 +0000

"As the largest open ecosystem in history, the Web is a tremendous utility, with more than 1.5B active websites on the Internet today, serving nearly 4.5B web users across the world. This kind of diversity (geography, device, content, and more) can only be facilitated by the open web platform."
- from blog.chromium.org

This would be the uber pitch for Chrome Dev Summit this year: elevating the web platform.

Last month I was in San Francisco for CDS 2019, my first time attending the conference in person. For those of you who couldn’t attend CDS this year or haven’t yet gotten around watching all the sessions on their Youtube channel, here are my notes and thoughts about almost everything that was announced that you need to know!

Almost everything you say? Well then, buckle up, for this is going to be a long article!

Bridging the “app gap”

The web is surely a powerful platform. But there’s still so much that native apps can do that web apps today can not. Think about even some simple things that naturally come to your mind when picturing installed native applications on your phones or computers: accessing contacts or working directly on files on your device, background syncs at regular intervals, system-level cross-app sharing capabilities and such. This is what we call the “native app gap”. And we’re betting that’s there a real need for closing it.

In their natural progression, browsers have become viable, full-fledged application runtimes.

Over the last decade, “the browser” has become so much more than a simple tool for accessing information on the web. It is perhaps the most widely-known publicly-used piece of software that there is, yet so heavily underrated at its sophistication. In their natural progression, browsers have become viable, full-fledged application runtimes - containers for not only delivering but also capable of deploying and running a very large variety of cross-platform applications. Technologies arising out of browser engines have been used for a while to build massively successful desktop applications; browsers themselves have been used as the basis of building entire operating system UI and even run complex real-time 3D games at a performance that is getting closer and closer to native speeds every day. With that train of thought, it seems almost inevitable that the browserverse would sooner or later tackle the problem of being able to impart the average-joe web app the power to do things native apps can.

Source: imgflip.com

If I had to bet, the Web combined with its reach and ubiquitous platform support is probably going to become one of the best and perhaps most popular mechanisms for software delivery for a very large subset of applications use-cases in the coming years.

Project Fugu

The goal of Project Fugu is to make the “app gap” go away. Simply put, the idea is to bake a set of right APIs into the browser, such that over time web apps become capable of doing almost everything that native apps can - with the right levers of permissions and access-control of course, for all your rightly-raised potential privacy and security concerns!

Source: imgflip.com

Enough with the Thanos references, but I wouldn’t be very surprised if someone in the web community called this crazy. And if I absolutely had to, I am going to admit that even if so, this is definitely my kind of crazy. I like to think that I somehow saw this coming, and I wanted this to happen. For years, browsers have in some capacity been trying to bring bits and pieces of native power to the web with experimental APIs for things like hardware sensors and such. With Fugu, all this endeavour to impart native-level power to the web has at least been formally unified under one banner and picked up like an umbrella initiative for building and standardising into the open web by the most popular browser project there is. And I’m really excited to see this succeed for the long term! So I’d love to see this turn out like IronMan (the winning, not the dying part) rather than Thanos in the end!

The advent and success of Progressive Web Apps (PWA) would have definitely acted as a catalyst at exhibiting that with the right pedigree, web apps can really triumph. Making web apps easily installable or bringing push notifications to the web was perhaps just the first few pieces of this bigger puzzle we have been staring at for a while. Keeping aside whatever Google as a company’s strategies and business motivations may be to so heavily be investing in everything web; if at the end of the day it benefits the entire web user and developer community by making the web platform more capable, and I choose to believe that it will, I am surely going to sleep happier at night.

Source: slides.com

In case you’ve been wondering, the word “Fugu” is Japanese for pufferfish, one of the most toxic and poisonous species of vertebrates in the world, incidentally also prepared and consumed as a delicacy, which as you can guess, can be extremely dangerous from the poison if not prepared right. See what they did there?

Some of the upcoming and interesting capabilities that were announced as part of Project Fugu are:

Native Filesystem API which enables developers to build web apps that interact with files on the users’ local device, like IDEs, photo and video editors or text editors.
Contact Picker API, an on-demand picker that allows users to select entries from their contact list and share limited details of the selected entries with a website.
Web Share and Web Share Target APIs which together allow web apps to use the same system-provided share capabilities as native apps.
SMS Receiver API, using which web apps can now use to auto-verify phone numbers with SMS.
WebAuthN to let web apps access hardware tokens (eg. YubiKey) or perform biometrics (like a fingerprint or facial recognition) based identification and recognition of users on the web.
getInstalledRelatedApps() API that allows your web app to check whether your native app is installed on a user’s device, and vice versa.
Periodic Background Sync API for syncing your web app’s data periodically in the background and possibly providing more powerful and creative offline use-cases for a more native-app-like experience.
Shape Detection API to easily detect faces, barcodes, and text in images.
Badging API that allows installed web apps to set an application-wide badge on the app icon.
Wake Lock API for providing a mechanism to prevent devices from dimming or locking the screen when a web app needs to keep running.
Notification Triggers for triggering notifications using timers or events apart from a server push.

The list goes on. These features are either in early experimentation through Origin Trials or targeted to be built in the future. Here is an open tracker for the list of APIs and their progress that have been captured so far under the banner of Project Fugu.

Source: developer.google.com

Also worth noting, webwewant.fyi was as announced as well, which is a great place for anyone in the web community to go and provide feedback about the state of the web and things that we want the web to do!

On PWAs… wait, now we have TWAs?

Progressive Web Apps with their installability and native-like fullscreen immersive experiences have been Google’s showcase fodder for over multiple years of Google I/O and Chrome Dev Summit. Major consumer facing brands like Flipkart, Twitter, Spotify, Pinterest, Starbucks, Airbnb, Alibaba, BookMyShow, MakeMyTrip, Housing, Ola, OYO have all built and shown how great PWA based experiences can be made which are hard to distinguish from native apps by the average user. By this point in time, I think as a community, we generally understand and agree that PWAs can be awesome when done right. So what next?

Source: medium.com

A key development for installable web apps has been the emergence of Trusted Web Activities (TWA) which provide a way to integrate full-screen web content into Android apps using a protocol called Custom Tabs: in our case, Chrome Custom Tabs.

To quote from the Chromium Blog, TWAs have access to all Chrome features and functionalities including many which are not available to a standard Android WebView, such as web push notifications, background sync, form autofill, media source extensions and the sharing API. A website loaded in a TWA shares stored data with the Chrome browser, including cookies. This implies shared session state, which for most sites means that if a user has previously signed into your website in Chrome they will also be signed into the TWA.

Basically think of how PWAs work today, except that you can install it from the Play Store, with possibly some other added benefits of app-like privileges. It was briefly mentioned that with TWAs the general permission model of certain web app capabilities (such as having to ask for push notification permissions) may go away and become as simple and elevated as true native Android apps (considering they are, in fact, so).

As an application of all this, TWAs are now Google’s recommended for web app developers to surface their PWA listings on the Play Store. Here’s their showcase on OYO.

Imagine having native apps that almost never need to go through painful or slow update cycles and consume very little disk space.

I believe TWAs can open up some really interesting avenues. Imagine having native apps that almost never need to go through painful or slow update cycles (or hence have to deal with all the typical complexities of releasing and maintaining native apps and their codebases), because like everything web, the actual UI and content always updates on the fly! These apps get installed on a user’s device, consume very little disk space compared to full-blown native apps because of an effectively shared runtime host (the browser) and work at full capacity of that browser, say Chrome. This is quite different from embedding WebViews into hybrid native applications for a number of reasons where the main browser on a user’s device can do more powerful things or have access to information that WebView components embedded into individual native apps can not.

If today you maintain a native app, a lite version of your native app, and a mobile website (like Facebook does); now, if you want, your lite app can be simply your mobile website distributed via the Play Store wrapped in a TWA. One less codebase to maintain. Phew.

I haven’t yet played around with deploying a TWA first-hand myself, so some of the low-level processes are still unclear to me, but from what I could gather talking to Google engineers at CDS who have been working on TWAs, because of several Play Store policies and mechanisms based on how it operates today by design, looks like as developers we still need to handcraft a TWA from a PWA, and manually upload and release it onto the Play Store. What would be amazing is being able to hook up some sort of a pipeline onto the Play Store itself that auto-vends a PWA as a TWA given a right, validated config.

Other improvements coming to PWAs are the shortcuts member in Web App Manifest which will allow us to register a list of static shortcuts to key URLs within the PWA where the browser exposes these shortcuts via interactions that are consistent with exposure of an application icon’s context menu in the host operating system (e.g., right-click, long press), similar to how native apps do.

Also, Chrome intends to play with the “Add to Homescreen” verbiage and it might probably simply be called “Install” in the future.

Because Performance. Obviously!

Not all devices are made equal.

And neither the experience of your web app.

Users access web experiences from a large variety of network conditions (WiFi, LTE, 3G, 2G, optional data-saver modes) and device capabilities (CPU, memory, screen size and resolution) which causes a large performance gap to exist across the spectrum of network types and devices. Multiple Web APIs are available today that can collectively inform us with network and device information which could be used to understand, classify and target users with an adaptive experience for providing them with an optimal journey through our website, given their state of network and device performance. Some APIs that can help us here are the Network Information API that informs effective connection type, downlink speed, RTT or data-saver information, DeviceMemory API, CPU HardwareConcurrency API and a mechanism to communicate such information as Client-Hints.

Source: Adaptive Loading - improving web performance on slow devices

Facebook described on a very high-level their classification models for devices for both mobiles and desktops (which are relatively harder to do) and how they have been effectively using this information to derive the best user experience for targeted segments.

All this comes paired with the release of Adaptive Hooks, which makes it easy to target device and network specs for patterns around resource loading, data-fetching, code-splitting or disabling certain features for your React web app.

Better to hang by more than a thread.

The more work is required to be done during JS execution, it queues up, blocks and slows everything down effectively causing the web app to suffer from jank and feel sluggish.

To deliver web experiences that feel smooth, a lot of work needs to be done by the browser, ranging from the initial downloading, parsing and execution of HTML, CSS & Javascript; and all the successive work required to be able to eventually paint pixels on the screen which includes styling, layouting, painting and compositing; and then to make things interactive, handling multiple events and actions; and in response to that, frequently redoing most of these above tasks to update content on the page.

A lot of these tasks need to happen in sequence every time, as frequently as required, within a cumulative span of a few milliseconds to keep the experience smooth and responsive: about 16ms to deliver 60 frames per second, while some new devices support even higher refresh rates like 90Hz or 120Hz which push the available time to paint a frame to even smaller if you have to keep up with the refresh rate.

With the combined truth that all devices are not made equal and that JavaScript is single-threaded by nature which means the more work is required to be done during JS execution, it queues up, blocks and slows everything down effectively causing your web app to suffer from jank and feel sluggish.

Source: The main thread is overworked & underpaid

Patterns to effectively distribute the amount of client-side computational work across multiple threads by leveraging web workers to perform Off-Main-Thread (OMT) work and keep the main (UI) thread reserved for doing only the amount of work that absolutely needs to be done by it (DOM & UI work) can help significantly to alleviate this problem. Such patterns are about reducing risks of delivering poor user experiences, where although the entire time of overall work completion maybe, in fact, slowed marginally my message-passing overheads across multiple worker threads, the main (UI) thread is instead free to do any UI work required in the interim (even new user interactions like handling touch or scrolls) and keep delivering a smooth experience throughout. This works out great since the margin of error of dropping a frame is in the order of milliseconds while the making the user wait for an overall task to complete can go into the order of 100s of milliseconds.

Web workers have existed for a while but somehow for probable reasons around their wonkiness, they haven’t really seen great adoption. Libraries like Comlink can help a lot to that end.

Proxx.app is a great example to look at all of this in action.

Lighthouse shines brighter!

Source: google.com

Not to throw any shade at Lighthouse (all puns intended), so far this web performance auditing tool had always fallen short of my expectations for any practical large-scale use-case. It seemed a little too simple and superficial to be of much use to drive meaningful insights in complex, real-world production applications. Don’t get me wrong, Lighthouse has always been a decent product on its own, but building web performance test tooling that is robust, powerful and predictable, is inherently a hard problem to solve. Lighthouse had always been somewhat useful to me, but mostly as a basic in-browser audit panel thing that could give me some generic “Performance 101” insights, rather than something I would be excited to hook up as a powerful-enough synthetic performance testing tool in a production pipeline for catering to deeper performance auditing needs that I may have.

Hopefully, that changes now. With the release of Lighthouse CI, an extension of the toolset for automated assertion, saving and retrieval of historical data and actionable insights for improving web app performance though continuous integrations, the future seems a bit more brighter.

What’s even more exciting, is the introduction of stack-packs which detect what platform a site is built on (such as Wordpress) and displays specific stack-based recommendations, and plugins which provide mechanisms to extend the functionality of Lighthouse with things such as domain-specific insights and scoring, for example, to cater to the bespoke needs of an e-commerce website.

… and comes with new Performance Metrics.

Source: Speed tooling evolutions: 2019 and beyond

With Lighthouse 6, some important changes are coming to how it scores web page performance, focusing on some of the new metrics that are being introduced:

Largest Contentful Paint(LCP), which measures the render time of the largest content element visible in the viewport.
Total Blocking Time (TBT), a measure of the total amount of time that a page is blocked from responding to user input, such as mouse clicks, screen taps, or keyboard presses. The sum is calculated by adding the blocking portion of all long tasks between First Contentful Paint and Time to Interactive. Any task that executes for more than 50ms is a long task. The amount of time after 50ms is the blocking portion. For example, if Chrome detects a 70ms long task, the blocking portion would be 20ms.
Cumulative Layout Shift (CLS), which measures the sum of the individual layout shift scores for each unexpected layout shift that occurs between when the page starts loading and when its lifecycle state changes to hidden. Layout shifts are defined by the Layout Instability API and they occur any time an element that is visible in the viewport changes its start position (for example, it’s top and left position in the default writing mode) changes between two frames. Such elements are considered unstable elements.

Metrics that are being deprecated are First Meaningful Paint(FMP) and First CPU Idle (FCI).

Visually marking slow vs. fast websites

Chrome has expressed plans to visually indicate what it thinks is a slow vs. a fast loading website. The exact form of how the UI is going to look like is still uncertain, but we can expect a bunch of trials and experiments from Chrome on this.

Source: Moving towards a faster web

I guess that this is going to be mired with some controversy when this happens. How does the browser judge what is right for my website? Why does it get to decide where exactly to draw the line? And how exactly does it do it for the type of website, target audience and content I have? Surely there are a lot of difficult questions with no easy answers yet, but there’s one thing for sure, that if this does happen, it will force the average website to take some web performance considerations more seriously. Somewhat like when browsers together decided to start enforcing HTTPS by visually penalizing non-secure websites and it worked out well eventually. Honestly, with so much that is unclear, for now, I am still going lean towards the side of more free will, but as a self-appointed advocate of web performance, I am very tempted to think that if executed right, this might just be a good thing.

Web Framework ecosystem improvements

Google has been partnering up with popular web framework developers to make under-the-hood improvements to those frameworks such that sites that are built and run on top of these frameworks get visible performance improvements without having to lift a finger so to speak.

Choosing to deliver modern Javascript code to modern browsers could visibly improve performance.

The prime example of this was a partnership with Next.js, a popular web framework based on React, where a lot of development has happened around improved chunking, differential loading, JS optimisations and capturing better performance metrics.

An interesting (though quite seemingly obvious in retrospect) takeaway from this was choosing to deliver modern Javascript code to modern browsers (as opposed to lengthy transpiled or polyfilled code based on some lowest common denominator of browsers you need to support) could visibly improve performance by drastically reducing the amount of code that is shipped. This was coupled with the announcement of Babel preset-modules which can help you achieve this.

If you are interested, the Framework Fund run by Chrome has also been announced multiple times across this CDS.

How awesome is WebAssembly now?

Spoiler alert: pretty awesome! 💯

Source: Wikimedia Commons

WebAssembly (WASM) is a new language for the web that is designed to run alongside Javascript and as a compilation target from other languages (such as C, C++, Rust, …) to enable performance-intensive software to run within the browser at near-native speeds that were not possible to attain with JS.

While WebAssembly has been out there being developed and improved upon for a few years, it saw a major announcements this time on performance improvements that brings it closer to being at par with high-performance native code execution, being enabled through the browser’s WASM engine improvements such as implicit caching, introduction of support for threads, and SIMD (Single Instruction Multiple Data) which is a core capability of modern CPU architectures that enables instructions to be executed multiple times faster.

Multiple OpenCV-based demos that illustrated real-time high-FPS feature recognition, card reading and image information extraction, facial expression detection or replacement within the web browser, all of which have been made possible by the recent WASM improvements, were showcased.

Check them out, some of them are really cool!

The cake is still a lie, but a delicious one at that!

Here, if you didn’t get that reference.

Source: web.dev

One of the unique new web platform capabilities that garnered a lot of interest was Portals, which aims to enable seamless and animation-capable transitions across page navigations for multi-page architecture (MPA) based web applications, effectively affording such MPAs a creative lever to provide smooth and potentially “instantaneous” browsing experiences like native apps or single-page applications (SPA) could provide. They can be used to deliver great app or SPA-like behaviour without the complexity of doing a SPA which often becomes cumbersome to scale and maintain for large websites and with complex and dynamic use-cases.

Portals are essentially a new type of HTML element that can be instantiated and injected in a page to load another page inside it (in some form similar to IFrames but also different in a lot of ways), keep it hidden or animate it in any form using CSS animations, and when required, navigate into it - thus performing page navigations in an instant when used effectively.

An interesting pattern with Portals is that it can also be made to load the page structure (skeleton or stencil, as you may also call it) preemptively even if the exact data is not prefetched and perform a lot of the major tasks of computation (parsing, execution, styling, layout, painting, compositing) for most of the document structure that contributes to web page performance, in effect moving the performance costs of these tasks out-of-band of critical page load latencies, such that when a portal navigation happens, only the data is fetched and filled in onto the page. This would also require some rendering costs but typically much lesser than the entire page’s worth of work.

Several demos are available and this API can be seen behind experimental flags in Chrome at the moment.

Web Bundles

Source: web.dev

In the simplest terms, a Web Bundle is a file format for encapsulating one or more HTTP resources in a single file. It can include one or more HTML files, Javascript files, images, or Stylesheets. Also known as Bundled HTTP Exchanges, it’s part of the Web Packaging proposal (and as someone wise would say, not to be confused with webpack).

The idea is to enable offline distribution and usage of web apps. Imagine sharing web apps as a single .wbn file over anything like Bluetooth, Wi-Fi Direct or USB flash drives and then being able to run them offline on another device in the web application’s origin’s context! In a way, this sort of again veers into the territory of imparting the web more powers like native apps which are easily distributable and executable offline.

In such countries, a large portion of apps that exist on people’s phones get side-loaded over peer-to-peer mechanisms rather than from over a first-party distribution source like the Play Store.

If you researched on different modes in how native apps get distributed in countries with emerging markets such as in India, Mid-East or Africa which are heavy on mobile users but generally deprived on public Wi-Fi availability or have predominantly poor, patchy or congested cellular networks, peer-to-peer file-sharing apps like Share-It or Xender are extremely popular in terms of how people share software and a large portion of apps that exist on people’s phones get side-loaded over peer-to-peer mechanisms rather than from over a first-party distribution source like the Play Store. Seems only natural that this would be a place to catch on for web apps as well!

I need to confess that the premise of Web Bundles does sort of remind me of the age-old MHTML file format (.mhtml or .mht files if remember those) that used to be popular a decade back and in fact, is still supported by all major browsers. MHTML is a web page archive format that could contain HTML and associated assets like stylesheets, javascript, audio, video and even Flash and Java applets of the day, with their content-encoding inspired from the MIME email protocol (leading to the name MIME HTML) to combine stuff into a single file.

For what it’s worth though, from the limited knowledge that I have so far, I do believe that what we’ll have with Web Packaging is going to be much more complex and powerful and catering to the needs of the Web of this generation with key differences like being able to run in the browser using the web application’s origin’s context (by being verified using signatures similar to how Signed HTTP Exchanges may work) rather than being treated as locally saved content like with MTHML. But yeah… can’t deny that it does feel a bit like listening to Backstreet Boys again from those days! Hashtag Nostalgia.

More cool stuff with CSS! Yeah!

I didn’t even try to come up with a better headline for this section, because this is simply how I genuinely feel.

New capabilities

A quick list of some of the new coolness that’s landing on browsers (or even better, have already landed) are:

scroll-snap that introduces scroll snap positions, which enforce the scroll positions that a scroll container’s scrollport may end at after a scrolling operation has completed.
:focus-within to represent an element that has received focus or contains an element that has received focus.
@media (prefers-*) queries, namely the prefers-color-scheme, prefers-contrast, prefers-reduced-motion and prefers-reduced-transparency, which in Adam Argyle’s words, can together enable you to serve user preferences like, “I prefer a high contrast dark mode motion when in dim-lit environments!” 😎
position: sticky which is a hybrid of relative and fixed positioning, where the element is treated as relative positioned until it crosses a specified threshold, at which point it is treated as fixed positioned.
CSS logical properties to provide the ability to control layout through logical, rather than physical, direction and dimension mappings. Think of dynamic directionality based on whether you’re serving ltr, rtl or vertical-rl content. Here’s a nice article that talks about it.

Source: Next-generation web styling

:is() selector, the new name for the Matches-Any Pseudo-class.
backdrop-filter which lets you apply graphical effects such as blurring or colour shifting to anything in the area behind an element!

Houdini

...creating new CSS features without waiting for them to be implemented natively in browsers.

CSS Houdini has perhaps for some time been at the top of my hot-new-things list when thinking about the exciting future of the web. As MDN describes it, Houdini is a group of APIs being built to give developers direct access to the CSS Object Model (CSSOM) and enabling them to write code the browser can parse as CSS, thereby creating new CSS features without waiting for them to be implemented natively in browsers.

In other words, it’s an initiative to open up the browser in a way that gives web developers more direct access to be able to hook into styling and layout process of the browser’s rendering engine. And let creativity (with performance) run amok!

If this is the first time you are hearing about CSS Houdini, take a few moments to let that sink in. Believe me. Then if you like, read a few other great articles on it.

It’s relatively still quite early in the world of Houdini in terms of cross-browser support, but a few announcements on some good progress were made. Paint API, Typed OM and Properties and Values API have shipped to Chrome. Layout API is in Canary.

Source: Next-generation web styling

Check out the cool Houdini Spellbook or the ishoudinireadyyet.com website for more.

Showing some ❤ to HTML

Form elements

In HTML, the visual redesign, accessibility upgrade and extensibility of form elements such as <select> or <date> is a welcome development! A joint session by Google and Microsoft described what to expect with the customizability of form elements in the future, or even the possibility of new elements that don’t exist yet, like table-views or toggle-switches.

Display Locking

Web content is predominantly large amounts of text and images, and if you think about it, often just a collection of list views of a few common types of components repeating over and over again. Think about your Facebook or Twitter feed, your Google or Amazon search results, a lengthy blog (like this one?) or a Wikipedia article you’re reading, or pretty much every other popular website that you use. There is a lot of scrolling involved!

This demands the notion of Virtual Scrolling, and one of the possible prototypes is a new web platform primitive called Display Locking, which is a set of API changes that aim to make it straightforward for developers and browsers to easily scale to a large amount of content and control when rendering work happens.

Source: HTML isn’t done!

To quote from Nicole Sullivan from the session on this, Display Locking allows you to do batch rendering updates to avoid paying the performance costs when handling large amounts of DOM; it also means that locked sub-trees are not rendered immediately, which means you can keep more stuff in the DOM; and that’s great because it becomes searchable both by Find in Page as well as by assistive technologies.

Safety and Privacy

Visual updates to URL display

Source: Protecting users on a thriving web

Let’s talk about important stuff. In the dimension of safety and privacy, some notable callouts include Chrome’s experiments around the general web consumer’s perception of security models related to how URL information is displayed by the browser.

Chrome’s past attempts on using extended validation indicator which informs the legal entity tied to a domain name did not turn out to be successful, simply because people don’t notice when it’s missing.

Source: Protecting users on a thriving web

This also calls out studies where the average web user has been found out to not necessarily clearly understand visual cues like what the HTTPS padlock icon on the URL bar means.

All of this comes with a degree of potential controversy though, where Chrome as a browser will start hiding complete URLs and show origin information that it feels is the most relevant for the average web user. This is probably not going to make more experienced users very happy. In its defence, Chrome announced the Suspicious Site Reporter extension that will allow the power user to see the full unedited URL, as well as report malicious sites to Google’s Safe Browsing service. While the intentions are great, this still feels somewhat stop-gap and a little unfulfilling to me. Simply because mobile has been always so hugely important and non-desktop versions of Chrome have so far, to the best of my knowledge, have had literally zero history of supporting extensions, this sounds like a hasty half-measure and an uncanny oversight. Wouldn’t something as simple as a browser setting have made things easier? Perhaps there are motivations here that I don’t fully understand.

Combating sophisticated spoofing attacks

Sophisticated spoofing attacks like IDN spoofing is extremely difficult for the average web user to detect, and for that matter, often likely to easily defeat the technically experienced user as well unless they are specifically looking for it.

Source: Protecting users on a thriving web

Chrome is introducing what it calls lookalike warnings to inform the user of potential attacks and then try to redirect them to the possibly intended website instead.

Committed to privacy, but with ads? 🤷‍♀️

Following a brief stint on why we should all look at ads as a necessary evil, it was announced that there are [sic] restrictions coming to third-party cookies in Chrome. New cookie classification spec that’s landing enforces SameSite=None to be explicitly set to designate cookies intended for cross-site access, without which they will be by default accessible only in first-party contexts. Coupled with the Secure attribute, this makes cookies only accessible over HTTPS connections. Read more about it on blog.chromium.com.

In a world where other more privacy-focused browsers like Firefox or Safari have been blocking third-party cookies by default and have shown committed interest in fighting against fingerprinting, all this seems arguably feeble. Then again, not that it has had a great track record.

Chrome Extensions

…making progress towards the way they should have ideally always been.

Themes of privacy and safety continued into the presentation of the newer mechanisms for building Chrome extensions that are being designed to be more protective about security and access control.

The introduction of Extension Manifest V3 along with other overhauls to the extension ecosystem architecture would hopefully deprecate currently existing permission models and background code executions which traditionally have been overtly open and also known to cause performance bottlenecks. Stricter models for both permissions and execution limits through background service workers are being introduced.

A notable mention here was the addition of the declarative net request model that will drastically change the behaviour of request interception and blocking as done today by Chrome extensions (such as AdBlock) and provide more restrictive and performant models to achieve the same.

Source: Chrome extensions and the world of tomorrow

SEO

Google announced that the Googlebot crawler user-agent would be updated soon to reflect the new evergreen Googlebot. A much-needed improvement over the previous rendering engine used by Googlebot that was based on Chrome 41 and had been probably facing a lot of difficulties keeping up with new Javascript heavy websites of today.

Source: How to make your content shine on Google Search

What this basically means is that with every release of Chrome, the Googlebot rendering engine will also keep up and get updated. Consequentially, this also gets coupled with the update of the Googlebot user-agent string which will now not always continue to match with an exact version of Chrome anymore, as used to be the case before.

Benefits include better support for modern ways of building websites using such as with Javascript rendered pages, lazy-loading and the support for web components.

Also, going ahead, images set as background-image URLs may not be indexed.

Other stuff to call out…

The Blink shipping process

I wouldn’t really bother trying to explain this considering there’s a great video and write-up that already does a much better job at it. If you are interested in learning how the web platform works in terms of new feature proposals, addition and review of web standards and how features are shipped to Blink (Chromium’s rendering engine) and how it complements the web standards process, check them out.

Origin Trials

This isn’t really news, but to the uninitiated, “Origin trials” are Chrome’s way to quickly experiment and gather feedback on new and potentially upcoming web features by providing some partner websites early access to try out early implementations and give feedback on usability, practicality, and effectiveness that eventually goes on its way to the web standards community.

APIs exposed through Origin Trials are unstable by intent (prone to changes) and at one point before the end of the trials, go out of availability briefly. They also have inbuilt safeguarding mechanisms to get disabled if 0.5% of Chrome’s page loads start accessing the API, to prevent such experimental APIs from being exposed or baked too much into the open web before they are done right and become standards. For more information, see the explainer, developer guide or blink documentation.

If you are interested in playing around with a hot new API that’s landing on Chrome but far from general availability, this is your way to go!

Context Indexing API

Here comes that one-off API that I didn’t really quite know where to put. The idea is to enable indexing of offline content that you can present to a user, but to be able to effectively do that, request the browser to index them such that they can be surfaced in prominent places like Chrome’s landing page or other places, collectively known as “Discovery” experience. Check out the proposal to learn more.

That’s all folks!

Creating a multi-level hierarchical flyout navigation menu using only HTML and CSS

Abhishek Ghosh — Sun, 07 Jul 2019 00:00:00 +0000

Today I am going to give you a quick tutorial on how to create a hierarchical navigation flyout menu that can go nested deep down across multiple levels.

As an inspiration, we’ll start off with a concrete practical use-case of an example menu bar for a desktop application. I’ll pick a subset of the Chrome browser’s menu bar to illustrate this.

We’ll begin with a simple quite look-and-feel, something that goes back to the classic Windows™ theme. Here’s a short animation on how that would look like:

Towards the end, we’ll make it a bit fancier by adding some more styling to give it a MacOS™ like feel.

Impatient? Scroll down below to the Codepen embeds!

The Basics

Let’s start off by understanding what our menu items would typically constitute of. They should have the following properties:

Label : (required) which is basically the name of the menu item that is displayed
Target : (optional) a hyperlink that takes the user to a page as a response to clicking on the menu item. We’ll stick to just links right now. Adding more dynamic in-page features would require JavaScript which we’ll stay away from at the moment. It’s something you can always go and easily add later.
Shortcut : (optional) in our case, displays a keyboard shortcut that could be used for this menu item. For example, “File > New” would be “Cmd + N” (⌘N) on Mac.
Children : (optional) which refers to the sub-menu for this menu item. Think of our menus and sub-menus in the form of a recursive structure. Visually, a menu item having a sub-menu should also have an arrow icon on it (▶) to indicate that it can expand when hovered.
Disabled : (optiona), a state indicating if the menu item can be interacted with.
A conceptual Type parameter? (optional) that could emulate different types of menu items with this. Say, some entries in the list of menus should act as just a separator line.

Note that we could go ahead and add more complex behaviours to our menus. For example, a certain menu could be a Toggle item, and so, would need to have some form of a tick mark (✔) or checkbox associated with it to indicate its on/off state.

We’ll use CSS classes on our HTML markup to indicate such properties and write some clever styling to impart all the corresponding behaviours.

Structuring the HTML

Based on the above, this is how our basic menu HTML should look like:

A list of menus is defined by an HTML ul element, with individual items being the obvious li.
The label and shortcut will be placed as span elements with their corresponding CSS classes (label or shortcut) inside an anchor (a) tag inside the li, so that clicking on it causes the navigation action, as well as be able to provide some UI feedback such as highlighting the menu item on hover.
When a menu item contains a list of sub-menu (children), we’ll put that sub-menu in another ul element inside the current menu li element (parent) and so on. To describe that this particular menu item contains a sub-menu and also be able to add some specific styling to make it functional (as well as visual elements like the ▶ indicator), we’ll add the has-children CSS class to this parent li.
For items like the separator , we’ll add a corresponding CSS class called separator to the li item denoting it.
A menu item can be disabled , in which case we’ll add the corresponding disabled CSS class. It’s job is to make this item non-responsive to pointer events like hover or clicks.
We’ll wrap everything off inside a container HTML nav element (it’s good to be semantic) and add the flyout-nav class to it for some basic namespacing of the CSS styles that we’ll add.

<nav class="flyout-nav">
    <ul>
        <li>
            <a href="#"><span class="label">File</span></a>
            <ul>
                <li>
                    <a href="#">
                        <span class="label">New Tab</span>
                        <span class="shortcut">⌘T</span>
                    </a>
                </li>
                <li>
                    <a href="#">
                        <span class="label">New Window</span>
                        <span class="shortcut">⌘N</span>
                    </a>
                </li>
                <li class="separator"></li>
                <li class="has-children">
                    <a href="#">
                        <span class="label">Share...</span>
                    </a>
                    <ul>
                        <li>
                            <a href="#">
                                <span class="label">✉️ Email</span>
                            </a>
                        </li>
                        <li>
                            <a href="#">
                                <span class="label">💬 Messages</span>
                            </a>
                        </li>
                    </ul>
                </li>
            </ul>
        </li>
    </ul>
</nav>

Adding behaviours in CSS

I lied. We’ll use SCSS instead.

Jokes aside, here comes the interesting part!

The menu (except the first-level “horizontal bar”), should be hidden by default.

Anything below the first level should only be displayed when the corresponding menu item is hovered upon using the mouse pointer. As you may have already guessed, we’ll heavily rely on the CSS hover pseudo-class for this.

Arranging menu and sub-menu elements

Perhaps the trickiest bit in this whole puzzle is to understand how we make the sub-menu position and align itself with respect to their parent menu item correctly. This is where some knowledge of CSS positioning comes in. Let’s look at that.

There was a reason why we chose to put the sub-menu ul element inside a “parent” li element. Of course, it helps us to logically appropriately put together the markup for our hierarchical content, but it also serves another purpose of allowing us to easily write some CSS to position a child element relative to the position of a parent element. Then we take this concept all the way to the root ul and li elements.

For doing this, we’ll use a combination of absolute positioning and top, left CSS properties that will help us to position a child element relative to its closest non-static positioned ancestor defining the containing block. By non-static, we mean that the CSS position property for an element is not static (which happens by default in the HTML document flow), but instead is one of relative, absolute, fixed or sticky. To make sure of that, we’ll assign the position relative to the li elements with their child ul elements positioned absolute.

.flyout-nav {
    // list of menu items at any level
    ul {
        margin: 0;
        padding: 0;
        position: absolute;
        display: none;
        list-style-type: none;
    }

    // a menu item
    li {
        position: relative;
        display: block;

        // show the next level drop-down on
        // the right at the same height
        &:hover {
            & > ul {
                display: block;
                top: 0;
                left: 100%;
            }
        }
    }

The effect of this is shown in the image below, highlighted in the red box for illustration. Some additional CSS for visual styling has been done in the image to make it look all nice, but the core behaviour is defined by what we have above. This keeps working great to N-levels deep (within limits of practicality).

There’s one exception to this though, which is the first-level list of menu items (File, Edit, View… in our example), whose children menu items need to be positioned below instead of right. To handle that, we add some style overrides to our previous CSS.

.flyout-nav {
    // ... other stuff

    // overrides for first-level behaviour (horizontal bar)
    & > ul {
        display: flex;
        flex-flow: row nowrap;
        justify-content: flex-start;
        align-items: stretch;

        // first-level drop-down should appear
        // below at the same left position
        & > li:hover > ul {
            top: 100%;
            left: 0;
        }
    }
}

Note that using a flex-box here was not imperative, rather just something I did out of choice. You could achieve similar behaviour using other approaches such as a combination of display: block and display: inline-block on the ul and li items as well.

UI polishing

Once we’re done handling the basics of positioning the menu items, we’ll go on about writing some additional styles such as fonts, sizes, colours, backgrounds, shadow and such for making the UI feel all nice and better.

For consistency and reuse, let’s also assume that we have such values defined and shared using a bunch of SCSS variables. Something like…

// variables
$page-bg: #607d8b;
$base-font-size: 16px; // becomes 1rem
$menu-silver: #eee;
$menu-border: #dedede;
$menu-focused: #1e88e5;
$menu-separator: #ccc;
$menu-text-color: #333;
$menu-shortcut-color: #999;
$menu-focused-text-color: #fff;
$menu-text-color-disabled: #999;
$menu-border-width: 1px;
$menu-shadow: 2px 2px 3px -3px $menu-text-color;
$menu-content-padding: 0.5rem 1rem 0.5rem 1.75rem;
$menu-border-radius: 0.5rem;
$menu-top-padding: 0.25rem;

There are some pieces that we’re left adding the appropriate styles and behaviours for. We’ll go over them quickly now.

Anchors, Labels and Shortcuts - the actual visual elements

.flyout-nav {
    // ... other stuff

    li {
        // ... other stuff

        // the menu items - text, shortcut info and hover effect (blue bg)
        a {
            text-decoration: none;
            color: $menu-text-color;
            position: relative;
            display: table;
            width: 100%;

            .label,
            .shortcut {
                display: table-cell;
                padding: $menu-content-padding;
            }

            .shortcut {
                text-align: right;
                color: $menu-shortcut-color;
            }

            label {
                cursor: pointer;
            }

            // for menu items that are toggles
            input[type='checkbox'] {
                display: none;
            }

            input[type='checkbox']:checked + .label {
                &::before {
                    content: '✔️';
                    position: absolute;
                    top: 0;
                    left: 0.25rem;
                    padding: 0.25rem;
                }
            }

            &:hover {
                background: $menu-focused;
                .label,
                .shortcut {
                    color: $menu-focused-text-color;
                }
            }
        }
    }
}

Most of this code is pretty self-explanatory. However, did you notice anything interesting? The bit about input[type='checkbox']?

Toggle Items

For toggles, we use a hidden HTML checkbox element to maintain state (on or off) and style the label with ::before pseudo-element accordingly. We are able to do that using a simple CSS adjacent sibling selector.

The corresponding HTML markup for that menu item would look something like this:

<li>
    <a href="#">
        <input type="checkbox" id="alwaysShowBookmarksBar" checked="true" />
        <label class="label" for="alwaysShowBookmarksBar">Always Show Bookmarks Bar</label>
        <span class="shortcut">⇧⌘B</span>
    </a>
</li>

Separators

.flyout-nav {
    // ... other stuff

    li {
        // ... other stuff

        // the separator item
        &.separator {
            margin-bottom: $menu-top-padding;
            border-bottom: $menu-border-width solid $menu-separator;
            padding-bottom: $menu-top-padding;
        }
    }
}

Disabled

.flyout-nav {
    // ... other stuff

    li {
        // ... other stuff

        // don't let disabled options respond to hover
        // or click and color them different
        &.disabled {
            .label,
            .shortcut {
                color: $menu-text-color-disabled;
            }
            pointer-events: none;
        }
    }
}

CSS pointer-events does the actual trick here. Setting it to none makes it invisible as a target for any pointer events.

Putting it all together…

Now that we’ve gained some understanding of the building blocks, let’s put it all together. Here’s a Codepen link to our multi-level hierarchical flyout navigation menu in action!

Fancier theming

If you are not a fan of the retro Windows look, here’s another version of the same code with some minor tweaks to the CSS to make it look and feel more like MacOS.

What doesn’t work?

There are a few things we haven’t handled. For starters,

If you’re nitpicky about it, while most of the behaviour works great, a limitation of the deliberate CSS-only approach is that unlike the real-world Windows and MacOS application menus, our menu hides immediately as soon as the pointer goes outside. For more comfortable usage, typically what we’d want to do is wait for a click before hiding (can be always achieved with a bit of JS).
What if the list of items in a menu is super long? Imagine a bookmarks list as an example. At some point, it might need to be capped into a scrollable view, say at some percentage of the viewport height. At the end of the day, it’s really a choice of the user experience you’re building, but something I wanted to put out there as well.

Hope this was useful.

Cheers!

Starting a blog with a developer mindset in 2019

Abhishek Ghosh — Tue, 18 Jun 2019 00:00:00 +0000

In a previous post, I talked about my motivation for starting this blog.

But starting and maintaining a blog is a lot of hard work. First, you have to decide what to name it, then figure out how to set it up and host it, what content management system would work for you along with their features and pricing, is there a theme to the blog - whether you’d prefer to stick to some particular subject or be more open - something that imparts a sense of “character” or “identity” to the blog. And all this before you’ve got the chance to put serious thought into how you’re actually going to keep posting regularly - creating the actual content for your blog - which may just turn out to be the most difficult part!

When I ventured out, I knew I wanted to focus on a “developer blog”, so at least I knew the theme I was going after. I thought that was a great starting point.

Soon enough surely, hesitation kicked in.

Should I go for some hosted platform solution, or have something I can call more of my own? Do I deploy a ready out-of-the-box framework, or start building something from scratch? Or probably something in between? What is a trusted and affordable service provider that I could use for hosting my content? How much should I even begin with as a spending budget for this? Will I get locked-in on some service provider or technology choices for storing my content? How difficult could it be to move my content to somewhere else if I wanted to in the future? How will I ever even manage to get an actual audience for this blog?

I had all the liberty to feel giddy looking at the number of options available and the choices to make.

Baby steps.

Eventually, I decided to go down the path of setting up my own domain and creating my blog as a static website generated using Gatsby and hosted on Netlify.

In my first blog post, I did add a light-hearted remark around “all the cool kids using Gatsby these days”. And who doesn’t want to be cool, yeah? In fairness though, my decision to follow this path was more deeply deliberated than just getting on the hype train. So far, it seems to have been a good decision.

Now I am not going to make this article a “Yet another post on how to set up your blog with Gatsby and Netlify”. There are a great, many, resources, all, over, the, web on that already!

What I will focus on instead, is sharing my rationale towards making that decision.

I’m certain there are people out there embarking upon the path of setting up their blog and in the process going through some of the same dilemmas that I did. This is an attempt at being of some help if I could.

⚠️ Content below is bespoke and opinionated.

Here’s are the things that mattered to me, which I’m going to talk about today.

Self-owned content rather than hosted at somebody else’s mercy whom I’m probably paying again to serve content that I created.
Creative freedom and customizability to establish identity and individuality.
Technical freedom to do more under the same roof.
Statically built website for speed, frugality and agility. With possible eco-friendliness sprinkled on top.
Transparency, portability and version control of content
The subliminal developer experience
A pretext to learn new things and apply them
But why Gatsby? Why Gatsby at all?
So, is it all sunshine and rainbows?

Self-owned content rather than hosted at somebody else’s mercy whom I’m probably paying again to serve content that I created.

I prefer to fully own the content I create, published at my discretion and not subject to some third-party hosted platform’s changing policies and potential censorship. This is why I didn’t go for hosted solutions like Medium or even Wordpress.com.

Not to mention the associated service’s usage pricing models that would be involved: while they all start free, the way it typically goes is that as you get bigger, or desire to be more customizable or feature-rich, it’s common to charge you for various ancillary and auxiliary services. I’m not at all saying that’s unjustified considering all the useful services they may provide, rather something that I felt wasn’t worthwhile for me. At least not as the canonical place to put my content.

Creative freedom and customizability to establish identity and individuality.

The other reason I didn’t prefer hosted solutions is simply the fact that they all practically provide canned, run-of-the-mill experiences to everyone who signs up on their platform. There’s a lot of merit in the standardization of things. As someone who lives off building things for the web, you can understand probably where and why my sentiments lie in the context of standardizing things, but in this case, I’d clearly choose to move away at the behest of creative freedom.

A blog, portfolio (or both?) that I’ve put out there should reflect what I feel defines me, is unique or just the way I want my audience to experience it. I should be able to design an user experience with the look-n-feel and feature-sets that I want, free from limitations imposed by a certain service or platform that I’m using.

As a developer, being able to have that free reign is critical to me. I can afford to invest some time and effort to have things built exactly to my will. Not being able to do so today or tomorrow is not a chip I’m willing to bargain.

Some platforms like Wordpress do offer you decent degrees of flexibility, but still, come with a lot of opinions and often fall short of what you want to achieve, either ending up with practical limitations or simply becoming too cost prohibitive and making you lose interest and give up. Some other platforms are even worse. Forget customizing too much, Medium for one has stopped providing some basic capabilities to build your identity such as associating a custom domain name with your blog. They used to do that at a steep price at some point, but have stopped now altogether. I have my personal speculations (a gun to the head of your potential future from easily moving off their platform?), but that’s a conversation for another day.

Technical freedom to do more under the same roof.

Continuing with the above, it’s not just limited to the blogging aspect of it. I can imagine a future where I’d probably want to create custom content - say experiments, projects or labs that I’d want to set up, talk about and share. Being able to host and serve all of that together under the same roof would be great.

There are some counter-arguments to this. In theory, I could still host my blog on some chosen software platform, put that behind a domain and wire other enhancements hosted elsewhere through sub-domains and such… or even some hypothetical under-the-hood rewrites, as unlikely as sounds. I imagine it’s a decision probably best deferred. Right now, the best I could do is make the least assumptions and keep as many potential pathways open as I can. Cheers to Occam’s Razor!

Statically built website for speed, frugality and agility. With possible eco-friendliness sprinkled on top.

This is a popular school of thought now, and in my opinion for a lot of good reasons. At the moment, I have been bought into the general philosophy behind JAMStack. As a frontend engineer, I can’t help but confess that it has quite effortlessly grown close to my heart. I love the way how it naturally bakes in the segregation of data and view so easily into its core architectural principles and then enables a myriad of use-cases from the simplest to adequately complex web applications to be cheaply hosted, effectively scaled and swiftly modified to ever-changing needs, the 2010s-generation definition of “static websites”. Yes, that involves ample amount of client-side rendering, but we’ll try not to pick up pitchforks with the performance aspects of that just yet.

The use-case of a blog flows in surprisingly well into this paradigm. The actual content of your typical blog is predominantly going to be crafted manually rather than being dynamically generated. It’s not going to change on the fly from one reader visiting your blog to another. So are the pages that are rendered with the content, which can be crafted fairly well at build time rather than runtime.

There are definitely conceivable things could give your content an edge when done at runtime (say more complex features or optimizations around ranking content or a dynamically computed “top posts this week”), but most of these would be second or third order capabilities for a personal blog rather than the core experience, and if some sweet spot exists between dynamic generation vs. something that is fully statically built, it would fairly strongly lean towards being sufficiently achievable through intermittent build-time computations in a controlled environment as opposed to runtime calculations that need to be done every time a page is requested.

Avoid doing at runtime what you can do at design time. With that in mind, it doesn’t make a lot of sense to introduce an added dependency on a server requiring computational power to serve predominantly non-dynamic content, and on account of that, consume some energy. Again scaling those servers with more computational power with added traffic. More servers, more energy, more money. For a lot of apparent scenarios, it may not seem that big of a deal, but it feels quite wasteful to me.

With pre-built static components though, it becomes a fairly trivial matter in comparison of having to dumbly serve some static files without any complex computational needs, which can then be done by cheap, distributed and easily scalable CDNs. You can practically eliminate the time and energy required to compute things on the server over and over again and consequentially the need to even commission those servers, and at the same time be more easily available and closer to your audience with this static content that can be readily cached and distributed geographically.

Both of these factors are going to improve your user experience by making the pages of your blog load much faster.

Without the need for provisioning servers with custom requirements and computational demand, these CDNs come really cheap and easily scale by replicating themselves at various points of presence, which lets them respond to your audience with your content much faster. Imagine the pain you’d have had to go through if you realised you needed to deploy custom servers that compute your content, all across major geographical areas!

Case in point, Netlify provides services that are practically free of cost for hosting static websites to until a quite sufficiently large amount of traffic per month. If I were to go beyond that consumption for my blog, I’d take it as a happy problem to have, and pay for the additional amount gladly! On top of that it provides a bunch of other great things that I love, and I’m pretty sure you will too. Not an affiliate promotion. Just a happy customer.

Security-wise, data isolation is not something that I was gunning for here. That’s by design, where the usual idea of a blog and it’s content is to be available publicly, as was for me. Data integrity, however, is surely important, and something we can work out given a CDN service provider of choice, as well as make sure that we’re doing some basic things such as serving content over HTTPS from the CDN edge servers. These are pretty elemental at this point and commonly supported by these service providers out-of-the-box. For more scrupulous aspects of security, that would sadly be beside the point of this article. And the fact that you’re probably not looking for a security expert in me right now. So I’ll stop digressing more on that front.

Transparency, portability and version control of content

Imagine owning a blog with a large number of articles, thoughts, and posts that you’ve accrued over time with your blood, sweat and tears. Now imagine all that gone in a poof due to a database corruption with your blog hosting service provider. It makes my skin crawl.

Hosting service providers will generally make sure to host your content well. But bad things happen. Systems fail. And while the scenario of an acute loss of system availability may seem a little bit contrived in context, considering any well-meaning and sensible hosting service provider will intend to (and hopefully) make certain of data redundancy, at the end of the day it’s a matter of placed trust and the perceived transparency.

Of course, the whole damn world is running on the cloud. But not every cloud thunders the same, so to speak. My goal here is not to be paranoid but I’d prefer to avoid losing any sleep over this. It’s not possible for me to know upfront how well-built a certain xyz-affordable-hosting-dot-com might be, or to be more appropriate, the quality of service it’ll always provide me.

So rather than going down the route of hiring some service provider who spins a server and a rents out some storage space in some hosted database somewhere where it becomes hard for me to easily keep track of all the content that I create and keep changing; or don’t even know how complicated it is going to be to port all of that content in and out of that system, I’d bias towards keeping things simple and stick to mechanisms I already trust to not make my life harder later.

For a blog which is again mostly text-based serialized documents in some form and could be easily stored directly as files, rather than relying on some database-service backed system that stores my content and then potentially requires some additional processes (and SLAs) to push, pull, transform or migrate data, I’d stick to a simpler way where the content I create is retained directly natively in the form I created them. As files. In some repository. In the same way that I’m used to storing and maintaining with a lot of reliability, the source code that I write, again, with my blood, sweat and tears. This also gets me all the benefits of a well-defined, robust, and battle-tested version-control system.

I’m talking about authoring in Markdown and maintaining them on Github (or GitLab or BitBucket if you will).

I know I don’t have to sell Markdown here. In developer-town, it’s quite the universally accepted format for authoring documents. So I’m probably safe to not worry about potential pains of migration later if I wanted to move all my content from one system to another. If in future my destination system needs to understand something other than Markdown, it’s still probably possible that there’s some transpiler available somewhere, if this so-called destination system is popular enough.

What’s truly great about this approach is now the content that I create is apparent to me, how it’s stored and transformed. It’s simple. They are files. I can hit a simple file copy and replicate them as many times as I want, back them up when I want, where I want, extremely easily (probably along with git repo itself to preserve the versioning and it’s history). Given that, the chances of me losing it all is really, really slim. It does come with placing a lot of trust on Github really. That’s fair. Also acceptable. And definitely a much better bet than xyz-affordable-hosting-dot-com.

The subliminal developer experience

In continuation of the above theme, this is where I risk pissing off some great proponents of separation of concerns who also believe that all things should be black or white.

For me as a developer, maintaining my blog is not too different from maintaining any other software project. In fact, it’s both.

In the developer ecosystem, we’ve historically built great systems and tooling to make sure things work the way they are supposed to, and that building and maintaining those things are a good experience.

So it naturally feels great to impart a lot of those benefits to creating and maintaining content as well.

Does that mean we store all of that code and content intertwined together? The initial thought of “coupling together” code and content sounds repulsive. Where is the abstraction, the modularity, the single-responsibility, the separation of concerns? Oh, and the risk of non-generalization of software? Heresy!

But sacrificing those qualities is not exactly what we’re doing here. What I merely suggest is a bit more nuanced mechanism for the specific use-case of creating and maintaining a personal blog (or even one managed by a small group of people).

I know a typical personal blog is not going to blow out of proportions, neither does it have to be overly generalized and potentially over-engineered. So I’d start with a simple setup that I can easily maintain. Starting with one repository that contains everything is perfectly fine. In fact, having it all together pleasantly surprised me with some unexpected advantages!

It’s one single portable setup, and I don’t have to run around between multiple workplaces, editor instances or software tools which are essentially contributing to the same thing.

I get to use the same toolchain to construct my content that I use to construct my code. Writing content feels like writing code. When I write a new article, I get the benefits of pushing a version-controlled commit to a Github repository, a hook that automatically kicks off a build in Netlify when this commit is pushed and then deploys it to their CDN that hosts my website, through continuous deployment. It’s a simple workflow, predictable and hassle-free. It makes me happy.

The best part is, when I create content and see it in action, I get the benefit of getting instant feedback on code components that I build for rendering the pages of this blog off that bare-bone content, and if I need to tweak something, it’s a fairly simple matter of modifying the code in a file that I also have open in another tab in my code editor. I am my own principal customer, and it’s one of the best things that can ever happen to a software developer when building a product. I call this the “firewire of feedback” (yes, I just came up with that now).

It’s important to realise that building a blog - both the content and the software around publishing it - is not a one-before-the-other process. They happen in tandem. The day you first set up your blog; and every day henceforth. So as long as scale permits, and your source is designed to not complicate a separation if ever required later at a later point in time, it’s perfectly fine to have had put them all together now.

At a superficial level, this can sound unconventional, but not all conventional wisdom of the time is necessarily right. I’m tempted to draw a parallel to the kind of backlash that us “separatists” may have helped contribute to when React came along and said it’s probably better to put HTML, CSS and JS code all together in one single file for a component. But I will not. It’s a bit too extreme. And not very analogous. But hey, we all know how that went. It’s correct if it’s done for the right reasons. I guess the way to look at it is re-evaluating over time whether the concerns, in fact, are really so separate.

A pretext to learn new things and apply them

So far I talked about the means and the motive. Let’s also talk about an opportunity in the overall equation.

This is perhaps the simplest reasoning of all.

The idea of setting up your own blog, building features and being able to customize it to your heart’s content does come with a great appeal to a developer who’s excited to play around with new things.

It’s of course always possible to go about hacking around with new stuff anyway, but in my experience, more often than not such endeavours end up remaining temporal and isolated efforts, which without a structured motive to build, maintain or scale something do not really lead to any sustained excitement or a meaningful learning experience.

It just works better when you have a real-world target use-case in action. So why lose a great opportunity to capitalize on that?

Great software is built on well-executed principles of abstraction. I don’t love abstractions I don’t understand. I do love them later, but only after I’ve broken into, dissected and then put ‘em all back together. I love to work with primitives. I like to understand how the tools in my belt work… to a sufficient degree. This is not to say that I’d prefer to reinvent the laws of motion before using them to solve a problem, but I am just one of those people who can’t stay away long from getting their hands dirty messing around with the nitty-gritties. This habit is not always necessarily your friend. Sometimes, it just likes to manifest as a compulsive disorder.

So here’s me simply cashing in on that to learn a new concept or just a new way to look at a problem. Or a framework, tool or language. Fiddling with them. Applying them in context to real-world problems.

It enriches you.

But why Gatsby? Why Gatsby at all?

"I wasn't actually in love, but I felt a sort of tender curiosity."
— F. Scott Fitzgerald, The Great Gatsby

Come on. I could not just pass on the opportunity to not do that.

But putting all the flare and drama aside, it really boils down to one dead simple fact. For me, Gatsby simply seemed to fit the bill really well.

I wanted a static site generator, but in a language or toolchain that I was comfortable sticking around with for a while. And Gatsby seemed to meet that, along with having been a massive success in the JavaScript frontend community.

It seemed-thought through and well-designed, with a lot of the right bells and whistles to make you productive, yet comfortably distant in its own way to not breathe down your neck with too many opinions on how to build websites.

It came built using technologies I was convinced I would be interested to learn and play around with: React, GraphQL. And a thoroughly justified rationale at that.

It seemed to come with an architecture that consisted of well-defined component lifecycles and somewhat neutrally opinionated hooks for common and useful things, making it immensely pluggable and strangely powerful at the same time.

It did not come with a prescription on what to build and how to build it. It was not a blogging solution. But it was a solution using which blogs, and thankfully much more, could be so elegantly built.

It had great community support, and the right pedigree to build websites that are genuinely fast, that’s not just focused on the final end user experience (UX), but also the developer experience (DX). Powered with Webpack it supported out-of-the-box hot-reloads, came with a lot of sensible defaults, a large number of plugins and a rich set of guidelines, starter packs and inspiration to get you up and kickin’ sooner than you’d believe.

And great support for easily building Progressive Web Apps (PWA). The direction things are going, it’s probably fallible today to underestimate the power of PWAs. But I believe it’s even more dangerous to underestimate the power of a simple, elegant and well-built tool to facilitate building PWAs.

Maybe I did actually fall in love with it. Or maybe not. But rest assured I was convincingly sold enough to go ahead and give it a real try.

The documentation could improve though in being a bit more detailed, I suppose.

There’s a detailed chart of what Gatsby can and can not do in comparison to other popular static site generators such as Jekyll or content management systems (CMS) like Wordpress or site-builders if you’re interested.

So, is it all sunshine and rainbows?

Surely not. But it’s more sunny than gloomy though. In a good way.

At the end of it all, Gatsby is still a static site generator, although deceivingly powerful.

There are some features that a more “true” and powerful CMS with more dynamically rendered content and features could provide that I could wish for. Remember that dynamically computed “top posts this week” example I had in a section above?

However, having the pros and cons weighed and the cost-benefit measured, the return on investment of using Gatsby and Netlify in building and maintaining a blog has been so far simply amazing! And I would not have it in any other way! Well… if the software industry has taught me something, never say never. But today is not that day.

Also, not having gone the route of using an existing hosted platform that has baked in capabilities to distribute your content within its community, gather audience and cross-pollinate, it definitely becomes a much harder challenge to figure out to gather a sustained audience. To be honest, it’s one of the biggest things to solve for a successful blog. And I have not solved that yet.

There are definitely a bunch of ways and ideas though. For one, I could always cross-post keeping my own blog site as the canonical, to start seeding some community presence and feedback. It’s a common pattern, and I believe many communities, such as Dev.to, encourage that (I absolutely adore what Dev.to is and stands for). Over time, I definitely plan to add more capabilities to my blog to subscribe readers, share, and engage them.

It takes some time to create good content, surface that (be it on dedicated communities or search engines) and start getting people to talk over it. It’s not easy, but neither unthinkable. Existing on a hosted platform does not solve that magically as well. It’s hard and a much longer battle, but people have done that time and again. And it’s a topic that I’ll want to talk about in more detail as well in future sometime.

So that’s about it today.

Phew, that was one long article! And I genuinely appreciate you if you’ve read all through it and come this far!

Feedback and opinions welcome!

On personal blog as a software developer

Abhishek Ghosh — Sat, 01 Jun 2019 00:00:00 +0000

I have been setting up a blog for myself very recently. This is a cross-post and the first ever that I'm posting on dev.to.

I am a software engineer. I have been in the industry for five years now. I have been part of a "big-five tech company", working on things that more often than not, gives me the opportunity to fulfil my intellectual need and curiosity as a developer. All that is great. However, when I look at the general developer community out there, I largely don’t exist.

Five years is a significant time for someone to learn, grow and establish themselves out there. Not that I have not grown or established myself professionally - in fact, it’s quite the opposite - I could confidently say that all this time, there has been a tremendous amount of learning on my part for which I am quite so thankful. A lot of that learning and expression of skills, for good or bad, ever so stays within the confines this immediate environment and the people within it, where I get to exist comfortably in that world of its own! While no matter how great that can be, in the globally open community out there, I still don’t quite so, exist.

I’d be lying if I didn’t say that I was tempted to blame it on the fact that I would have been engrossed in technologies and projects that existed within that cocoon, or that I felt that I always had more things to do than I had the time to sit down and share with the community my thoughts or those little side-projects which I’d think why would anyone even want to care about anyway? But that’s not necessarily true. I didn’t get around since I hadn’t bothered enough to, myself. I somehow did not feel that need. In retrospect, that’s a bit of a regret.

So why this new-found urge to exist out there now? It’s for sure not about showing the world how ‘great’ I am. This is not a showcase or portfolio. Or even the fact that I don’t really care for one. I am definitely not looking out for work opportunities as well. I wouldn’t naively disagree that having a great community presence and a medium to talk about your work, skills or interests definitely adds to your career, but that’s not why I believe I have this lingering feeling that I need to put myself out there. This is not an egotistical existential crisis. This is an epiphany - that largely - this situation, this pattern - is in fact, the general, sad truth out there.

I personally know a lot of great people, who have so much to offer. I don’t personally know even fractionally close to as many people who have actively found out and settled down on ways to be part of and regularly contribute to the general global software development community out there. Of course, everyone is entitled to their choices, but as for me, I can only genuinely hope that I am not on the wrong side of this universe.

"I do not know what I may appear to the world, but to myself I seem to have been only like a boy playing on the sea-shore, and diverting myself in now and then finding a smoother pebble or a prettier shell than ordinary, whilst the great ocean of truth lay all undiscovered before me."
"If I have seen further it is by standing on ye sholders of Giants"

-- Isaac Newton

It’s generally agreed that the software engineering industry is something that is split out so vast in its breadth and depth and ever grows so exponentially, that it’s practically impossible for anyone to really grasp and know about most of any of it at all. This is not something necessarily special about this field though. It’s the general hallmark of anything worth having knowledge about. Even Isaac Newton, the man who discovered the laws of motion, invented calculus, and fundamentally changed the understanding of the physical world around us at his time, is famously quoted more than once to have shared such sentiments. And it is not surprising to see how much the software development community suffers from imposter syndrome.

I can’t help but feel that this is perhaps one of the biggest reasons as to why I, and like me, thousands of others, may have not cared enough to bother putting ourselves out there.

But I’m going to give you a counterpoint to this. This, in fact, is exactly the reason why we should care about putting ourselves out. There is too much out there to know and share, and we are, in fact, all just boys, girls or otherwise, playing on the proverbial sea-shore. Finding a few more pebbles to play with will only make everyone happier.

We have all had our own unique forays into the world of software development, with our own unique experiences leading to the acquisition of a unique combination of knowledge and realisations out of the knowledge acquired.

Not that all of this specifically applies to just blogging (there are so many other avenues that we can try), but in the context of this conversation, that’s the extent I will resort to. Personally, I don’t think I need to preach again and again and again why having your own blog as a developer is a great thing and how it benefits you (and the community). I believe a lot of people have already done an amazing job out there on explaining all the great things about doing so.

What I will urge though, is hankering about it.

So as it seems, this post evidently turned out to be a shoutout to my inner self and then to all of those people out there! There is enough substance in you to share. There’s someone somewhere out there who may be desperately seeking an effective way to obtain the knowledge that you may have in your possession so nonchalantly. Of course, not every bit of information needs to flow free openly, that’s fair. But there’s ever far so less than what positively could be.

So give it a shot.

If nothing else, this attempt will still result in the creation of a medium of expression and validation for yourself in the least. Hopefully, that could be motivation enough for some.

So this blog is my attempt at practising what I preach, a little pebble at the shore of that great ocean!

Better late than never?