I’ve been learning Rust lately.

Rust is one of the most loved languages out there, is fast, and has an amazing community. Rust invented the concept of ownership as a solution memory management issues without resorting to something slower like Garbage Collection or Reference Counting. But, when you don’t need to be quite as low level, it gives you utilities such as Rc, Arc and Cow to do reference counting and “clone-on-right” in your code. And, when you need to go lower-level still, you can use the unsafe system and access raw C pointers.

Rust also has a bunch of awesome features from functional languages like tagged enums, match expressions, first class functions and a powerful type system with generics.

Rust has an LLVM-based compiler which lets it compile to native code and WASM.

I’ve also been doing a bit of Swift programming for a couple of years now. And the more I learn Rust...

I was going to write an article about how Shadow DOM has been a horrible idea and here comes Manuel Matuzovic with an article that lays out exactly what’s wrong with it.

The article is balanced and well considered, so I’m going to feel free to be more unhinged and not mince my words when I say that Shadow DOM has been actively harmful to the web.

Let’s consider the 3 “pros” mentioned by Manuel.

• Style Encapsulation
• DOM Encapsulation
• Slots

Style Encapsulation

This is arguably the most useful part of Shadow DOM today and it is already not what most developers wanted when they asked for “scoped CSS”.

Usually, we want global styles to apply to our components. What we don’t want is styles that are only meant for our components from leaking out.

CSS will soon add true scoped selectors to CSS which is what we have wanted this whole time.

All the work and heavy-handed promoting of web...

A trend I have seen recently is that people are making some extremely flawed arguments against React. And then, these same people hype up web components and their only argument is favour of Web Components is that “it’s the platform”, as if implying that Web Components can somehow replace React or a similar UI framework.

One day I’m going to write a longer post taking apart some of the most flawed arguments, but first, I wanted to learn about Web Components themselves. What can they actually do?

What are Web Components?

Web Components is a term used to describe three new features available in the web platform:

1. Custom Elements
2. Shadow DOM
3. Template Element

Custom Elements

Custom Elements are elements with a hyphen in their name which can be defined as subclasses of HTMLElement in Javascript, but what makes them useful over using simple HTML elements?

After a lot of research, I think...

Back in 2020, I wrote an article titled “Features CSS Needs”

I wanted to revisit it since so much of it has already come true, and to update my list for 2023.

A More Powerful calc

Support for dividing units has been part of the official specification for years now, yet no browser has implemented it.

calc(100% / 100px) still doesn’t work. This is unfortunate as this simple enhancement would make CSS so much more powerful without the need to use much more verbose concepts such as Container Queries

More CSS functions — floor, ceil and round

The round function is a reality and supported in Firefox today! Better yet, it lets you do floor and ceil as well!

Logical Operations in calc

There’s some discussions about this, but nothing yet. At least we’re getting “Container Style” queries which handle many of the use-cases

ScrollTimeline

ScrollTimeline, (animation-timeline) is real and in...

Any mention of using Flow in the year 2023 causes strange reactions for web developers everywhere. Why would you do that!?

The tradeoffs won’t make sense for everyone, but there are actually some very compelling reasons to choose Flow instead of Typescript.

Let’s start with the things that Typescript is undeniably better at.

Typescript has much better availability of type definitions

If you look at NPM download metrics alone, Typescript is about 80x more popular than Flow. This comes with some serious benefits. Typescript is ubiquitous and virtually every module on NPM has typescript type definitions available.

If you’re using a type-system to improve your developer experience and get better auto-complete, Typescript is clearly the right choice.

That said, it’s becoming easier than ever to convert Typescript definitions to Flow. Flow supports mostly the same syntax now. You simply...

While the work on Houdini continues, I think it makes sense to prioritise a few simple features that would make life much easier for developers trying to build the most common things we need on the web.

I have carefully chosen the following features to fulfil two requirements:

1. They enable new functionality that was previously impossible or very difficult without Javascript.
2. They should be modest enough to be able to implemented in browsers.

Recent features such as scroll-snap-type, position: sticky and backdrop-filter are examples of simple capabilities that have greatly expanded the capabilities and quality of what we can build on the web.

A More Powerful calc

tldr; allow multiplication and division of mixed units

The calc function is a game changer. The function was introduced years ago and it enables us to achieve layout that most of think needs features like container...

Disclaimers:

• I’m not trying to start a flame-war. Both Typescript and Flow are great.
• I’m not a Typescript expert so feel free to correct me on Twitter (@naman34)
• I’m assuming Typescript >2.0 which includes non-nullable types (because nullbale-types === ?)

If you haven’t noticed, there are two popular ways of adding types to your Javascript code — Microsoft’s Typescript and Facebook’s Flow.

Both are extremely powerful, gradual, structural, type-systems. They also, look very similar, with almost the same syntax. Almost.

Often developers jumping from one system to the other get frustrated that all the things they learnt no longer work in the same way. And they assume that the features aren’t supported. And so, they do what any modern JS developer would do and vent on Twitter.

But wait, didn’t I just tell you that both type-systems are powerful. Everything you did in one type-systems...

I’m primarily a Javascript developer. I’ve written servers in Node.js for years, made small and big front-end apps, (mostly in React.js, of course) and written plugins for Atom and Visual Studio Code.

Yet, even after living and breathing Javascript for years now, I’ve never been quite content. I’ve always wanted something a little more functional. Javascript (I’m talking ES6) does great in many respects. It has first-class functions, tail call optimization. But it still lacks immutable data structures or a powerful type system. I’ve tried to fix these problems. I end up using Immutable.js for most of my projects, and I don’t write Javascript without flow anymore. Immutable is great, and flow is constantly getting better.

Yet, I like languages and I learn languages. I spent time learning the basics of Haskell and Elm. I can read OCaml. I’ve tried to get comfortable reading lisp (read...

Forget everything you know about Gulp. Welcome to Gulp 4.

If you’re a front-end developer you surely have a build process in place. You maybe using Grunt, Gulp, Broccoli, NPM scripts etc. If everything works for you and you understand everything in your build process, you should stop reading now and focus your energy elsewhere.

If, however, you’re confused or just want to learn a little more about Gulp hang around.

Using Multiple Files to Organize Tasks.

If you currently break your gulpfile into multiple files, you probably make a folder called gulp and using something like require-dir to import it all.

While this works for now, it has the effect of making your build process harder to read.

Instead, keep things more explicit. This happens in two steps.

Firstly, start writing you gulp tasks as simple functions and attach them to gulp.task separately.

So, instead of writing this: