DEV Community: Joost van der Schee

A carousel in two lines... and more crazy simple front-end tricks!

Joost van der Schee — Fri, 14 Nov 2025 10:21:32 +0000

Need a lightweight responsive carousel that also works on mobile (with swipe). Need a masonry layout? A filter? A lightbox? What if I told you all you need is a CSS class and a small vanilla JavaScript file?

With this idea in mind I started my own code library. Check it out. It currently holds 6 different front-end tricks that you can implement in seconds!

https://code.usecue.com/

Isotope in just 60 lines...

Joost van der Schee — Wed, 22 Oct 2025 22:54:56 +0000

I saw the original Isotope Javascript fancyness and I just had to write a rebuild using modern web standards. Check out my rebuild! My version of Isotope uses a grid layout and animates using view transition. It is silky smooth, blazing fast and has graceful degredation. The code consists of only 63 lines of vanilla JS, while the old version required an astonishing 3500+ lines. If you choose to leave the sorting out, you can even reduce the code to 37 lines. Yup... the web has come a long way.

How to use it?

Just set id="isotope" on any container and give its children classes that represent categories, like class="metal". Then create some buttons with data attributes, like data-filter=".metal" or data-sortby="symbol". Load the JS from the demo in the footer and it works. You don't need ANY of the CSS. That is all just fancy stuff.

Caveats

Note that this version only supports basic filtering and sorting (which are the only things I ever used from the original code). Also note that the animation might not show in older browsers. Finally, be aware that you can not use this Isotope filter twice on the same page, as it lacks abstraction for that.

License

This is so basic, you can't license it. You would license modern web standards, which is crazy. So, if anything, it should be WTFPL. The original Isotope code was licensed GPLv3 and was not free for commercial use.

Enjoy the code!

Joost van der Schee

Responsive Tiled Mosaic Image Gallery

Joost van der Schee — Sat, 30 Aug 2025 20:24:17 +0000

I was converting a website from WordPress to Hugo and needed an equivalent to the Tiled Image Gallery from Wordpress. I wanted the Tiled Mosaic style, but that was a little to complex, as it also contains colspans. I came up with this as an alternative. You can find it here:

https://code.usecue.com/mosaic/

It has a WTFPL license and is almost fully 'vibe coded'. It is Javascript-heavy and requires no CSS. It uses a simple HTML structure, as illustrated below:

<div class="tiled-gallery">
   <a href="full_img_src">
      <img ratio="0.666" src="thumb_img_src" />
   </a>
   ...
</div>

The hardest part of using this code is determining the image ratio before rendering. Any server side language (like PHP) can generate these image ratios though, as can Hugo (which I have built this for). Knowing the image ratio before loading the images prevents layout shifts and ensures a smooth loading experience.

This whole javascript is only a few kilobytes large, so it loads relatively quickly. It is fully responsive and has a debounce function that limits the redraws to 50ms, preventing it from being CPU-heavy.

Aestheticly, it aims for about 1 image every 700px of width. The images always fill out nicely and the code prevents subpixel issues. Images have a minimum size, which turns the gallery into a list of images on mobile. The margin between the images is 4px.

I did not take the time to fully understand the code, but it works pretty nice.

Enjoy!

Native apps are dead

Joost van der Schee — Tue, 03 Dec 2024 13:25:12 +0000

A single line of CSS can enable slick multi-page transitions for web applications (and websites for those who maintain there's a difference), opening up new possibilities for web app architectures, and website experiences.

@view-transition {navigation: auto;}

The upcoming of native apps

The launch of the iPhone in 2008 coincided with (and likely ignited) a resurgence of the web. Native iPhone apps arrived, with their smooth, animated state transitions between views, panels and widgets sliding in and out, and satisfying, physics-driven responses to user interactions. The web's traditional multi-page architecture was no match; moving from one page to another was clunky, with screens going blank as new pages loaded over sluggish 3G networks.

This resulted in an article from Wired The Web Is Dead. Long Live the Internet, in which they stated that the web lost its relevance and competitive edge. The problem wasn’t just the lack of engaging transitions. Web apps also lacked access to platform APIs, such as address books, cameras, and Bluetooth—features leveraged by native apps to create viral growth and novel experiences. But the absence of smooth UI transitions certainly didn’t help.

Unfixable shortcomings

However, native apps also had some unfixable shortcomings, like the lack of SEO / discoverability. To be discovered you needed to be featured in the app store, which meant you had to pay Google and Apple. Additionally, you could not use any business model, as there were strict income rules in the app store. Finally, your app had to work on both iOS and Android, requiring a complex codebase that needed to be updated frequently. Therefore, native apps were limited in terms of growth and business model, and the multiple platforms led to high development costs.

The comeback of the web

The promise to make the web competitive again came from Single Page Applications (SPAs). They would allow you to create a website with the advantages of an app, but none of the disadvantages. But, as we learned over time, SPAs also had their shortcomings. There were SEO challenges, complex codebases, accessibility issues, slow loading times and maintenance headaches. Nevertheless, SPAs paved the way for more app-like experiences in websites.

Today, thanks to SPAs, we have access to almost all platform APIs on the web. The only big reason to choose an SPA over a website (or multi-page application) would be the smooth page transitions. But that has been fixed as well with View Transitions. There seems to be no reason left to choose for a native app or SPA. This means that the web has won after all. You (probably) no longer need an app. You just need a website.

This is article was first published on www.usecue.com.

SSG's have become boring technology

Joost van der Schee — Tue, 03 Dec 2024 13:24:46 +0000

Static site generators took off in the year 2008 with Jekyll and Tom Preston-Werner. He simplified website data, by storing it in flat files. These files could then be managed by Git, meaning full ownership and control over all changes.

You probably expect me to tell you that now, 15 years later, it is time to move on... but I will do exactly the opposite: NOW is the time to adopt static site generation. Because only now, 15 years later, static site generators have become boring technology. This means that all solutions are proven, widely spread, have a minimal amount of dependencies and all (related) software is mature and well-crafted. It is so far evolved that the evengalists of the first hour have decided to move on. All problems with static site generators have been solved many times and there is a widely spread agreement on how it all should work.

For those who missed the rise and the evolution of static site generators, I will summarize what the advantages of static site generators are. First of all, you own your data, which is stored in simple flat files in a Git repository. Secondly, you can choose ANY open-source static site generator to turn those files into a website. The static site generator you choose depends on which templating language you prefer and how many data files you have. Next (pun not intended), you need a very simple CMS that is not much more than a fancy markdown file editor. There are many options available, both paid and free. Finally, deploying your output to a hosting environment is a piece of cake. Although there are many options, a simple 'rsync' can do the trick as well. The fact that these things are all separated makes it very robust. You can switch your SSG without switching your CMS or changing your data structure. The same goes for switching your CMS or your deployment method: everything is interoperable.

One of the nicest things about static site generators is that Github is offering a fully integrated solution for free. They manage your files using Git, will build your website using ANY static site generator with Github Actions, and allow you to host the output on Github Pages. When you use Frontmatter.codes in Visual Studio Code you will even get a fully featured (and free) CMS.

So... there is a very appealing all-in-one solution from the biggest code platform in the world, powered by Micro$oft. Fortunately, there are also hundreds of alternatives for every part of this solution and they are all interoperable. The SSG eco-system has matured and you will no longer feel trapped in any way. SSG's have officially become 'boring technology'. This means you can use SSG's worry-free in production.

Happy coding!

How to build a fast website?

Joost van der Schee — Sun, 06 Oct 2024 09:00:28 +0000

There are only four thing you have to know when you want to build fast website. They are equally important and relatively simple.

I know this, because all my websites have a near perfect Google Lighthouse score. Forget about the endless lists of optimizations you may have seen before. These four guidelines will make your website load instantly.

1. Make your website small

When I say small I mean really small (in terms of page weight). Do not just use lightweight images, but also write as little CSS and Javascript as possible. Aim for 15kb of CSS and 3kb of Javascript. The reason for this, is that CSS and Javascript are often 'blocking', thus delaying the rendering of the page. The average Wordpress website is 3000kb large and serves almost 10 times that amount of CSS and 100 times that amount of Javascript. No wonder most websites are so slow!

2. Make it static

A dynamic page that has to assemble all HTML before serving it to you, will take significantly more time to render than a static page that already consists of plain HTML. The database connections and database requests delay your page load. Static pages are as fast as fully cached pages, which are basically static pages as well. Make it static, either by caching everything or by using a static site generator.

3. Get a fast host

Some servers take much longer to reply to requests than others and some servers are slow at executing database queries or executing server-side code. The specs of the server and the amount of concurrent users influence the speed of the server. There is no easy way to find out if you have the fastest host. The only way to do that is to benchmark them (or have somebody else do that for you). Get a really fast host.

4. Serve from the best location

If you have to travel to the other side of the world to serve your website, you will lose approximately 1 second. This means that you should serve your website as close to your audience as possible. CDN's might seem like a good solution for this, but that is not always the case. Choose your servers location(s) wisely.

That is it!

These four guidelines are the answer to the question 'How to build a fast website'. They will make the difference between a website that takes more than 3 seconds to load and a website that loads instantly.

The article How to build a fast website first appeared on www.usecue.com.

SSG's have become boring technology

Joost van der Schee — Fri, 22 Dec 2023 11:46:10 +0000

Happy coding!

Long live the lean web

Joost van der Schee — Wed, 23 Nov 2022 22:37:44 +0000

The following text is a Twitter thread from Thomas Fuchs. Every web developer should have read this. He posted it in November 2017 and it becomes more valuable every year. Chris Ferdinandy even wrote a whole book about it. Thomas ended the thread with the title of this post: 'Long live the lean web'.

It’s a weird dichotomy: the more capable underlying web tech gets (CSS features, HTML canvas, etc.) the more larger and more complex frameworks on top of it become. If you actually use the underlying improvements directly you’ll notice that you need less and less JavaScript. I noticed that in our new app. We get so much more done with a lot less scripting especially because of newer CSS features like flexbox, calc, vw/vh units, compositing modes, etc. Most of the scripting has to do with progressive enhancement, rather than making basic stuff work. This has so many positive effects:

Much improved load times, especially on mobile
no lock-in to a client-side framework
simpler HTML structure
Less code = easier to debug
Get more done faster with a smaller team
Almost no cross-browser issues anymore

I’m hoping for a second renaissance for the Web, like the one we had after we collectively decided that we don’t want Flash no more. That will happen when people realize that ginormous lock-in client-side “browser-in-a-browser” frameworks aren’t necessary to make great apps.

KISS.
Less is more.
Brevity is the soul of wit.
</rant>

A huge fan

I have been advocating this lean web for quite a while now. I was interviewed recently about artisanal web development by David Large from CloudCannon, where I advocated passionately for less code (and writing this code yourself). Additionally, I posted an article on how to get a 100% Google Lighthouse score, which has generated quite a bit of attention. My trick to get to these perfect scores is to stop using frameworks. This is in line with the lean web. I also wrote a post about the Jamstack report from 2021, where we can see that Jamstack websites (on average) became terribly slow as a result of using insane amounts of Javascript. The lean web has clear advantages.

You can never give too much credits, hence this post. I aim to be a part of the second renaissance Thomas dreams of. Let's make it happen! Long live the lean web!

This post was originally posted on www.usecue.com.

How to get a 100% Google Lighthouse score

Joost van der Schee — Thu, 06 Jan 2022 17:30:57 +0000

Google will soon shame slow websites. A good reason to take a good look at your Google Lighthouse score right now. A good reason to take a good look at your Google Lighthouse score right now.

You might feel that it is nearly impossible to get to a perfect 100% score. You minified your Javascript, properly scaled your images and even combined some requests, but that did not help nearly enough. The problem is: you might be looking at it from the wrong angle.

I build 100% scoring websites on a daily basis, so obviously it is very well possible to get a perfect score on all your websites with little effort. I will try to explain what we want to achieve and how we can achieve that.

There are some basic facts that a lot of people get wrong when it comes to speed and performance. Minifying does not beat gzipping, image scaling does not beat JPG compression and combining requests is actually counter-effective over HTTP/2. These are probably the reasons why your earlier efforts had so little effect. Another important thing to know is that Google Lighthouse simulates a slow connection. This emphasizes the importance of a low 'page weight' or 'total size' over fast infrastructure, as a small page is delivered significantly faster over such a narrow connection than a large page.

Before we look at the actual steps we need to take, let us look at some websites that score (nearly) 100 points on all four categories. It will give you an idea of what the end-result could or should look like. For each site I have listed the weights: the Javascript, CSS and the total page weight. You can also see the number of requests, as well as the time it takes the server to respond (TTFB) and the site to load. Note that these results are results from my computer. Finally, I listed the host, the company that built the website and the Google Lighthouse score. Note that the comma separated numbers stand for Performance, Accessibility, Best Practises and SEO.

debabywegwijzer.nl
Javascript:	0kb
CSS:	9kb
Total size:	120kb
Requests:	9
TTFB:	22ms
DOM loaded:	274ms
Loading time:	596ms
Hosted on:	CloudFlare (CDN)
Built by:	Usecue BV
Score:	99,100,100,100

...

[article truncated]

Do you like this? Read the full article on How to get a 100% Google Lighthouse score at www.usecue.com.

Building a Jekyll Site in the browser in less than 20 minutes

Joost van der Schee — Sat, 14 Mar 2020 23:17:47 +0000

At my first conference talk ever (JekyllConf2019) I showed the world how to build a Jekyll website in under 20 minutes, using nothing but a browser.

https://vimeo.com/361839295

Why Jekyll?

Jekyll transforms your plain text into static websites and blogs. It is simple: no databases or pesky updates to install. It is static: Markdown, Liquid, HTML & CSS go in and blazing fast static sites come out, ready for deployment. It is feature rich: Permalinks, categories, pages, posts and custom layouts are all first-class citizens. Additionally, Jekyll gets you free hosting with GitHub Pages. Are you sick of dealing with hosting companies? GitHub Pages are powered by Jekyll, so you can easily deploy your site using GitHub for free—custom domain name and all.

Why in a browser?

A lot of people think that Jekyll requires the command line, which is scary for beginners. In my tutorial I show you that you do not need to use the command line.

What will we build?

We will be building a Jekyll website with version control (Git), a CMS and a form builder. Are you ready?

https://vimeo.com/361839295