January 5, 2024

Links by Friday 003 - VanillaJS Doesn't Scale

Intro

This week we have a development heavy issue featuring Ruby, Rails, JavaScript and a bit of design from a database company.

I love Ruby

Elise Shaffer articulates some of the reasons why she loves Ruby.

I have not really used Ruby that much but I'm torn between it and Go as a language to learn deeply.

I Love Ruby | Elise Shaffer

I've done a lot in my career. From working on business support software to big backend systems and even robotics. If there's been a consistent through-line to my career, it's the Ruby programming language.

Rails: When changing code doesn't change behavior

We’ve all been there. We’re updating the code, but nothing changes (either in the UI or in the back-end). Here’s a list of things to check to figure out what’s wrong.

• Check Your Environment

• Check your Feature Flags

• Watch Your Files

• Clear Generated Assets

And much more in the post below.

Rails: When Changing Code Doesn't Change Behavior

Are you updating code and not seeing changes? Try this to figure out what’s wrong.

Vanilla JavaScript Doesn't Scale

Chris Ferdinand is the Vanilla JavaScript guy but I also get the sense that he is also pragmatic. In this article, he debunks the 'Vanilla JavaScript does not scale' argument. If you want to hear more about his views on JavaScript, he talks about the Rise and Fall of JS Frameworks in this JSParty podcast.

Vanilla JS doesn't scale | Go Make Things

Yesterday, one of my students shared some Twitter nonsense where people were predictably complaining that vanilla JS doesn’t scale, that using it means you’re just reinventing the wheel, and so on. Today, I wanted to unpack why that’s all utter bullshit. Let’s dig in! ❄️ Quick note! Want to level-up your vanilla JS skills? Now through the New Year, save 40% on Lean Web Club membership, private coaching, and all of my courses and workshops.

Thoughts on Remix

What we like about Remix

• The docs are easy to navigate and extensive, spanning high-level discussions on the various approaches and tradeoffs for building modern web applications, API documentation, and topic/objective-based guides.

• Learning Remix is mostly about understanding routing (same API as react-router v6), and data loading, along with learning the framework conventions (“the right thing is the easy thing," ideally, though not always in practice).

• The framework design puts a focus on standard/fundamental web APIs and interfaces (e.g., Response, FormData) – the knowledge of which is transferrable outside of Remix applications.

• Remix is easy to deploy on a variety of different infrastructures and provides pre-packaged “stacks” that ease new project setup.

• Remix has a thoughtful approach to rolling out new features, offering early and incremental adoption through “future flags”.

• It just generally feels productive to build with. Loaders and actions feel like solid Lego pieces to snap together - compared to a framework-less React app, having some stronger conventions about where code lives helps with maintainability and navigating the codebase.

  • Our work happened while Remix rolled out support for flat routes, and we opted to keep most of our code outside of the app/routes folder, following a more DDD-oriented approach.

  • The docs outline a few different approaches to organizing route modules either as flat files or nested folders.

• It’s much easier to build applications that work progressively and degrade gracefully, as compared to something like Next.js.

• For many use cases and features, you don’t need to pull in third-party dependencies for state management, data fetching, or networking (loaders replace react-query and Remix handles making the requests). If you do need some client-side states, it might make sense to pull in something lightweight like zustand or jotai, rather than something heavier and more robust like redux.

• Remix gives developers flexible levers for making different tradeoffs in different places with regards to eager vs. lazy loading of data, allowing us to opt in to showing loading states granularly if a particular use case favors valuing the UX of fast navigations over avoiding loading states.

• The Shopify acquisition last year gives us a reason to believe that Remix will continue to mature and grow.

Thoughts on Remix | Viget

Reflections on Remix by seasoned React developers. TL;DR: it good.

React Server Components: the good, the bad and the ugly

I’d argue that adding server capabilities to React is much less important than fixing its many existing issues. There are lots of ways to write server-side logic without React Server Components, but it is impossible to avoid the atrocious mess that React creates on the client without replacing React altogether

React Server Components: the Good, the Bad, and the Ugly

Evaluating Next.js's implementation of React's new server features.

Design at Supabase

Our approach to design

To design at Supabase, you have to think like an agile developer.

What minimal increment will have the biggest impact, with the lowest engineering effort? We make small daily gains while simultaneously solving large milestones. We aim to ship daily and dream in years.

https://supabase.com/blog/how-design-works-at-supabase

That's it, see you next time.