Andy Jiang and Deno’s content team are really speaking my language lately:

Sites take time to build these days. A large Next.js 11 site will take several minutes to build. This is wasted time in the development cycle. Build tools like Vite or Turbopack highlight their ability to get this number down.

But the deeper question hasn’t been considered:

Why do we even need a build step?

Akshay Khot:

Although Hotwire (an approach to building web apps without much JS by sending HTML instead of JSON over the wire.) is closely tied to Ruby on Rails, you might be surprised to know that you don’t really need Rails to learn, play, and experiment with Hotwire. In this article, I will show you how a simple static website can use Turbo Drive and Frames to make it more dynamic and responsive.

We’ve been using the predecessor to Hotwire’s Turbo Drive on this very website (an Elixir app) for 7 (!) years now, so I’m convinced there are valid uses of Hotwire outside of its usual Rails context.

What’s old is new cool again. Here’s Andy Jiang, writing on Deno’s blog:

In the past 10 years, the median size for a desktop webpage has gone from 468 KB to 2284 KB, a 388.3% increase. For mobile, this jump is even more staggering — 145 KB to 2010 KB — a whopping 1288.1% increase.

That’s a lot of weight to ship over a network, especially for mobile. As a result, users experience terrible UX, slow loading times, and a lack of interactivity until everything is rendered. But all that code is necessary to make our sites work the way we want.

This is the problem with being a frontend dev today. What started out fun for frontend developers, building shit-hot sites with all the bells and whistles, has kinda turned into not fun. We’re now fighting different browsers to support, slow networks to ship code over, and intermittent, mobile connections. Supporting all these permutations is a giant headache.

How do we square this circle? By heading back to the server (Swiss basement not required).

He goes on to talk about isomorphic JavaScript frameworks and Deno’s offerings in this space. But hey, you don’t need all that fancy stuff to do SSR. All you need is a programming language that can render HTML (this is almost all languages) and a server…

In this post, I will show you some advanced usage patterns for working with Playwright in order to take a screenshot of a specific element and modify the contents of the image, either before taking the screenshot or after, using image preprocessing tools.

Sometimes all a project needs is the ability to read/write small amounts of JSON data and have it saved in some persistent storage. Imagine a simple data-model which receives infrequent updates and could be represented as JSON object. It doesn’t demand a full-blown database, but it would be neat to have a way to interact with this data and have it persist across sessions.

This is where gist-database comes in handy, by leveraging the power of the gist api you can easily create a key/value data-store for your project.

This is a perfect solution for low write / high read scenarios when serving static site content with Next.js and using Incremental Static Regeneration to keep your cached content fresh.

This looks like an interesting framework for everything error-related. The core handles the usual tasks (wrapping errors, creating classes, etc.) and plugins offer more advanced use cases (serialization, CLI errors, logging, etc.).

If you’ve ever had to split a string into sentences, you may have reached for a naive regular expression:

'Hello! How are you?'.split(/[.!?]/);

Instead of giving yourself two problems, Stefan Judis says maybe reach for Intl.Segmenter, which he shows is quite sophisticated and supported everywhere but Firefox.

If you don’t have time to fill out the entire survey… at least skip down to the “Resources” ~> “Podcasts” section and help someone dethrone those rascals over at Syntax. I think it might be JS Party’s time, y’all…

For web automation/testing, Selenium has been the de facto “standard” since forever. It’s simple to get started with and supports almost every programming language.
My problem with it has been: It’s good enough, but nothing more. It doesn’t work that well with modern, Javascript framework heavy sites (Angular, React etc). I’m not saying it doesn’t work– just not too well.

I know a lot of people who use Selenium, but I don’t know a lot of people who enjoy using Selenium. (That’s no knock on the Selenium team. They solved a hard problem for lots of devs over the course of many years. Huge impact!) Playwright on the other hand…

Vercel dropped Next.js 13 last week and there’s a lot of new stuff (router, server components, streaming & more) in this release. If you learn best by example (and subsequent tinkering with existing things), this (WIP) repo might be a good starting place for you.

If you’re feeling the FOMO of JavaScript or you’re writing “spaghetti code” just to do something a NextJS component would do out of the box, then read this post from Bill Prin on why he moved from Django to NextJS.

The summary is that using a language like Python or Ruby for a significant web project has increasingly gotten less reasonable over time to the point where now, in 2022, it’s getting hard to justify. By not keeping your web stack in pure Javascript, you are making your life unnecessarily difficult (as usual, we’ll include languages like TypeScript as part of the JavaScript ecosystem). You will almost certainly invest a bunch of time-solving problems that would be automatically solved for you if you just stuck with JavaScript.

I will provide specific examples of solving problems using Django that would have been trivially solved in NextJS.

He goes on to share two reasons why you should use Python or Ruby for web projects in 2022.

You’re working on an existing project that hasn’t been migrated yet or is not worth migrating.
You are already a master of a Python or Ruby web stack, and you need to implement a new project as soon as possible, and you don’t have time to learn a better stack.

Suppose you learn some functional JavaScript, and it’s wonderful. But, for some reason, your team doesn’t get it? What do you do? To understand what’s going on, we need to step back and get a little perspective…

Webpack creator Tobias Koppers announcing its (Vercel-funded) successor:

Turbopack is built on a new incremental architecture for the fastest possible development experience. On large applications, it shows updates 10x faster than Vite and 700x faster than Webpack. On even larger applications, the difference is greater—often 20x faster than Vite.

Turbopack is open source and still in alpha. Here’s what the future may hold:

To start, Turbopack will be used for the Next.js 13 development server. It will power lightning-fast HMR, and it will support React Server Components natively, as well as TypeScript, JSX, CSS, and more.

Turbopack will eventually also power Next.js production builds, both locally and in the cloud. We’ll be able to share Turbo’s cache across your entire team, using Vercel Remote Caching.

Webpack users can also expect an incremental migration path into the Rust-based future with Turbopack.

This looks like top notch work:

Get more than 20 components with beautiful defaults and simple props. From charts to input and layout elements, we covered all the essential components to lift the tedious front-end work from your shoulders. Get ahead with our simple API approach in no time.

Check out their demo dashboard right here.

1. run npm install -g easy-sharing
2. run sharing /directory-or-file-to-share
3. scan the QR code with your phone

Tobias Bieniek:

Have you ever worked with JavaScript? Have you been annoyed by the three hundred copies of left-pad in all of the node_modules folders on your disk? Would you prefer if all of your projects shared their node_modules folders instead of each getting their own copy?

The single character that saved him all that space? The p in pnpm…

It’s Hacktoberfest again, but you don’t know where to find interesting projects? This CLI will help you find participating projects based on your starred repositories. Simply run:

npx hacktoberfest-hunt

I love that people are bringing HTML back to the forefront:

Our mission is to enable anyone to build multi-page dynamic web apps while staying as close to the platform as possible. Enhance fills in the gaps to make building for the backend, and the browser a seamless experience for web authors and consumers.

Modern JavaScript frameworks bring more problems than they solve; recreating native web platform features adding unnecessary weight and complexity, which is challenging to unravel.

Enhance provides a dependable foundation built on standards-based web platform features, allowing developers to create web applications that are lightweight, flexible, and future-proof.

This project is a web implementation of the raining green code seen in the Matrix franchise. It’s built right on top of the upcoming graphics API WebGPU, but falls back to the functional WebGL wrapper, REGL; its previous Three.js version is maintained in a separate branch.

I used to spend countless hours in college scouring the web for the best digital rain screen saver for my laptop. Sounds like the author is with me on that:

The number of implementations out there of this effect is a testament to the size of the film’s impact on popular culture. For decades, I’ve enjoyed searching for and comparing them from time to time. That’s probably how you arrived here— it’s fun to see what kinds of solutions different people come up with to a problem, when the process is purely recreational and its success is subjective.

This one’s really nice and even has a 3D mode. The README says it’s “made with love”, but from what I can tell it’s almost entirely JavaScript. 😜

Tan Li Hau gave this talk at Front Conference, but the videos won’t be out for a year (!), so he gave the talk again and posted it to his YouTube channel. Here’s how he described the video to us:

Watch the <1 hour video to write a simplified Svelte compiler <300 lines of code is amazing! Easy to follow, inspiring, and gives a great overview of how to write a compiler.

Jaun Diego covers some little known yet extremely useful APIs, such as the Page Visibility, Web Sharing, Broadcast ChanneI and Internationalization.

This is a nice round-up of some new(ish) HTML and JavaScript features related to forms. Now that Safari 16 is out, good stuff like requestSubmit and showPicker are looking pretty green!

11ty creator Zach Leatherman recently released a standalone HTML serializer for generating markup for Web Components. Here’s what Zach had to say about it on Twitter:

This is an early preview and I welcome feedback! I think it’s a great way to build standards-based HTML-first components without JavaScript framework overhead 🙌🏻

Josh Collinsworth (an unapologetic React non-fan) writes on his blog about the ubiquity of React:

I don’t know what the future of front-end looks like. Nobody really does. But it’s a very safe bet that React will continue to be the thing for a very long time.

If you’re learning front-end development in the hopes of getting a job, or trying to level up your career, and React is a knowledge gap for you, it seems like the safest bet you could make. React isn’t going anywhere anytime soon. That said, however…

But why does React remain on top?

Because we don’t always value the strongest choice as much as we value consensus. (In fact, you could make an argument that consensus is the strongest choice, in many ways.)

React keeps getting picked…because React keeps getting picked.

But there’s a ton more to unpack. Josh got into the details on the best choice for the job, covering: Performance, learning curve, bundle size, scalability, community and support, financial backing, hireability, and developer experience.

Should I spoil it for you? Nah. Read Josh’s words for the full story.

Here’s Natasha Lekh from Apify describing the project:

This project really is a culmination of 4 years of work trying to make the best library for web scraping in production. Web scraping is a very dynamic environment and what works today might not work tomorrow, so we at Apify had to go through a lot of trial and error to figure out the most reliable and convenient ways of crawling the web and scraping data. We hope that we finally cracked it and that now many developers will enjoy working with our new library and it will make their scrapers more reliable and time to production faster.

I like how it starts with simple HTTP-based scraping, but can switch to browser-based automation when a site has JavaScript rendering. I don’t love the built-in proxy rotation features. Not because they’re bad, per se, but because they make spammers lives easier…