Modernization

[nickserv]

Taken from https://github.com/HubSpot/youmightnotneedjquery/pull/249#issuecomment-1229298952, but I didn't want it to get lost from other contributors.

• [x] Convert CoffeeScript to JavaScript
• [x] Convert Stylus to CSS with nesting working draft (would mostly just be adding brackets like JS)
• [x] Convert Jade to something more HTML based (like EJS or React/JSX)
• [x] Remove Gulp in favor of a modern bundler (like esbuild, Vite, or swc), native web code, or a static site generator (like Astro)
• [x] Figure out if we're still supporting Internet Explorer No
• [x] #222

[mscuthbert]

"Convert Jade to something more HTML based (like EJS or React/JSX)" -- can I be "-1" in using React on this (or we'll be making a "YouMightNotNeedReact" site). It seems like the only parts of the index page that can't easily be written in pure HTML are the loops over alternatives and the comparisons. I've never used Jade before, but I found it easy enough to read, and there doesn't seem to be anything we want to do that can't be done with the current system. I'm not sure the usage case for removing gulp either (I don't use it in my projects, but it seems sufficiently fast to me right now, and there's nothing I want done that can't be done with it for this project).

[Abbondanzo]

+1 on both of these points. I'm not convinced that switching to React is necessary given the vast majority of the content is static, and we're only managing one tiny bit of state with the slider. I also believe gulp is sufficient but I see no harm in bumping it to the latest version if need be. If there's truly another bundler out there that's faster or easier to set up (and can survive nine whole years without needing any configuration changes) only then would it be worthwhile to switch. This project is going to remain on GH pages indefinitely

[nickserv]

Why not React? It would have little overhead if we used pre/server rendering.

If there's truly another bundler out there that's faster or easier to set up

Yes, esbuild/Vite is much easier to set up, and about 10-100 times faster than JS alternatives. IMO the only major advantage to JS based build tools is legacy support, which doesn't matter if we're switching to more modern tools.

I'm currently leaning toward Astro because it has a fast Vite-based build system and built in prerendering. We would need to change the URL scheme if we wanted to support IE or remove client side JS, but that would have the advantage of supporting GitHub Pages with nicer URLs. Astro would also give us the option of using a framework like React on the client and at build time (so it gracefully degrades with JS is not available).

Alternatively, we could migrate to native modules and skip bundling or rendering entirely, though that has some performance disadvantages over bundlers and static site generators.

[jarikmarwede]

Why not React? It would have little overhead if we used pre/server rendering.

Server side rendering isn't possible on Github Pages. It just serves static files without any code being executed on the server side.

[jarikmarwede]

I would agree that React (or any JS framework for that matter) would be overkill for this project considering its small size if you exclude all the code examples. If you really want to get rid of Jade maybe we could now use Webcomponents (custom elements) instead since we dropped support for IE.

[nickserv]

Why not React? It would have little overhead if we used pre/server rendering.

Server side rendering isn't possible on Github Pages.

But pre rendering is.

Do you think a 100% static HTML example would be better? I don't think Webcomponents are a good idea due to their overhead and weaker support for pre rendering.

[jarikmarwede]

I don't think 100% static HTML would work, because we have to load the examples from their respective files somehow. Jade (or any static site generator) is pretty good for that. Maybe we could also just update from Jade to Pug (it was renamed).

[nickserv]

We can load them at build time. Example: #275

[jarikmarwede]

Well, that's what happens currently, right? Gulp reads the files during the build and pipes them to Jade.

[nickserv]

Yes, but #275 uses Astro instead.

[jarikmarwede]

Yes, I noticed that, but to be honest I am a bit confused with Astro. From its website I learned that it's are a framework that focuses on server side rendering. Wouldn't that be a bit overkill since we can't even support server side rendering? I thought we just need a static site generator?

[nickserv]

It's not server side rendering, it's build time pre rendering.

[jarikmarwede]

Ah, ok. Then their docs are just confusing. They don't mention pre-rendering at all on the "Getting Started" page.

[mscuthbert]

I'm with @jarikmarwede also -1 on switching to astro or another build system (especially something like esbuild that requires a binary to be built for wherever system the page is compiled on). The current system works, builds in less than one second, and if we want to switch the .jade file to pure HTML in any of the static parts, it looks like it can be done.

One of my main large projects (www.artusimusic.com) is 95% built in web components, shadow DOM, brand new builders, etc. so I'm not a luddite. But I also have a weekly cron script on my computer from 22 years ago that still runs on Perl, because, well, it's never broken, and still does what it's supposed to, so why touch it?

[nickserv]

Node itself already has native bindings, and so do many popular npm packages, so I don't see native as a disadvantage.

Astro also provides a much better developer experience (live reloading, easy config, fast builds, TypeScript integration, editor editor). I don't think it's even possible to get hot reloading with Gulp, but it works by default with Astro. Astro also it abstracts away most of the build and config, so we wouldn't have to worry about maintaining it. I couldn't even figure out how to upgrade Gulp because it had so many breaking changes. In the time it took me to attempt to update the build scripts, @Richienb had already configured Astro successfully. And that's biased in favor of Gulp, because I have had prior experience with Gulp.

[My6UoT9]

"youmightnotneedastro"

Astro

What is Astro? Astro is an all-in-one web framework for building fast, content-focused websites.

Gulp

A toolkit to automate & enhance your workflow Leverage gulp and the flexibility of JavaScript to automate slow, repetitive workflows and compose them into efficient build pipelines.

edit: Astro actually looks good. As long as Astro is not required to replicate a solution found here in your project.. maybe it is okay.

[Abbondanzo]

:shipit: like @My6UoT9 here, I've had the chance to spin up a small Vite/Astro project and I gotta say I'm impressed. Performance is there, TYPESCRIPT IS THERE, and a whole suite of other quality-of-life improvements.

If there's truly another bundler out there that's faster or easier to set up (and can survive nine whole years without needing any configuration changes) only then would it be worthwhile to switch.

To answer my own hesitations, yes this one is better. And it supports local development out of the box which is something I was planning on setting up last night anyhow. To put anyone else at ease with these changes, Astro's JSX and template-based component imports look and feel identical to Jade templates, so this change can easily be reversed.

The work in #275 is a great start