JavaScript Icon

JavaScript

JavaScript is an object-oriented programming language used alongside HTML and CSS to give functionality to web pages.
810 Stories
All Topics

JS Party JS Party #115

All the stale things

Divya Sasidharan leads a deep discussion with Jerod Santo, KBall, and Nick Nisi on what’s stagnating in browsers. What has remained the same in browser tech over the last 20 years that remains a pain point in working with browsers? For example - Focus in browsers hasn’t changed much in 20 years. Why is that and how do we go about making all the stale things in browser tech better?

JavaScript github.com

An extremely fast JavaScript bundler and minifier

Why build another JavaScript build tool? The current build tools for the web are at least an order of magnitude slower than they should be. I’m hoping that this project serves as an “existence proof” that our JavaScript tooling can be much, much faster.

According to the author, esbuild is fast because..

  1. it’s written in Go
  2. much of the work is done in parallel
  3. it takes very few passes and avoids data transformations
  4. it was coded with performance in mind
An extremely fast JavaScript bundler and minifier

The Changelog The Changelog #381

The dawn of sponsorware

Caleb Porzio is the creator & maintainer of Livewire, AlpineJS, and more. His latest open source endeavor was announced as “sponsorware”, which means it lived in a private repo (only available to Caleb’s GitHub Sponsors) until he hit a set sponsorship threshold, at which point it was open sourced.

On this episode, we talk through this sponsorware experiment in-depth. We learn how he dreamt it up, how it went (spoiler: very well), and how he had to change his mindset on 2 things in order to make sustainability possible.

CSS-Tricks Icon CSS-Tricks

Why JavaScript is eating HTML

Mike Turley for CSS-Tricks:

JavaScript developers have realized that by defining a page’s structure in JavaScript instead of in HTML (using frameworks such as React), they can simplify the development and maintenance of user interaction code that is otherwise much more complex to build. Of course, when you tell someone that the HTML they wrote needs to be chopped up and mixed in with JavaScript they don’t know anything about, they can (understandably) become frustrated and start asking what the heck we’re getting out of this.

I get this question occasionally and I often have trouble answering it. All of the materials I’ve found on this topic are written for an audience that is already familiar with JavaScript — which is not terribly useful to those who focus on HTML and CSS. But this HTML-in-JS pattern (or something else that provides the same benefits) will likely be around for a while, so I think it’s an important thing that everyone involved in web development should understand.

Crystal mint-lang.com

Mint – a programming language for writing single page apps

Mint has all the tools you need to write error free, easily readable and maintainable applications in record time.

Built-in styling, data management, language-level routing, and JavaScript interop make this a very interesting project, indeed. It’s still in heavy development, so the only real-world example you’re going to see is their implementation of realworld.io.

Marco Otte-Witte simplabs.com

How to over-engineer a static page

Marco Otte-Witte:

When we set out to rebuild our own website simplabs.com in 2019, we wanted to use that project as an opportunity to ignore all economic considerations (and reason you could say) and dive deep into what was technically possible. Doing so would allow us to build something that was super customized for our specific needs and highly optimized for performance. We ended up spending a lot of time and effort but are quite pleased with the result.

While we cannot recommend anyone following our example as your time is most likely better spent elsewhere, this post explains the approach we took. I will be covering topics like static pre-rendering and client-side rehydration, advanced bundling and caching strategies as well as service workers.

Highlights added by me because this is a fun read (and no doubt a fun experiment for them), but I also cannot recommend you follow their example. 😉

Marja Hölttä v8.dev

Understanding the ECMAScript spec (part 1)

When’s the last time you read the ECMAScript spec? Marja Hölttä on the V8 dev blog:

In this article, we take a simple function in the spec and try to understand the notation. … Even if you know JavaScript, reading its language specification, ECMAScript Language specification, or the ECMAScript spec for short, can be pretty daunting. At least that’s how I felt when I started reading it for the first time.

Also check out How to read the ECMAScript specification which covers most of the material from this post, but from a different angle.

JavaScript github.com

Clean Code concepts adapted for JavaScript

Software engineering principles, from Robert C. Martin’s book Clean Code, adapted for JavaScript. This is not a style guide. It’s a guide to producing readable, reusable, and refactorable software in JavaScript.

Not every principle herein has to be strictly followed, and even fewer will be universally agreed upon. These are guidelines and nothing more, but they are ones codified over many years of collective experience by the authors of Clean Code.

React github.com

A simplified Jira clone built with React and Node

This looks like an excellent read for anyone looking to level up their fullstack JS chops:

I do React consulting and this is a showcase product I’ve built in my spare time. It’s a very good example of modern, real-world React codebase.

There are many showcase/example React projects out there but most of them are way too simple. I like to think that this codebase contains enough complexity to offer valuable insights to React developers of all skill levels while still being relatively easy to understand.

A simplified Jira clone built with React and Node

JS Party JS Party #111

Lesser known things browsers can do in 2020

Did you know you can make a device vibrate via a webpage? Neither did we until we popped open Luigi De Rosa’s super cool repo that collects many of the lesser known things browsers can do in 2020.

On this episode we hang out on his list and discuss which APIs were surprises to us, which we think are the most useful, which we wish would die in a fire (sorta), and what you might get if you mash up a few of these APIs.

JavaScript github.com

A tiny (196B) JS utility to generate calendar views

I love how much is squeezed into this truly tiny library.

import calendarize from 'calendarize';

// Week = [Sun, Mon, Tue, Wed, Thu, Fri, Sat]
const view = calendarize(new Date('2019-12-20'));
//=> [
//=>   [ 1,  2,  3,  4,  5,  6,  7],
//=>   [ 8,  9, 10, 11, 12, 13, 14],
//=>   [15, 16, 17, 18, 19, 20, 21],
//=>   [22, 23, 24, 25, 26, 27, 28],
//=>   [29, 30, 31,  0,  0,  0,  0],
//=> ]

Check out the demo to see it in action.

Side note: the demo “reimplements” jQuery in one line:

const $ = document.querySelector.bind(document);

This reminds me of how I answered a question in our Slack recently about whether or not I’d use Umbrella JS again if starting a new project today.

if I were merely doing JS sprinkles I’d probably just write a few ‘ergonomics’ functions around querySelector and friends.

The web really has come a long way in a short time.

Svelte github.com

A Svelte compiler & watcher that works with Snowpack

The goal of svelvet is to make svelte play nicely with snowpack and web_modules.

As of today, svelte depends on a loader for webpack or rollup which compiles your svelte components into individual js files. Since snowpack’s goal is to avoid the need for a bundler, we can’t use those loaders, but we can use svelte’s internal compiler api to do 95% of the work for us. On top of that, svelvet adds automatic file watching to recompile your svelte files just like a loader would, but much faster!

I’m not gonna lie, any green field that offers a super light build process is looking pretty stinkin’ green these days. That being said, there’s a reason we call it the bleeding edge.

JavaScript github.com

A Next.js site demonstrating SSG support with a Notion-backed blog

I’m not sure which is more interesting: the fact that Next.js is getting in to the static-site generation game or the fact that Notion is becoming popular enough amongst devs that people would use it as a back-end for their blog.

The Notion aspect, while interesting, comes with a big disclaimer:

since it is using a private API and experimental features, use at your own risk as these things could change at any moment.

0:00 / 0:00