9 ms·

I'm not against frameworks, but in many cases, they're unnecessary. I've always questioned why we should add 100KB of JavaScript to a page before writing a sing

I'm not against frameworks, but in many cases, they're unnecessary. I've always questioned why we should add 100KB of JavaScript to a page before writing a single line of real code. My team and I built https://restofworld.org https://restofworld.org without any frameworks. The feedback, from surveys, outreach, and unsolicited emails, has been overwhelmingly positive, especially around usability and reading experience. We might adopt a framework eventually (I do appreciate how their opinionated structure can cut down on endless debates), but for now, plain JavaScript serves us really well.

throwaway984393 1y ago
[dead]
pmdr 1y ago
Congtats! Usability should be a first class citizen. Instead we seemed to have perfected the art of loading screens, "hydrating" components, time & power consuming animations and annoying modals.
eduction 1y ago
Kudos, the site feels really snappy and I’ve definitely come across the journalism before. Any sharp edges to this approach?
- nzgrover 1y ago
  In my experience, the sharp edges are browser compatibility issues, and I've been gratefully avoiding them for years by using jQuery.
CharlesW 1y ago
Ahhh, the beauty of WordPress-generated static pages.
lelandfe 1y ago
One of the nice things about this is that back and forwards in history is snappy as hell. I’m so used to going back on my iPhone and the entire page reloading.
- rjh29 1y ago
  SPAs are supposed to be more efficient by only loading the data needed to update, but somehow back/forward are 100x more responsive on static pages or static sprinkled with JS, and they don't break the back button either. SPAs always have a kind of sluggish feel to them.
  - zdragnar 1y ago
    That's because backend-rendered sites need a shit load of caching. SPAs tend to just use APIs that aren't cached.
    - moritzwarhier 1y ago
      That's primarily because many SPAs aggressively prevent caching of all xhr responses using headers (which are ofc defined from the BE side) And the reason for that is mainly to prevent edge cases and make sure people in CRUD apps see up-to-date content. The experience with a no-cache max-age=0 server-rendered site would be very similar. All of the headaches around custom routing code + restoration of state are pretty much obsolete wirh bfcache, introduced more than 5 years ago. If you build a dynamic page and use HTTP headers to prevent caching, stop complaining about it. Most people making this argument want to offload dealing with external APIs to the frontend, and then complain about the result when no requirements around API response caching were defined, let alone time was given to define them.
      - zdragnar 1y ago
        No, this proves my point. Back in my days of backend programming, Varnish was the "magic" that made servers (especially CMSs) feel fast. Memcached is another common go-to cache. Browser caching isn't a replacement as the first request for every endpoint is still going to be slow. Yet somehow, APIs aren't treated with the same requirements for performance as web pages.
        deleted 1y ago
        [deleted]
atoav 1y ago
As a fellow vanilla-fan: If this shows anything, it shows how bloated modern web development has become. Your page is snappy as hell.
- insin 1y ago
  Modern static content web development is in some of the best health it's ever been in with the likes of Astro. You get your lovely developer experience with components, with the same component API enabling layouts for the repeatable outer structure, easy composition of reusable parts of your content, ease of passing data around between these and implementing any logic you need before rendering or inside what you're rendering. The user gets a snappy, static website.
pinoy420 1y ago
[dead]
metabagel 1y ago
Blazing fast. Wow!
- hoherd 1y ago
  I thought this was sarcasm, so I loaded the page, and yeah, that is an insanely fast cold load time, and even more impressive once the resources are cached.
electroly 1y ago
While I think your page is excellent and loads great, I don't think this is related to the approach described by TFA. You're using the biggest framework around: WordPress. You're just static rendering it. TFA is talking about no build tools at all, using modern web standards, and specifically nothing requiring preprocessing. "... just an editor, a browser, and web standards" is a quote from the page.
andrewstuart 1y ago
No user cares about 100K.
- austin-cheney 1y ago
  They care about time and they absolutely do care. If your giant virtual DOM mess takes 10x longer to respond on every user interaction they will absolutely notice. It’s just the developers that don’t care because deviating from the framework puts their job at risk.
  - someothherguyy 1y ago
    > 10x longer to respond 10x longer than what? > It’s just the developers that don’t care because deviating from the framework You realize that many major modern (and legacy) web frameworks started inside companies?
    - austin-cheney 1y ago
      10x longer than not using that framework and yes, I do realize that.
lolinder 1y ago
I think that this comment is a great example of the total disconnect these conversations always have. On the one hand we have lots of people on here who are building full-featured web apps, not websites, on teams of 30+. These people look at frameworkless options and immediately have a dozen different questions about how your frameworkless design handles a dozen different features that their use case absolutely requires, and the answer is that it doesn't handle those features because it doesn't require them because it's a blog. Meanwhile there are also a lot of people on here who have never worked on a large-scale web app and wonder why frameworks even exist when it's so obviously easy to build a blog without them. It would be nice if we could just agree that the web hosts an enormous spectrum of different kinds of software and make it clear what kind of software we're talking about when we were opining about frameworks—whether for or against. In this case: this is a WordPress blog.
- dorfsmay 1y ago
  On the third hand, some people use React and some framework to write static web page...
  - lolinder 1y ago
    And if you can point me to an example of that I will happily lampoon them. If we're talking about Medium, then yes, Medium is a complete disaster zone that should not be emulated anywhere. Their reader-facing use case does not require JavaScript at all except as a light optional seasoning on top. All I'm saying is that we need to actually talk about use cases whenever we're talking about frameworks, which we almost never do. Failing to specify the use cases turns the conversation incoherent because we end up having two different conversations without even realizing it.
    - austin-cheney 1y ago
      The primary use case for these large frameworks is hiring.
  - emseetech 1y ago
jemmyw 1y ago
Nice site, I found some interesting stories. I do find it a little annoying that when we have these discussions about vanilla vs frameworks people hold up an example and I go there and see a news site of articles rather than a complex application, and I think to myself yeah I wouldn't have used a framework in this situation anyway. It's annoying from 2 directions: the first that people ARE using frameworks for sites that shouldn't have ever had them in the first place, and I can bring to mind a couple of news sites I visit regularly where this is obviously the case because of the silly ways they work. Secondly that this is then held up as an example, because most of my work is on very interactive sites so I end up thinking well yeah but that's not going to work for me is it. My feeling is that I could do vanilla but would end up with something like a site specific framework. My current approach is to use a framework and consistent patterns but to try and use as few other dependencies as possible.
eviks 1y ago
Not sure if it's no-framework related, but navigation back/forth is sometimes broken: the url changes immediately, but the page doesn't update and stays on the same article. Also infinite scroll breaks the most basic usability issue - you can't track where in the article you're with the scrollbar positioning
ntnsndr 1y ago
I love Rest of World! Great work!
pier25 1y ago
> I've always questioned why we should add 100KB of JavaScript to a page before writing a single line of real code With most frameworks you don't need 100kB of JS code. Heck, with Mithril you get the components, vdom, router, and http client in like 10kB gzip.
- chillpenguin 1y ago
  shoutout to Mithril! Has always been an under-appreciated gem.
  - pier25 1y ago
    maybe you'll be interested to know v3 is in active development https://github.com/MithrilJS/mithril.js/pull/2982 https://github.com/MithrilJS/mithril.js/pull/2982
andoando 1y ago
My problem with all this vanilla showcases is they are dead ass simple pages with the most basic layouts and user interaction. Shit just show me how long it takes you to create a nice reactive table with search or a form with proper labels, user interaction, validation, errors, etc Why would I implement that all from scratch when I can install svelte install a UI library and add a couple lines of code, all with a 25kb overhead and get a better, nicer looking, more well tested product that would take you to do in a week?
- claytongulick 1y ago
  Increasingly, this is actually an argument in favor of vanilla web components. The WC ecosystem has grown a lot, and one of the great things about native web components is that they can be consumed by most major frameworks at this point. There are also many mature component sets you can pick from, like shoelace, etc... you can mix and match components from different offerings, something that's not practical with React/Angular (for example). I can use a select from Ionic, a breadcrumb from Shoelace, and a date picker from Lightning and it'll all just work. Doing vanilla Javascript development doesn't mean "don't use any libraries" (well, it might to purists, but whatever) it means stick to using standards based technologies with libraries and accelerators. For example, I use many of the techniques described by the site, but I prefer to use lit-html library (NOT lit framework) for rendering. Sometimes I use the vaadin router for routing, sometimes the Ionic router, sometimes my home grown one. I use a little library I wrote called ApplicationState for cross component shared state, because I don't like state being coupled to my DOM structure. Sure, this requires a deeper understanding than "batteries included" frameworks, but the advantages outweigh the negatives IMHO.
  - andoando 1y ago
    If you use a bunch of libraries for routing, UI, authentication, the only thing thats left is the rendering. And quite frankly I don't see why Id want to reinvent the wheel there. {#each notes as note} {note.content} {/each is exactly what Id want to implement for example if I were writing JS functionality to render a collection. And Svelte for example doesnt restrict you from using vanilla JS whenever you want either
littlecranky67 1y ago
> I've always questioned why we should add 100KB of JavaScript to a page before writing a single line of real code 100kb would never be a considerations for any of the apps I worked on (as a contractor in the corporate world). I mostly work in large teams, sometimes we had mulit-team monorepos with various line-of-buisness apps using React. 100kb are so completely irrelevant, as for LoB or B2B, no-one cares about the initial page load. Your users use the app on a daily basis, so they get all the JS/CSS/static assets served from their browser cache almost all of the time, until we make a new prod deployment (usually weeks). Plus, all users are always on Ethernet or WiFi at least, not some 3G cellular network somewhere in the desert. If you use some smarter framework like Next.js, you even get smartly chunked js parts on a per-route basis, that are immutable - they contain a sha256 hash of their content in the filename, and we configure the webserver to serve them via `Cache-Control: immutable`. There won't even be a roundtrip to check for newer versions. Plus Nextjs comes with tons of other stuff, like pre-loading chunks in the background, or when hovering over a link (i.e. using the time between the hover and the click to already load a chunk). Let alone that the initial render is static html and hydration happens completely unnoticed from the user.
- lolinder 1y ago
  This is spot on. Load times do not matter for the kinds of apps that: * Are exclusively loaded on high speed internet in corporate networks. * Have a high hours-of-work-per-page-load count. * Update infrequently. We're engineers, or at least we like to call ourselves that. Engineering is the process of gathering requirements and building a system that meets those requirements on time and under budget. If your requirements include being able to serve users on 3G networks or users who only load your site in order to read a single piece of content per day, yeah, optimize your load times. But don't attack other engineers for failing to live up to your app's requirements.
- zelphirkalt 1y ago
  That's assuming quite a few things though about the user's browser. Like cache not being cleared on shutdown. And on the project side, that there are not so many changes, that need to be received by the user agent now, instead of whenever the cache expires. That updates can be applied later on the user side. Of course when updates only happen every few weeks, then it might work... but only if that cache is not deleted, which is a big if.
worldhistory 1y ago
what? that is impossible
jimbob45 1y ago
I've always questioned why we should add 100KB of JavaScript to a page before writing a single line of real code. Developer productivity, theoretically. Although some of these frameworks don’t help with that for me personally.
robertoandred 1y ago
Your primary image is over 200kb. 100kb is nothing. And you're using WordPress, so yeah you are using a framework. Turns out you do think they're necessary. And as you can see, framework != slow, whether it's WordPress or anything else.
- donohoe 1y ago
  I believe the topic is front-end frameworks. WP is used as a CMS but the entire front end is built from scratch.
bigtones 1y ago
Rest of World looks like a fantastic news website I was not familiar with. I just spent a half hour reading a whole bunch of interesting articles there. Well done for helping build it - its super fast from Australia.
ummonk 1y ago
What do you even need JS for on that site? It looks like it should be doable with plain HTML.
vivzkestrel 1y ago
So you are the guys behind this amazing news website. What made you build this and is the target audience American? If you don't mind me asking, how are you guys monetizing this? Is this a funded venture or bootstrapped?
EZ-E 1y ago
Fantastic website, really happy to be able to finally read interesting stories and news about the tech scene where I work, in Vietnam
- duc_minh 1y ago
  Took me off guard too :D I didn't expect to click on a random link on HN and see an article about my home country
rikroots 1y ago
I recently did a ShowHN post for my browser-based screen recording web page side project. 100% vanilla, with added wasm-based ML shenanigans. It really is amazing what functionality can be built into a web page without resorting to framework support! https://news.ycombinator.com/item?id=43960434 https://news.ycombinator.com/item?id=43960434
heyheyhouhou 1y ago
Just wanted to say that I really like restofworld.org. Thanks to you and your team for building it.
redbell 1y ago
> My team and I built https://restofworld.org https://restofworld.org without any frameworks. Puter (https://news.ycombinator.com/item?id=39597030 https://news.ycombinator.com/item?id=39597030) was also built purely using vanillaJS (or, JQuery to be more precise)
replwoacause 1y ago
The site is beautiful... and fast too.

throwaway984393 1y ago

[dead]

pmdr 1y ago

Congtats! Usability should be a first class citizen. Instead we seemed to have perfected the art of loading screens, "hydrating" components, time & power consuming animations and annoying modals.

eduction 1y ago

Kudos, the site feels really snappy and I’ve definitely come across the journalism before. Any sharp edges to this approach?

nzgrover 1y ago
In my experience, the sharp edges are browser compatibility issues, and I've been gratefully avoiding them for years by using jQuery.

CharlesW 1y ago

Ahhh, the beauty of WordPress-generated static pages.

lelandfe 1y ago

One of the nice things about this is that back and forwards in history is snappy as hell. I’m so used to going back on my iPhone and the entire page reloading.

rjh29 1y ago
SPAs are supposed to be more efficient by only loading the data needed to update, but somehow back/forward are 100x more responsive on static pages or static sprinkled with JS, and they don't break the back button either. SPAs always have a kind of sluggish feel to them.
- zdragnar 1y ago
  That's because backend-rendered sites need a shit load of caching. SPAs tend to just use APIs that aren't cached.
  - moritzwarhier 1y ago
    That's primarily because many SPAs aggressively prevent caching of all xhr responses using headers (which are ofc defined from the BE side) And the reason for that is mainly to prevent edge cases and make sure people in CRUD apps see up-to-date content. The experience with a no-cache max-age=0 server-rendered site would be very similar. All of the headaches around custom routing code + restoration of state are pretty much obsolete wirh bfcache, introduced more than 5 years ago. If you build a dynamic page and use HTTP headers to prevent caching, stop complaining about it. Most people making this argument want to offload dealing with external APIs to the frontend, and then complain about the result when no requirements around API response caching were defined, let alone time was given to define them.
    - zdragnar 1y ago
      No, this proves my point. Back in my days of backend programming, Varnish was the "magic" that made servers (especially CMSs) feel fast. Memcached is another common go-to cache. Browser caching isn't a replacement as the first request for every endpoint is still going to be slow. Yet somehow, APIs aren't treated with the same requirements for performance as web pages.
      - deleted 1y ago
        [deleted]

atoav 1y ago

As a fellow vanilla-fan: If this shows anything, it shows how bloated modern web development has become. Your page is snappy as hell.

insin 1y ago
Modern static content web development is in some of the best health it's ever been in with the likes of Astro. You get your lovely developer experience with components, with the same component API enabling layouts for the repeatable outer structure, easy composition of reusable parts of your content, ease of passing data around between these and implementing any logic you need before rendering or inside what you're rendering. The user gets a snappy, static website.

pinoy420 1y ago

[dead]

metabagel 1y ago

Blazing fast. Wow!

hoherd 1y ago
I thought this was sarcasm, so I loaded the page, and yeah, that is an insanely fast cold load time, and even more impressive once the resources are cached.

electroly 1y ago

While I think your page is excellent and loads great, I don't think this is related to the approach described by TFA. You're using the biggest framework around: WordPress. You're just static rendering it. TFA is talking about no build tools at all, using modern web standards, and specifically nothing requiring preprocessing. "... just an editor, a browser, and web standards" is a quote from the page.

andrewstuart 1y ago

No user cares about 100K.

austin-cheney 1y ago
They care about time and they absolutely do care. If your giant virtual DOM mess takes 10x longer to respond on every user interaction they will absolutely notice. It’s just the developers that don’t care because deviating from the framework puts their job at risk.
- someothherguyy 1y ago
  > 10x longer to respond 10x longer than what? > It’s just the developers that don’t care because deviating from the framework You realize that many major modern (and legacy) web frameworks started inside companies?
  - austin-cheney 1y ago
    10x longer than not using that framework and yes, I do realize that.

lolinder 1y ago

I think that this comment is a great example of the total disconnect these conversations always have. On the one hand we have lots of people on here who are building full-featured web apps, not websites, on teams of 30+. These people look at frameworkless options and immediately have a dozen different questions about how your frameworkless design handles a dozen different features that their use case absolutely requires, and the answer is that it doesn't handle those features because it doesn't require them because it's a blog. Meanwhile there are also a lot of people on here who have never worked on a large-scale web app and wonder why frameworks even exist when it's so obviously easy to build a blog without them. It would be nice if we could just agree that the web hosts an enormous spectrum of different kinds of software and make it clear what kind of software we're talking about when we were opining about frameworks—whether for or against. In this case: this is a WordPress blog.

dorfsmay 1y ago
On the third hand, some people use React and some framework to write static web page...
- lolinder 1y ago
  And if you can point me to an example of that I will happily lampoon them. If we're talking about Medium, then yes, Medium is a complete disaster zone that should not be emulated anywhere. Their reader-facing use case does not require JavaScript at all except as a light optional seasoning on top. All I'm saying is that we need to actually talk about use cases whenever we're talking about frameworks, which we almost never do. Failing to specify the use cases turns the conversation incoherent because we end up having two different conversations without even realizing it.
  - austin-cheney 1y ago
    The primary use case for these large frameworks is hiring.
- emseetech 1y ago

jemmyw 1y ago

Nice site, I found some interesting stories. I do find it a little annoying that when we have these discussions about vanilla vs frameworks people hold up an example and I go there and see a news site of articles rather than a complex application, and I think to myself yeah I wouldn't have used a framework in this situation anyway. It's annoying from 2 directions: the first that people ARE using frameworks for sites that shouldn't have ever had them in the first place, and I can bring to mind a couple of news sites I visit regularly where this is obviously the case because of the silly ways they work. Secondly that this is then held up as an example, because most of my work is on very interactive sites so I end up thinking well yeah but that's not going to work for me is it. My feeling is that I could do vanilla but would end up with something like a site specific framework. My current approach is to use a framework and consistent patterns but to try and use as few other dependencies as possible.

eviks 1y ago

Not sure if it's no-framework related, but navigation back/forth is sometimes broken: the url changes immediately, but the page doesn't update and stays on the same article. Also infinite scroll breaks the most basic usability issue - you can't track where in the article you're with the scrollbar positioning

ntnsndr 1y ago

I love Rest of World! Great work!

pier25 1y ago

> I've always questioned why we should add 100KB of JavaScript to a page before writing a single line of real code With most frameworks you don't need 100kB of JS code. Heck, with Mithril you get the components, vdom, router, and http client in like 10kB gzip.

chillpenguin 1y ago
shoutout to Mithril! Has always been an under-appreciated gem.
- pier25 1y ago
  maybe you'll be interested to know v3 is in active development https://github.com/MithrilJS/mithril.js/pull/2982 https://github.com/MithrilJS/mithril.js/pull/2982

andoando 1y ago

My problem with all this vanilla showcases is they are dead ass simple pages with the most basic layouts and user interaction. Shit just show me how long it takes you to create a nice reactive table with search or a form with proper labels, user interaction, validation, errors, etc Why would I implement that all from scratch when I can install svelte install a UI library and add a couple lines of code, all with a 25kb overhead and get a better, nicer looking, more well tested product that would take you to do in a week?

claytongulick 1y ago
Increasingly, this is actually an argument in favor of vanilla web components. The WC ecosystem has grown a lot, and one of the great things about native web components is that they can be consumed by most major frameworks at this point. There are also many mature component sets you can pick from, like shoelace, etc... you can mix and match components from different offerings, something that's not practical with React/Angular (for example). I can use a select from Ionic, a breadcrumb from Shoelace, and a date picker from Lightning and it'll all just work. Doing vanilla Javascript development doesn't mean "don't use any libraries" (well, it might to purists, but whatever) it means stick to using standards based technologies with libraries and accelerators. For example, I use many of the techniques described by the site, but I prefer to use lit-html library (NOT lit framework) for rendering. Sometimes I use the vaadin router for routing, sometimes the Ionic router, sometimes my home grown one. I use a little library I wrote called ApplicationState for cross component shared state, because I don't like state being coupled to my DOM structure. Sure, this requires a deeper understanding than "batteries included" frameworks, but the advantages outweigh the negatives IMHO.
- andoando 1y ago
  If you use a bunch of libraries for routing, UI, authentication, the only thing thats left is the rendering. And quite frankly I don't see why Id want to reinvent the wheel there. {#each notes as note} {note.content} {/each is exactly what Id want to implement for example if I were writing JS functionality to render a collection. And Svelte for example doesnt restrict you from using vanilla JS whenever you want either

littlecranky67 1y ago

> I've always questioned why we should add 100KB of JavaScript to a page before writing a single line of real code 100kb would never be a considerations for any of the apps I worked on (as a contractor in the corporate world). I mostly work in large teams, sometimes we had mulit-team monorepos with various line-of-buisness apps using React. 100kb are so completely irrelevant, as for LoB or B2B, no-one cares about the initial page load. Your users use the app on a daily basis, so they get all the JS/CSS/static assets served from their browser cache almost all of the time, until we make a new prod deployment (usually weeks). Plus, all users are always on Ethernet or WiFi at least, not some 3G cellular network somewhere in the desert. If you use some smarter framework like Next.js, you even get smartly chunked js parts on a per-route basis, that are immutable - they contain a sha256 hash of their content in the filename, and we configure the webserver to serve them via `Cache-Control: immutable`. There won't even be a roundtrip to check for newer versions. Plus Nextjs comes with tons of other stuff, like pre-loading chunks in the background, or when hovering over a link (i.e. using the time between the hover and the click to already load a chunk). Let alone that the initial render is static html and hydration happens completely unnoticed from the user.

lolinder 1y ago
This is spot on. Load times do not matter for the kinds of apps that: * Are exclusively loaded on high speed internet in corporate networks. * Have a high hours-of-work-per-page-load count. * Update infrequently. We're engineers, or at least we like to call ourselves that. Engineering is the process of gathering requirements and building a system that meets those requirements on time and under budget. If your requirements include being able to serve users on 3G networks or users who only load your site in order to read a single piece of content per day, yeah, optimize your load times. But don't attack other engineers for failing to live up to your app's requirements.
zelphirkalt 1y ago
That's assuming quite a few things though about the user's browser. Like cache not being cleared on shutdown. And on the project side, that there are not so many changes, that need to be received by the user agent now, instead of whenever the cache expires. That updates can be applied later on the user side. Of course when updates only happen every few weeks, then it might work... but only if that cache is not deleted, which is a big if.

worldhistory 1y ago

what? that is impossible

jimbob45 1y ago

I've always questioned why we should add 100KB of JavaScript to a page before writing a single line of real code. Developer productivity, theoretically. Although some of these frameworks don’t help with that for me personally.

robertoandred 1y ago

Your primary image is over 200kb. 100kb is nothing. And you're using WordPress, so yeah you are using a framework. Turns out you do think they're necessary. And as you can see, framework != slow, whether it's WordPress or anything else.

donohoe 1y ago
I believe the topic is front-end frameworks. WP is used as a CMS but the entire front end is built from scratch.

bigtones 1y ago

Rest of World looks like a fantastic news website I was not familiar with. I just spent a half hour reading a whole bunch of interesting articles there. Well done for helping build it - its super fast from Australia.

ummonk 1y ago

What do you even need JS for on that site? It looks like it should be doable with plain HTML.

vivzkestrel 1y ago

So you are the guys behind this amazing news website. What made you build this and is the target audience American? If you don't mind me asking, how are you guys monetizing this? Is this a funded venture or bootstrapped?

EZ-E 1y ago

Fantastic website, really happy to be able to finally read interesting stories and news about the tech scene where I work, in Vietnam

duc_minh 1y ago
Took me off guard too :D I didn't expect to click on a random link on HN and see an article about my home country

rikroots 1y ago

I recently did a ShowHN post for my browser-based screen recording web page side project. 100% vanilla, with added wasm-based ML shenanigans. It really is amazing what functionality can be built into a web page without resorting to framework support! https://news.ycombinator.com/item?id=43960434 https://news.ycombinator.com/item?id=43960434

heyheyhouhou 1y ago

Just wanted to say that I really like restofworld.org. Thanks to you and your team for building it.

redbell 1y ago

> My team and I built https://restofworld.org https://restofworld.org without any frameworks. Puter (https://news.ycombinator.com/item?id=39597030 https://news.ycombinator.com/item?id=39597030) was also built purely using vanillaJS (or, JQuery to be more precise)

replwoacause 1y ago

The site is beautiful... and fast too.