NOTICE: This is a
Work-In-Progress post, please do not read it yet! 🐌🐌🐌
Basic idea of some modern front-end concepts
- UI virtualization means that detailed visualization of items is deferred until we scroll the items into visible area of the web page or the
ViewPort. The term might have come from the concept of
Windowingthe elements i.e. lazily load elements which are within the current window
- The basic idea is, when there is long list of items to be shown, maybe with complex visulization using many DOM elements, the performance & memory load is improved by only displaying the detailed elements which are presently visible. Others are not rendered completely. The moment they enter the viewport, they get fully rendered with available data and logic
- The main difference between
- Infinite-scroll shows only a limited number of elements at start. So first load is fast. But after that, it keeps accumulating DOM elements, making the overall DOM heavier and heavier
- Virtualization on the other hand, always has only a fixed number of visible elements rendered, not more. This is generally achieved by discarding DOM elements once they move out of visible screen OR reusing the same DOMs with different data!
- Some examples - SlackGrid , Infinite-scroll, Variable height virtual list for Vue
Intersection Observer APIprovides a way to
changes in the intersectionof a
target elementwith an
ancestor elementor with a top-level document’s
- The most common use is to trigger something when an element enters the ViewPort, to implement lazy loading, infinite scrolls and the likes
- Mozilla docs
Canvas (and SVG)
Canvas is a comparatively new
HTML5 standard for painting images/graphics on the web! Canvas is just a rectangular area on the page, generally defined with an id, and height & width. The basic HTML Canvas element
<canvas /> has nothing in it.
SVG (Scalable Vector Graphics) on the other hand is a document structure for storing some graph representation. The
<svg> HTML element contains other drawing components as child HTML elements, which are generally geometric shapes like
CSS can be used to style them!
- Both can draw things on a web page, and are supported by modern browsers
- Both can be scaled & animated & have events, BUT in different ways
- Canvas renders as a single HTML element, whereas an SVG is a collection of HTML elements
- SVG is truly scalable. SVG scales seamlessly as the viewport or the spcific area of the page is scaled up or down, not much of additional effort is required. Also the SVG and overall document size remains same even if the graphics are zoomed in indefinitely. It can also be scaled using code. Canvas can be scaled only by redrawing the whole image again. And larger canvas means more pixels, which is more heavy on memory and resources.
- In general (though it depends on other factors), SVG works best when there are smaller number of drawing elements, and they need simple changes to styles, animate or to scale. Canvas works best for complex interactive drawings applictions like games, photo editing etc. where control over each pixel is more important.
HTML5 Canvas element. WebGL brings plugin-free 3D to the web, implemented right into the browser. Major browser vendors Apple (Safari), Google (Chrome), Microsoft (Edge), and Mozilla (Firefox) are members of the WebGL Working Group.
This conformance makes it possible for the API to take advantage of hardware graphics acceleration provided by the user’s device, i.e. it can take advantage of
GPU rendering for fast, efficient, parallel drawing without putting much load on the CPU.
What is GPU
Graphics Processing Unit in a computer, on a high level, is a processing chip consisting of a collection of many, low power computing units specially designed to efficiently handle graphics computation and drawing. But they can also be used for parallel, small computations. GPUs generally have many cores, in the orders of hundreds.
Central Processing Unit on the other hand is much more sophisticated, general purpose processing unit. Typical CPUs have a few (2-12) very powerful cores.
It’s also important to understand that a “graphics card” is not a GPU. GPU is just a chip, which is sometimes directly embedded in the motherboard (e.g. laptops) or SoC (System on a Chip, for mobiles), or can be put on a ditachable graphics card. A graphics card, along with a GPU, also has dedicated memory, connecting ports, cooling systems etc.
GPUs are specially disegned to handle graphical processings, which may include maths, game physics, display rendering etc. But they can also do smaller standard tasks like general computations. Since GPUs have many cores, they genrally can handle many threads concurrently, and can handle many tasks in parallel.
So, in brief
HTML5 Canvascan use
WebGLAPIs, which can use
canvas can be coded directly using the Canvas APIs or using WebGL APIs. Generally, programming the WebGL APIs is more complex than the standard Canvas APIs (example), but they bring in bunch of additional features, the huge performance boost of GPU rendering being the most useful. But, there are standard libraries available in the market to simplify this tasks, for example the three.js library. Some useful discussions here.
In some cases, the GPU acceleration is automatic; no special coding is required at all. For example, 3D CSS and Canvas 2D both run whether or not the PC has a GPU. If a GPU is found, the work gets passed to the GPU instead of the CPU. GPUs can render CSS transforms to create displays like pop-overs and animations, Canvas rendering of fonts, images, and vector graphics, and compositing, or blending layers, scrolling, and zooming. source
Worker is the main interface of the
Web Worker API.
Web Worker is a common web standard for background processing in
main UI thread (one per browser tab) can stay free and responsive, so that users do not feel any lag while using the page.
Web Workers can run any script, but it has few restrictions
- It cannot access the
- It can run
ajaxrequests, but the
- Not all
Windowfunctions are available. See details
- A worker can spawn new therads in terms of new
Workerinstance, but not all browsers can handle that (e.g. Safari)
- Some of the older browsers can only take
stringor primitives as
message. Most of the modern browsers can take a signle
objectas message though
To use a
Worker, a script needs to create an instance giving another script path in same domain. Then the other script runs in a background thread, and can send data to main thread using
postMessage() API, and vice versa. The main thread can listen to the messages using
onmessage() API on the instance.
See docs here.
What are Service Workers then?
They are pretty different. The are mainly used to provide
offline app experience.
They mainly work based on network availability and cached data and browser local storages like IndexedDB etc. The
Service Worker is generally a single instance per browser, which can serve any number of tabs. Some good discussions here.
ServiceWorkers essentially act as proxy servers that sit between web applications, and the browser and network (when available). They are intended to (amongst other things) enable the creation of effective offline experiences, intercepting network requests and taking appropriate action based on whether the network is available and updated assets reside on the server. They will also allow access to push notifications and background sync APIs.
You can render your graphics off the main thread with
OffscreenCanvas, using a
When doing heavy processing for Canvas e.g. for rendering high quality games etc. it might take a performance hit on the app, and may make the UI thread unresponsive.
The OffscreenCanvas API solves that problem by providing a native way to offload heavy canvas operations to backgrounds threads (through Worker, which needs to be configured through code). This can make the UI thread free, while the canvas is rendered in background, without using the DOM directly. Then it has a bunch of helper methods to transfer the generated graphics to the main canvas on page, or to mirror the OffscreenCanvas directly to the visible canvas. Docs here.
OffscreenCanvas is not well supported in all browsers yet (June 2020).
Web Component in itself is not a technology, but a set of DOM APIs to enable developers to build
custom HTML tags something like
<my-weather-widget></my-weather-widget> which can work on any
The main pieces that are generally put together to build
Web Component are
customElements- to define a custom
HTMLtag with a backing
ES6class, to support desired functionality
shadow DOM- a special area within the DOM to encapsulate and insulate the main page from the custom HTML internals, so that the
JSof the element does not affect the outer page & vice-versa
templateelement - a new HTML which can hold any
JS, but does not actually render on the page. This is sometimes used to hold the
customElement, but it’s not really required for building
Web Componentas such!
As these are native APIs supported by most modern browsers, and
polyfills being available for others, they can be built with plain vanilla
Angular Elements etc. Check this repo for some simple examples.
Virtualization, OffScreenCanvas etc.
WebGL & GPU
HTML Template strings & related APIs
- https://stackoverflow.com/questions/53244494/correct-way-to-apply-global-styles-into-shadow-dom, https://stackoverflow.com/questions/35694328/how-to-use-global-css-styles-in-shadow-dom
- What the heck is the event loop anyway - Philip Roberts
- Anjana Vakil: Immutable data structures for functional JS
- An introduction to functional programming
- Web Perf - Google dev
- Build with jake
- Accessibility for all, Accessibility - web fundamentals
- ARIA vs Semantic HTML
- Disability & Assistive Technologies - W3C
Flux, Redux, RxJS, Immutable…Oh my!