JavaScript Icon

JavaScript

Tracking all things JavaScript
1234 Stories
All Topics

JS Party JS Party #276

The ORMazing show

Nick & KBall sit down with the brilliant Stephen Haberman to discuss all things ORMs! 💻🔍

From the advantages and disadvantages of ORMs in general, to delving into the intricacies of his innovative project Joist, which brings a fresh, idiomatic, ActiveRecord-esque approach to TypeScript. 🚀

So sit back, relax, and let’s dive deep into the world of ORMs with the experts!

JS Party JS Party #270

Nick & KBall's "Coffee Talk"

Grab a comfy seat and a hot cup of joe, because it’s time for some coffee talk with Nick & KBall! Special guest Thomas Eckert joins the party and brings a bunch of questions for us to discuss.

Who wins in a fist fight: Tailwind CSS people or “real” CSS people? Is Agile overrated? What’s the longest bug you’ve ever chased? How about some underrated libraries/packages that people should know about? And more!

JavaScript deno.com

You don't need a build step

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?

JavaScript akshaykhot.com

You don't need Rails to start using Hotwire

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.

JavaScript deno.com

The future (and the past) of the web is server-side rendering

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…

Player art
  0:00 / 0:00