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?
According to the author, esbuild is fast because..
- it’s written in Go
- much of the work is done in parallel
- it takes very few passes and avoids data transformations
- it was coded with performance in mind
Supports too many languages to list here, but all of the usual suspects are there. Maybe you’re hoping for a web-based demo? No 🎲
Do not run the Web UI on a port open to public traffic! Doing so would allow remote code execution on your machine.
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.
Destiny scans a folder and moves/renames files to a “prettier” structure. Definitely don’t try this unless you have a git history or a backup.
Mike Turley for CSS-Tricks:
KBall and Nick dive deep with Chris Manson and Jen Weber from the Ember core team. They talk about Ember.js: What it is, why it’s different, what’s new in the Ember Octane release, and what’s exciting in the future of the project.
The State of JS 2019 survey left many in awe of the beautifully rendered line graph created by Amelia Wattenberger. So we’ve brought her on JS Party to discuss how she built it!
Mint has all the tools you need to write error free, easily readable and maintainable applications in record time.
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. 😉
When’s the last time you read the ECMAScript spec? Marja Hölttä on the V8 dev blog:
Also check out How to read the ECMAScript specification which covers most of the material from this post, but from a different angle.
It’s a new year which means companies are hiring and developers are interviewing. So we thought it would be fun to host a fun game of technical Jeopardy.
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.
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.
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.
Playwright is focused on enabling cross-browser web automation platform that is ever-green, capable, reliable and fast. Our primary goal with Playwright is to improve automated UI testing by eliminating flakiness, improving the speed of execution and offering insights into the browser operation.
From the Microsoft Edge team.
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);
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.
We’ve logged enough awesome lists by now that you know exactly what to expect from this repo. So instead of describing what’s inside, I will say that Emma and I will be talking Fullstack D3 with Amelia Wattenberger on January 30th. Join us for the live show or subscribe to JS Party to listen when the episode ships.
A severe security vulnerability impacted all popular npm package managers: npm, yarn and pnpm and even triggered a release for Node.js 12.4.0. What is behind this vulnerability and why is it so important for us to understand? I wrote about it in a post that also explains how npm handles executables.
The goal of
svelvetis to make
svelteplay nicely with
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,
svelvetadds 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.
This isn’t the most practical item in our feed this week, but it’s definitely neat and the how is it made section of the README (and related code) shows how you might accomplish something similar.
KBall, Divya, Mikeal, and Feross dig deep into refactoring. When to do it, best practices, things to watch out for, and the difference between a refactor and a rewrite. We then close out with some key pro tips.
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.