DEV Community: Ben Adams

The GNU/Linux Desktop

Ben Adams — Wed, 12 Jan 2022 04:50:51 +0000

Almost every device runs with an operating system. There are many different operating systems available. The most common options on desktop are Windows, MacOS, and GNU/Linux, while on mobile the two most common options are Android (a Linux derivative) and iOS. However, there’s more than just those options available. For example, desktop has Unix, BSD and derivatives, and TempleOS. Today I’m going to talk about GNU/Linux and how I’ve been using it every day for theY

But First

What is an operating system? An operating system is a kernel and a set of tools and programs that will let you use the computer. The kernel is the abstraction layer between the hardware and the operating system, while the operating system is an abstraction layer between the kernel and the user. Windows currently uses the NT Kernel, and has since the first release of Windows 3.1 in 1993. Before switching over to the NT Kernel full-time with Windows XP, Microsoft used the MS-DOS kernel from 1985 to Windows Me. The macOS kernel is based on a BSD kernel. Linux is just a kernel, and the operating tools are provided by GNU. Different default tools are combined in different ways and released as distributions (also called distros or flavors).

Linux Kernel

Before the need for a Linux kernel, GNU (GNU’s Not Unix) was formed in 1985 as an alternative to the Unix operating system since it was not open-source. GNU developed open source versions of popular Unix software. However, GNU did not have a kernel to use for their OS tools. In 1991, a Finnish student named Linus Torvalds shared his kernel with a group of researchers working on Minix, another Unix-like operating. In his introductory email, he described his kernel

I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu).

Distros

Today there are hundreds of different GNU/Linux distributions available, all of them are more similar than different, but each tries to put their own spin, such as custom tools, driver support, different desktop environments, and different package managers. Most of the distros fall under the umbrella of a much older and sometimes larger distro. The big branches of GNU/Linux distros include Red Hat, Debian, Slackware, and Arch. Red Hat Linux uses RPM package manager, and its mainstream distros include Fedora, CentOS and openSUSE. Debian and its descendants store applications in a .deb format, and is installed using dpkg, which is used through the apt commands. Common versions of Debian include Ubuntu and its derivatives like Linux Mint and pop!_OS (which is what I’m currently using). Distros based on Arch Linux use pacman as their package manager, and common variants include Arch Linux and Manjaro. Arch Linux utilizes a rolling-release model to constantly bring new updates from the source code to the user. Slackware doesn’t have many descendants, as desktop users tend to use Slackware.

Why use Linux?

You should use GNU/Linux if you believe in Free and Open Source Software. GNU/Linux is extremely secure. Because the Linux kernel is open source, it currently has around 28 million lines of code, written by over 21,000 different authors. With that many eyes looking over the source code, vulnerabilities are (hopefully) caught and resolved quickly. Linux is currently used all around the world, as most servers run Linux, and the majority of the top supercomputers run Linux as well. Linux is also very stable and configurable. The stability is attractive for server use, and the configurability is attractive for supercomputer use with their unique hardware setups and specialized use cases. Linux servers are also secure because of the practice of least permissions required for each process.

You should use GNU/Linux if you want a more Unix-like experience without being locked in to Apple hardware, if you are worried about Apple and Microsoft tracking you through using their OS, or if you want to use a computer without paying for an OS like Windows. While there will always be software that only runs on MacOS or Windows, there are many FOSS alternatives available on GNU/Linux. Package managers also very helpful tools for keeping all of your installed applications up to date – no more downloading executable files from the web and hoping for the best.

I switched to Linux for the ease of installing and removing programs through a package manager and because I knew that I wouldn’t need any Windows exclusive features (primarily gaming) on my laptop. I also knew that GNU/Linux requires less system resources than Windows, so that my hardware would last for longer without feeling sluggish.

Maybe I shouldn’t

Switching to GNU/Linux can be daunting and the amount of options can be overwhelming: Which distro do I choose? Which desktop environment should I use? Wayland or X11? These can be overwhelming for a new user. New users might be put off by the necessity of using the terminal to perform some mundane actions or to fix some software issue. GNU/Linux does not have the best hardware support from peripherals manufacturers, so it would be wise to see if the company provides Linux drivers before you switch. If you play a lot of video games on PC, Windows is still the best supported OS. However, Valve, the company behind Steam and the Half-Life franchise, is launching their own handheld gaming PC, called the Steam Deck, and it will run SteamOS v3, which is based on Arch Linux (after versions 1 and 2 were based on Debian). Hopefully, Valve’s Steam Deck will improve gaming and peripheral support on Linux – I’m banking on it, and plan to fully switch away from Windows in a few years.

Sources:

Bitwise Operations

Ben Adams — Tue, 04 Jan 2022 03:09:53 +0000

Perhaps looking through MDN, you might've come across the topics for Bitwise AND (&) and wondered what that meant. You've probably used the Logical AND (&&) operator before, so how is the single ampersand different from the double ampersand and what does bitwise mean?

Bitwise means that it operates on the actual bits (0s and 1s) of data that the computer understands. Numbers in JavaScript are stored as 64-bit floating point numbers, but when used with bitwise operators, numbers are converted to signed 32-bit Integers. Floating point numbers have a much greater number range (2.2250738585072014 * 10^-308 to 1.7976931348623158 * 10^308) and allow for decimals, but can be imprecise. For example, 0.1 + 0.2 = 0.30000000000000004 due to floating point rounding. Unsigned Integers are a bit simpler to understand because they are the binary equivalent of the decimal number. Unsigned Integers range from 0 to 2^N – 1, where N is how many bits. Depending on how signed integers are implemented (one's complement or two's complement), they range from -2^(N – 1) or -2^(N – 1) – 1 to 2^(N – 1) – 1, or -2,147,483,648 to 2,147,483,647 for a signed 32-bit integer.

JavaScript allows you to use non-base 10 numbers by using prefixes. You can write binary numbers by prefixing 0bor 0B before any amount of 0s and 1s. Octal, or base 8, numbers are prefixed with 0o or 0O and use 0 through 7. Hexadecimal numbers are prefixed with 0x or 0X, and use 0 through 9 as well as A through F. Hexadecimal numbers are typically used as shorthand representations of binary numbers since 32 consecutive 0s or 1s can be hard to read. Hexadecimal numbers are also used for representing colors in CSS.

Decimal	Binary	Octal	Hexadecimal
0	0b0000	0o00	0x0
1	0b0001	0o01	0x1
2	0b0010	0o02	0x2
3	0b0011	0o03	0x3
4	0b0100	0o04	0x4
5	0b0101	0o05	0x5
6	0b0110	0o06	0x6
7	0b0111	0o07	0x7
8	0b1000	0o10	0x8
9	0b1001	0o11	0x9
10	0b1010	0o12	0xA
11	0b1011	0o13	0xB
12	0b1100	0o14	0xC
13	0b1101	0o15	0xD
14	0b1110	0o16	0xE
15	0b1111	0o17	0xF

Four binary numbers (or bits) can be represented with just one hexadecimal character, making it much easier on the eyes.

AND &

AND	0	1
0	0	0
1	0	1

Like logical AND (&&), bitwise AND returns 1 when both bits are 1, akin to returning true when both expressions are true. This could be used for coercing boolean values into the numbers 0 or 1.

0b01101001 & 0b11011101 === 0b01001001 // or 73
0x69 & 0xDD === 0x49 // or 73
true & true === 1
true & false === 0

OR |

OR	0	1
0	0	1
1	1	1

Like logical OR (||), bitwise OR returns 1 when either or both bits match, instead of when either or both expressions evaluate true. It's an inclusive or.

0b01101001 | 0b11011101 === 0b11111101 // or 253
0x69 | 0xDD === 0xFD // or 253

XOR ^

XOR	0	1
0	0	1
1	1	0

Like bitwise OR, XOR returns a 1 when either of the bits is 1, but not when both bits are 1.

0b01101001 ^ 0b11011101 === 0b10110100 // or 180
0x69 ^ 0xDD === 0xB4 // or 180

NOT ~

Bitwise NOT returns the opposite for each bit.

~0b1101 === 0b11111111111111111111111111110010 // remember, we're dealing with 32-bit integers, so all of the preceding numbers were considered to be 0
~13 === -14

Due to JavaScript's signed integers using Two's Complement to represent negative integers, ~A + 1 === -A, where A is any number. The leftmost bit is 0 for positive numbers and 1 for negative numbers.

Bit Shifting

Bit shifting is literally moving the original bits of the number to the left or right a specified number of times. There are three kinds of bit shifting. << is left bit shifting, where however many 0s are inserted at the right of the number. If the new number exceeds 32 bits, the overflow is discarded, so the new number could be the opposite sign of the original number. >> is sign-preserving right shift, where the left-most bit is repeated however many times. >>> is right shift that does not preserve the sign and 0s are inserted at the left. Left bit shifting is another way of multiplying that number by a power of two.

0b1101 << 3 === 0b1101000 // or 104
13 << 3 === 104 // or 13 * 2 ** 3
0b11001110111011011110001111110010 >> 4 === 0b11111100111011101101111000111111 // or -51454401
0b11001110111011011110001111110010 >>> 4 === 0b00001100111011101101111000111111 // or 216981055

Practical Uses?

Bitwise operations can be faster than standard library calls, but it comes at cost of readability. These bitwise operators convert what would be 64-bit floating point numbers to 32-bit integers, so they can be used as a faster way of rounding a number to a whole number. By directly working with the 0s and 1s that contain the data we see, we are stripping away an abstraction layer for potential performance benefits.

Sources:

Monitors and TV Panels

Ben Adams — Tue, 21 Dec 2021 06:52:03 +0000

How are you reading this article? There's a very good chance that you're using a monitor to read this article. Did you know how many different types of technologies are used, and have been used, for displaying content. If you're reading this on a phone, there's a good chance you're using an OLED display, while your computer monitor is most likely a TN LCD display. Don't worry, we'll go over those terms below.

CRT

While there are plenty of display technologies, I'm gonna start with the CRT – Cathode Ray Tube. Those giant, heavy monitors and TVs that you often find for cheap or free on Craigslist. They've been around for a very long time, with the first commercial CRT TV becoming available in 1934. The first mass produced color TV – the RCA CT-100 – was available in 1954. CRTs use an electron gun to light up phosphors arranged on the inside of the glass you view to create an image. The color CRT TVs used three electron guns, red, blue, and green, to create color. The electron gun would start at the top of the screen and move from left to right (if you were facing the screen), and light up the phosphors to display the image. The phosphors don't stay lit for very long, so the electron gun would actually skip every other row before returning to the top of the screen. This technique is called interlacing and it basically tricks our eyes into thinking that we're seeing the full picture every frame.

CRTs' advantages are that they look good with any resolution, and have very fast response times. The "pixels" of a CRT are not perfectly square, and this could be an advantage depending on your point of view. CRTs' disadvantages are that they are very large, very heavy, and the dangers involved with the vacuum sealed, high voltage cathode ray. Starting in the early 2000's, CRTs were being replaced by Plasma TVs and LCD TVs and monitors. Today, CRTs mostly fulfill a niche for retro video gaming.

LCD

Liquid Crystal Display TVs and monitors were much smaller, and lighter, and used less power. LCD panels have a layer of liquid crystals between glass that lets light pass through it to display an image. Because they did not produce their own light, backlights were required. LCD TVs originally used a cold cathode fluorescent light as its backlight source, but these have been replaced with LED backlights because they are cheaper, slimmer, and use less power. However, there are three different types of LCD panels commonly found: Twisted Nematic (TN), In-Plane Switching (IPS), and Vertical Alignment (VA). These refer to how the liquid crystals are configured to block or allow light and it affects color, viewing angles, and refresh rate, and more.

TN panels were the first panel to really drive down the cost of LCD panels and make them more accessible. TN panels are noted for their fast response times and high refresh rates, and are probably the most common type of LCD panel. IPS panels are noted for their color reproduction and extremely wide viewing angles (178°) without color or contrast degradation. IPS panels make for great computer monitors, especially for professionals who need color accuracy. VA panels are noted for deeper blacks, and contrast ratio, than TN or IPS panels, and are mostly found in TVs. Black text can smear on VA panels, making them less ideal for computer monitor usage. TN panels can still achieve higher refresh rates than IPS or VA panels, so if a 240 Hz display doesn't refresh fast enough, you'll have to sacrifice color quality and use a TN panel.

Plasma

At the same time LCD TVs were replacing CRT TVs, large HD Plasma screens TVs were becoming popular as well. Plasma TVs offered some advantages over its LCD counterparts: darker blacks, wider viewing angles than TN panels, and a high internal refresh rate that reduced motion blur. However, Plasma TVs used more power than LCD TVs and were at risk for burn-in, where a static image (such as a news logo) would be permanently visible on the TV. By 2014, most TV manufacturers had ceased production of new Plasma TVS, as they had shifted their attention to OLED panels.

OLED

Organic Light-Emitting Diodes are panels where each pixel is its own light source and each individual pixel can be turned on or off, independent of its neighbors. This leads to true blacks without any light being emitted at all, while LCD panels would still need a backlight for other parts of the scene. Since less light is needed for darker scenes, OLED panels use less power than LCD panels for dark scenes, but can use more power for bright white scenes. OLED panels are commonly used in mobile displays (Samsung produces a lot of OLED panels that it uses in their own phones and others), and in high end TVs. OLED panels do not lend themselves well to computer monitors because they suffer from increased burn-in risk, like Plasma, so the static UI elements of a desktop experience are the exact things an OLED panel should avoid. As each pixel group of red, green, and blue LEDs emits light, they slowly start to degrade (but faster with higher brightness), and this degradation of each pixel at different rates (with the blue subpixel degrading the fastest) leads to burn-in.

Flash is Dead.

Ben Adams — Tue, 14 Dec 2021 06:36:05 +0000

Flash used to be the dominant technology to add interactivity and responsiveness to your website. Keyword: "used to". Before HTML5, CSS2.1, and better JavaScript engines, Flash was a great way to add dynamic elements to your website. It could stream video, it had interactive content that allowed for games, and it was all contained in a small file, which was very important in the era of 56K dial-up.

Humble Beginnings

In 1993 Jonathan Gay, Charlie Jackson, and Michelle Welsh founded FutureSplash Software to work on animation software that could use a pen as its interface, called SmartSketch. Unfortunately, the target OS (PenPointOS) was bought out by AT&T and discontinued. After receiving encouragement and recognizing a niche in the web market in the summer of 1995, SmartSketch was transformed into FutureSplash Animator and released in May 1996. At the time, the only way to show animations on the web required embedded Java, which had significant shortcomings in regards to performance and file size (remember, we're still on dial-up!). In 1996, NetScape implemented plug-ins with much better performance, so FutureSplash Animator was released as a plug-in. FutureSplash achieved almost instant fame since Microsoft used FutureSplash Animator for MSN, and Disney used it for their Disney Online site for animations and user interface.

At the same time, Macromedia was working with Disney Online and eventually acquired FutureSplash in November 1996. Macromedia already had Shockwave Director Player, which was used for higher performance applications, such as games or 3D simulations. Macromedia rebranded FutureSplash Animator as Macromedia Shockwave Flash Player (not confusing at all, right?) and released in 1997 with support for motion and audio. Macromedia continued to improve Flash Player, with version 5 being most significant for introducing ActionScript 1.0. ActionScript is an object-oriented programming and scripting language, and was similar to JavaScript since they were both based on ECMAScript 262. ActionScript allowed for more interactive Flash apps, such as games, e-commerce, and ads.

Adobe

In December 2005, Adobe bought Macromedia. At its peak, Flash was supported by 97% of all internet users. However, the good times would not last. Flash was still the dominant technology for interactive web and video streaming, but security concerns and outdated technology were piling up. In 2007, Apple released the first iPhone and refused to allow Flash to be installed, citing multiple concerns, outlined in a famous letter written by Steve Jobs in 2010 titled Thoughts on Flash. In it, Jobs articulates that Apple believes in completely open standards for the web, while Adobe Flash is 100% proprietary and closed. The web was also moving on from Flash video players as more and more sites were replacing Flash video players with HTML5 and the H.264 video codec. Mobile processors struggled to decode Flash videos in software mode, while, at the same time, they had a hardware H.264 video decoder, which improved video playback and nearly doubled the battery life of the iPhone. Adobe Flash was also notorious for being a security risk and Jobs did not want the security of the iPhone tarnished by a third-party technology and be reliant on Adobe for finding, fixing, and releasing updates in a timely manner. In addition, Flash Player was not designed for touch input, but for mouse and keyboard. Jobs reasoned that if developers had to rewrite their flash app to support touch input, they would be better off rewriting their app with newer tools and standards such as HTML5.

Other tech companies were in agreement that Flash needed to go away. Google had used Flash player for their video player in YouTube, but started to transition to an HTML5 player in 2010, with full support for HTMl5 in 2015. After numerous security vulnerabilities, Mozilla turned the Flash Player plug-in off by default in Firefox. Facebook had used Flash Player for their games and videos, but spoke out against Flash Player in 2015 and announced plans to move away from Flash Player. Microsoft stopped including Flash Player with Windows, which they had done since Windows XP. In 2017, Adobe announced that Flash Player would be deprecated, and it reached End of Life on December 31, 2020.

Gone but not Forgotten

Starting in 2014, people realized that Flash Player was on its way out. So the Internet Archive started archiving Flash games and videos that could be played through emulator called Ruffle.

Sources

Multithreaded JavaScript

Ben Adams — Mon, 29 Nov 2021 06:04:03 +0000

We've always talked about JavaScript as being a single-threaded interpreter, but as I've discussed in my previous post, the interpreter part isn't quite so true. So maybe the other part about being single-threaded isn't true either?

Multi-Threaded in the Browser

Turns out, we can make JavaScript multi-threaded by using WebWorkers. WebWorkers enable code to be run in the background, outside of the main thread. This can be useful to offload intensive calculations while the main thread that handles the UI remains responsive. WebWorkers can do almost all of the same operations that the main thread can do, except they can not manipulate the DOM or access properties of the global window object as they operate in a different global context.

WebWorkers are created with const myWorkers = new Worker(‘path to worker code’); and they use message passing to interact with the main thread. The WebWorker will send a message through the native function postMessage(), and the main thread will handle the message through the onmessage event handler. WebWorkers can be terminated early by calling .terminate(). WebWorkers can be created from other WebWorker threads as well.

There are three types of WebWorkers: Dedicated Workers that can only be used by a single source, Shared Workers that can be shared among multiple sources – but each source must be from the same domain, and Service Workers that act as go-betweens for apps, browsers, network, or cache.

Multi-Threaded in the Server

Node.js can also make JavaScript multi-threaded by using worker-threads. They are more useful for background calculations than for file I/O, as Node claims that their native asynchronous file I/O methods are faster than worker threads. To use worker threads, they must first be imported from worker-threads, and then created withconst worker = new Worker(__filename, { workerData: script });. Worker threads can create new Worker threads as well.

What's the catch?

Have an app that is multi-threaded sounds useful, as CPUs are now increasing multi-threaded performance at a faster rate than single-threaded performance is increasing. Multi-threaded applications can take better advantage of modern hardware, and can help make apps feel more responsive if the main thread that handles UI is never bogged down with a lengthy computation.

However, multi-threading introduces several issues. Writing multi-threaded code can be more difficult in implementation, testing, and debugging. If several threads are trying to access and change the same piece of data, one thread's results can change the results for a different thread, which is called a Race Condition. Multi-threaded code also needs more safeguards against these issues, so special code called Mutex (mutual exclusion) and Semaphores are used. Mutex will lock a piece of shared data until completion before releasing the lock, which can sometimes result in deadlock scenarios when a single thread has multiple mutex locks that can not be resolved and unlocked for other threads. Semaphores typically use signals and flags to prevent other threads from accessing that piece of data. Mutex and Semaphore code can be difficult to implement.

Looks like JavaScript can be multi-threaded. It's up to you to decide whether the benefits of concurrency and parallelism outweigh the different problems that they introduce.

Sources

WebAssembly

Ben Adams — Mon, 01 Nov 2021 04:04:39 +0000

If you want your application to be performant, you'd likely create a native desktop application instead of a browser based web app. That's where WebAssembly steps in. WebAssembly aims to bring resource intensive desktop applications to the browser with similar performance, with minimal difficulties. WebAssembly only requires the source code (of any language) be compiled into WASM's assembly-like language.

Arising from Asm.js

The idea of writing non-JavaScript code and having it run on the browser was previously explored through Asm.js, which would compile the source code into JavaScript. However, performance of Asm.js apps was about half of the native implementation. Even though Mozilla Firefox first launched support for Asm.js back in 2013, version 1.0 has yet to be released. Mozilla's Asm.js engine was called OdinMonkey. Asm.js required code to be compiled ahead of time.

Adoption

WebAssembly launched March 2017 and has largely replaced Asm.js, and as of this writing, over 94% of all web browsers support it. Some traditionally desktop only apps have already been brought to the browser with WebAssembly, like the game engine Unity, AI and ML library TensorFlow.js, AutoCAD's suite of software, and you can find more here. However, it still seems to be a rarity at this point, largely due to lack of exposure. Popular adblocking software uBlock Origin was rewritten with WebAssembly to be even more performant, see the below screenshot for a benchmark comparing JS and WASM implementations.

There are over 40 supported languages for WASM, while the initial focus was on C/C++ and Rust. Using Emscripten as the compiler, code can be easily compiled to WebAssembly

From the desktop to the browser and back again

Similar to how Node.js brought JavaScript to the desktop and server environments, efforts have been made to bring WASM to the desktop through Wasmtime, Wasmer, and others. Similar to how Node provides filesystem I/O to JavaScript, WASI is an API that brings several operating system-like features to WASM.

Not a JavaScript Replacement

While whole apps can be made with WASM, it does not have the ability to manipulate the DOM. So the idea is that most of the app can be made with WebAssmebly, and JavaScript will be used to fill in the gaps between functionality. This gives WASM apps the near native performance while still able to dynamically modify the site with traditional JavaScript methods.

Parting Thoughts

WebAssembly will allow for complex apps to be brought to the web, increasing accessibility and reach. WASM does not care about the user's OS or require additional plugins to run. WebAssembly has the joint support of W3C, Mozilla, Microsoft, Google, and Apple, so it's not going away anytime soon, and should only see more adoption. WebAssembly will allow more developers write highly performant web apps and make browsing the web a richer experience.

sources:

V8

Ben Adams — Mon, 25 Oct 2021 05:22:53 +0000

V8 is incredibly important to the web – and no, I'm not talking about the juice or the car engine. I'm talking about Google's JavaScript Engine V8 that launched with the release of the Google Chrome Browser on September 2, 2008 as a part of the open source Chromium Project. Before Chrome's release, JavaScript (and Jscript) performed slowly and would often bog down websites' responsiveness. I, and many others, would block JavaScript, using a Firefox add-on called NoScript. As seen in the image below, it was originally released for a much older version of Firefox.

Google had already created JavaScript intensive web applications like Gmail and Maps and recognized that JavaScript needed to be faster in order to improve their web apps, and decided to be the change they wanted to see. When Chrome launched in 2008, it used WebKit as its rendering engine, and a brand new JavaScript engine called V8. WebKit was originally a fork of KHTML used in KDE's Konqueror browser, and remains the rendering engine for Apple's Safari, while Google forked WebKit in 2013 to create Blink. Mozilla Firefox uses Gecko as its rendering engine and SpiderMonkey as its JavaScript Engine. Microsoft's Internet Explorer and early versions of Edge used Trident as a rendering engine, and Chakra as its JavaScript and Jscript engine (two different versions with the same name – definitely not confusing). Apple's Safari's rendering engine is still Webkit, as mentioned above, and its JavaScript engine is JavaScriptCore. When Chrome launched in 2008, it had the best JavaScript performance out of all the browsers due to its V8 engine.

The V8 engine launched with several notable improvements. The most obvious of these is a shift from an interpreter to a JIT Compiler. Interpreters read, parse, and execute code one line at a time. This means that changes to the source code and quickly integrated into the application – Python and Ruby are interpreted languages. This is in contrast to compiled languages like C/C++ and Java, which reads all of the code and converts it to a lower level language, often with optimizations. Compiled code often runs faster, but it comes with the drawback of needing to be compiled every time the source code is changed, and this can take a significant amount of time as the source code grows in size. A JIT Compiler tries to take the best of both worlds. It does not compile code ahead of time, but rather as each line is read, or several lines at once. If the JIT Compiler notices that certain code is reused several times throughout the program, it will save the already compiled code and call on that pre-compiled code when necessary. If a certain code block is called even more times, an optimizing compiler will attempt to optimize even further.

Another reason for Chrome's excellent JavaScript performance at launch was due to its multithreaded approach. Chrome keeps a separate thread for UI and I/O, and then dispatches as many threads as needed for executing JavaScript. In addition, each tab's threads are sandboxed from other tabs. This improves performance and stability by not letting buggy or lagging sites affect other parts of the browser, and takes advantage of the increasingly multithreaded nature of CPUs. By 2008, AMD and Intel had already released dual and quad core CPUs for consumers.

With the success of V8 and its influence on other JavaScript engines, people began to use JavaScript as a dependable and flexible programming language for larger projects. People began wanting to use JavaScript for desktop applications, and Chromium and V8 were brought out of the browser through Node.js. Node allows JavaScript applications to run on the desktop or through the command line. Node doesn't have access to browser exclusive features like window or document, but offers filesystem reading and writing. There are also forks of Node that use SpiderMonkey or JavaScriptCore instead of V8. In order to facilitate creating desktop JavaScript applications, the framework Electron.js was created in 2013 that uses Chromium and V8 to create cross-platform applications that use the familiar web app development process. Many apps we use every day are built with Electron, such as VS Code, Slack, Discord, Skype, and OBS.

The V8 engine ushered in a new age of JavaScript performance, and several competing JavaScript engines improved their performance by implementing their own JIT Compiler. For instance, Mozilla's JIT Compiler is called IonMonkey. Combined with ever evolving JavaScript features, web apps are able to do more than ever. Chromium and V8 were so successful that many other browsers are now based on the Chromium project, such as Opera, Edge, and Brave, and are responsible for over 70% of all web browser use.

Sources

Scalable Vector Graphics

Ben Adams — Tue, 19 Oct 2021 03:06:50 +0000

Scalable Vector Graphics, or SVG, is an alternative way to save and display images. Most images that we view on the web are typically saved as a JPG or PNG file, which both are two different file formats of raster images (other popular raster image formats are BMP, TIFF, and GIF). SVG, as its name implies, is a type of vector graphic, and has been in development since 1999 by the W3C.

Raster images are saved as bitmap images, which means that every pixel has to save the color information for every pixel, and this can exponentially increase in size as a larger color depth is used. Today, the common standard is called True Color and it assigns 8 bits per Red, Green, and Blue levels, so it's called 24 bit color. Thus, the formula to determine the size of a bitmap image is size = width * height * 2^color_depth. As the resolution of displays increases, the file size for bitmap image will also grow. A 1080p display has 2,073,600 pixels, while a 2160p (or 4K) display will have four times that amount, and 4320p (or 8K) TVs are already being sold. The size of uncompressed raster images will continue to grow.

To preserve space, compression algorithms were created. However, some compression algorithms will not return the exact same image when uncompressed. This is referred to as lossy compression. JPG is a lossy file format, but that means it can be very efficient with its file size. Instead of working with individual pixels, the JPG compression algorithm works with an 8x8 block of pixels – this leads to compression artifacts and fringing around the edges of text. PNG uses a lossless compression algorithm, and support for transparency. PNG does support animations, but I haven't seen it used out in the wild. Typically, images with animations are in the file format GIF, which is also lossless, but it saves space by only saving 256 colors, or 8 bit color.

In 2001, the need for low file size – but highly scalable images – was recognized as both higher resolution displays were entering the market and as mobile devices started to get internet connectivity. Enter Scalable Vector Graphics, or SVG. SVG is actually an XML file that merely describes the image in terms of lines, curves, thickness, color, and text elements, and this offers it great flexibility in scaling up or down on resolution, while being extremely cost efficient when it comes to file size. These attributes make SVG a very appealing format for logos and UI elements that need to scale up or down depending on the context. SVG images can be modified by CSS and JavaScript, making them ideal for use in web apps, as they can be changed on the fly without creating a new file.

SVG images have many practical uses and can (and, in my opinion, should) be used in many different applications. However, that's not to say that JPG or PNG should be immediately discarded. Photography images don't translate well to SVG, which is still the ideal scenario for a JPG image. PNG is still ideal for screenshots of text as it avoids the fringing seen with JPG compression. As always, find the right tool for the job, but consider using SVG somewhere in your next project – who knows, maybe you're already using vector graphics, as some fonts are already vector graphics.

Sources: