• Monday, 16 Oct 2023 7:10 pm

  No build step

  Jim Nielsen on the cost of avoiding annoyance, which is itself a commentary on why HTMX (the framework for JS-in-HTML) doesn't have a build step.

  A resounding yes! here: if you're using boring technology for your backend and progressively enhancing your frontend, modern browsers have made it extremely easy to skip out on the build step, both for CSS and JavaScript. This website has no build step, and it's got light/dark mode, color/bw mode, a dynamic component for pulling my recent tracks from Last.fm, and a search k-bar.

  Heck, my brother's website doesn't even import stylesheets, it just uses Twig templates to dump a template called style.css into a <style> tag.

  Next time you're spinning up a (let's be serious) side project, reconsider whether you even need a build step.

  Code JavaScript

• ---

  Sunday, 21 May 2023 4:50 pm

  View Transitions & frameworks

  I'm as stoked as the next developer-whose-job-is-only-tangentially-frontend-related about the new View Transitions API, but does it feel like the major response is relief that this is the feature that will obviate the use of JavaScript-heavy frontend frameworks?

  The excitement for a web that feels like a native application is well-placed, but surely page transition animations aren't the only reason we're loading dumptrucks of JavaScript on dev blogs across the webosphere?

  JavaScript Web Browser

• ---

  Sunday, 23 Apr 2023 5:48 pm

  Progress

  About midway through last month, probably around the time when the cast on my broken hand started to get a bit ripe, I decided to channel some of my continuous acute anxiety at not having the full use of one hand into making a little micro-webapp to allow users (i.e. me) to view the elapsed time between two dates as a progress bar. The visualisation, I reasoned, would help me get a bigger-picture perspective on what was, with bigger-picture hindsight, a pretty minute fraction of my whole life. It’s not clear whether it actually worked or whether it just focused my anxiety into a single sharp point, but the exercise was a fun distraction for a day.

  You can find the web app here, if you’re interested in visualising the progress between two points in time. This is what it looks like to measure my progress through life, assuming I die exactly at noon on my eightieth birthday:

  

  Any progress bars you create stay on your computer; there’s no syncing between devices or servers scraping your data and sorting you into a marketing cohort.

  In fact, the whole website is made up of three files: one HTML, one CSS, and one JS. The Platonic Form of a website circa 2004. There’s no build step, no dynamic rendering. The app doesn’t work without JavaScript, but that’s okay, since there’s nominally only a single user (me). The application isn’t doing anything particularly technical—mostly just reading and writing to localStorage—and browsers are all basically on the same page nowadays so there’s no need to faff with vendor prefixes or checks for APIs on window or polyfills or anything like that.

  I like the experience of writing applications like this. Modern browsers support it really well; you barely even need Postcss or Sass anymore. I think that in general we could probably err more on this side of the JavaScript Complexity Spectrum than we do today. Am I going to jump down your throat if you build your blog with Next.js? Only if you brag about it.

  Web JavaScript

• ---

  Thursday, 27 Oct 2022 11:51 am

  Next.js 13

  Next.js 13 was announced at Next.js Conf a couple days ago, and it’s Very Cool. There are a few flagship new features, like app layouts and OG Image generation, along with a new build system called Turbopack, along with a boatload of micro-optimisations to make your React application absolutely fly. The byline on the blog post is a real who’s-who of JavaScript framework royalty, and I’m glad that we’ve got some of the cleverest folks on the internet working on pushing the envelope.

  This wouldn’t be a hand-wringing Internet Tech Thought-Piece without a big but, though, so: BUT:

  I can’t help but wonder if all of this work to shave seconds and milliseconds off build times, to batch state updates and push logic and data from the server to the client and back to the server again isn’t maybe forgiving egregious abuse of JavaScript in the browser just a little bit.

  I get that the React team (and the Next.js team, if there’s still a meaningful difference) are architecting a Pit of Success—but there’s a fine line between making the right thing easy and making the wrong thing feel right. Speaking from experience, writing crummy application code and relying on Next.js to optimise my mistakes away was the simplest approach to building my old website. Next.js makes it so easy!

  Like here’s an example: React now overwrites the global fetch() browser API. Here’s the code that does it. They do this so that Next.js can do a bunch of caching magic behind the scenes—magic like automatically deduplicating requests for the same data. Setting aside for a moment the ickiness of overwriting global objects, this encourages developers to ignore the obvious code smell of multiple identical requests being triggered from different components. Deduplicating requests should be the responsibility of the application design, not a black box feature of the framework.

  (Which is to say nothing of Next.js 13’s new baseline. There’s a certain amount of framework code shipped on every request just to make things work, and it’s gone up from Next.js 12 to 13. But 12 was no slouch, either: why does Raycast’s homepage (which is ostensibly just images and text) ship 200KB of JavaScript to my browser? What’s it doing?)

  Web JavaScript

• ---

  Wednesday, 14 Sept 2022 5:12 pm

  Global variables

  In JavaScript—especially in modern JavaScript—variables are always declared with let or const (or, historically, var):

  function me() {
   let name = "Charles"; // scoped to me
  }
  

  I’m not going to get into the details here, since there are thousands of other blog posts diving into the differences out there. Instead. I want to talk about declaring variables without these keywords:

  function me() {
  	name = "Charles";
  }
  

  Up until the widespread adoption of ES Modules (and so long as you weren’t using strict mode) this was valid code. It declared name as a global variable—on window, if you’re in the browser.

  Developers are usually warned against doing this, because the global scope in the browser is already pretty full of stuff and you can never be sure whether you’re going to step on something that already exists.

  But I’m not just talking about browser APIs—did you know that every id attribute maps to a value on window (that is, the global namespace) in the browser?

  <nav id="navbar">The nav goes here</nav>
  
  <script type="text/javascript">
  	console.log(navbar) // => <nav id="navbar">
  </script>
  

  Thankfully we don’t tend to have to think about these things much nowadays—we’re well into the Age of ES Modules and if you’re not using "type": "module" from the start then you’ve likely got some bundler or another that abstracts all of this out of your regular thinking. But there’s always value in understanding the platform.

  Code JavaScript

Archive

Posts Stream Books Walks • Clear filters