Forem: Jesper Høy

Introducing OwnCDN

Jesper Høy — Fri, 17 Apr 2026 10:07:09 +0000

OwnCDN is self-hosted CDN server software
running as an IIS website on your own Windows computer/VM/VPS.

It does caching (disk/memory), replicated and versioned object storage (S3 compatible), and image resizing and optimization - effectively your own CDN node.

Services can be chained together in any order to provide a powerful system.

For example: HTTP Publisher → Disk Cache → Image Optimization → Blob/object storage.

OwnCDN is configurable through a web-based user interface.

It has a simple HTTP API which also supports Amazon S3 API syntax, making it compatible with a long list of software and services.

Features

File/object storage

Provide centralized file/object storage.

The "Storage service" provides versioned and replicable storage (like Amazon S3).

The "File System service" provides access to files in the local file system.

You can make store, retrieve, and delete files/object via the "HTTP API service" or provide public access to the files with the "HTTP Publisher" service.

Caching

Provide caching to bring files/objects closer to users, to serve files/objects faster, and/or to reduce traffic to origin servers.

The "Memory Cache service" provides temporary caching for files/objects which are requested very frequently and/or need very fast delivery (like Redis).

The "Disk Cache service" provides temporary file/object caching - persisted to disk so that it survives server restarts.

You can configure the cache services to retrieve files from a remote web-server using the "HTTP Fetcher service", or you can upload files via the "HTTP API service".

You can provide public access to the cached files with the "HTTP Publisher service".

Image Optimization

The "Image Optimization service" reduces image file size using and automatically scales and/or crops images.

OwnCDN origin story

My company (JH Software) also develop and run an educational platform with on-line tests and exercises for Danish elementary and middle schools - see https://tjek.net (Danish language only).

For years, we ran this as a single ASP.NET website under IIS on a Windows VPS (virtual private server) at various cloud providers.
But when GDPR (EU privacy regulations) hit, it became difficult to be in compliance while keeping the data with cloud providers.

So, we decided to move the core of Tjek.net home to a server running in our own office where we can ensure privacy and security for our users in accordance with GDPR.

As part of Tjek.net, we also serve a lot of images and videos (not user-specific) as illustrations in the on-line tests and exercises, and we didn't want to serve these through the limited bandwidth of our office Internet connection.

Since we were still running a (now underutilized) Windows VPS at a cloud provider for other purposes, we wanted to try and use this for serving the images/videos and to cache some dynamically generated content from the office server.

This meant that we needed some kind of object storage software (like AWS S3) and web caching software (like a CDN) running on this server.

Since we couldn't find any suitable software for this, we started putting together our own.

After refining this software for several years, this is, of course, what eventually became OwnCDN.

Today OwnCDN is serving 250K+ images/videos for Tjek.net every day, while barely registering on the CPU usage chart on the VPS.

Check out OwnCDN at https://owncdn.com

Filter CouchDB query results with arbitrary JavaScript - like SQL WHERE...

Jesper Høy — Sun, 04 Jan 2026 11:33:18 +0000

CouchDB has a "List function" feature which allows you to transform query results.

This can be used to filter results and/or generate HTML, XML, JSON, etc. - in CouchDB - before it is returned to the client.

A List function (JavaScript) needs to be stored in a design document in the same database as the data to be queried. So this JavaScript code is going to be static.

However, when executing a List function, it is possible to provide various parameters to it via URL query parameters (available as members of the Request.query object).

By sending JavaScript code as one such parameters, it is actually possible to run arbitrary JavaScript - dynamically generated client side(*) and potentially unique for each query - as part of a List function.
And so, a single List function can be used to execute any number of client defined(*) filters/transforms.

This is very similar to SQL WHERE functionality - only using JavaScript instead of SQL.

The following is the JavaScript code for a List function which takes 3 custom URL query parameters; "js_code" as the filter code to execute for each result row, "js_skip" as the number of initial rows to skip, and "js_limit" to limit the number of rows returned:

function(head, req){
  let filter = new Function("_r", "return (" + req.query.js_code + ")(_r);");
  let Skip = parseInt(req.query.js_skip);
  let Limit = parseInt(req.query.js_limit);
  start({'headers': {'Content-Type': 'application/json'}});
  let resp = head;
  resp.rows=[];
  let row;
  while (row = getRow()) {
    if (filter(row)) {
      if (Skip > 0) {
        Skip -= 1;
      } else {
        resp.rows.push(row);
        if (Limit>0 && resp.rows.length >= Limit) break;
      }
    }
  }
  return JSON.stringify(resp);
}

The code above would need to be included in a design document under lists / jsfilter.

I now add this exact List function to most of my CouchDB design documents, so that I always have this functionality readily available.

The JavaScript code that you send in the js_code parameters would look somthing like this:

function(row) {
  if(row.OrderNumber != 3) return false;
  return row.Color == "blue";  
}

Or, the short version:

row => row.OrderNumber!=3 ? false : row.Color=="blue";

(*) By "client side" / "client defined", I mean whatever code is sending the query to CouchDB. This would typically be code running on a server, like web-server server side script. You obviously don't want to give end-users direct access to this.

NOTE: The CouchDB documentation states that List functions are deprecated and will be removed in "CouchDB v. 4".
"V. 4" was a, now abandoned, effort to replace the underlying storage engine for CouchDB.
Since that "v. 4" will never be, and the current v. 3 is very actively maintained, I think (and hope) List functions will be around for the foreseeable future.

Why I am moving to CouchDB

Jesper Høy — Tue, 20 Feb 2024 00:44:21 +0000

Update April 2026
I am still a big fan of CouchDB, but I no longer use it after making
OwnCDN.
Indeed CouchDB was a big inspiration for the replication system in OwnCDN.
I now use OwnCDN for everything that needs "live continuous replication/backup" (JSON documents, images, and otherwise), and SQLite for everything else.

Starting today, I will be using CouchDB as my primary database server for new projects and will gradually be moving existing projects to it.

I have been using Microsoft SQL Server for many years and never really gave it much thought - it just works - and I know how to make it work. And it is pretty fast given the right hardware and configured with the right indexes etc.

Late to the No-SQL party?

I know this sounds like swimming against the current - or being late to the No-SQL party. But this is really about the overall feature set of CouchDB specifically - and not an SQL vs No-SQL thing.

I don't have big data...

Many articles on why you might use No-SQL databases (like CouchDB) point to "big data" as the main reason. But I don't have "big data". My largest SQL database is around 5GB with a few million records total. So that's not it.

I don't need master-to-master replication...

As for CouchDB specifically, many articles point to master-to-master replication, filtered synchronization with client devices using PouchDB, or offline-first scenarios. Those are great features - but that's not it either.

So why CouchDB?

It is simple!

Other database systems certainly have a lot more features.
But for 99% of what I do - CouchDB is plenty.
And I'd much rather use a simple system that I can get my head around, than some complex thing that I will never fully understand or utilize.
Lightweight

In my tests with 500K records, it used less than 100MB of memory and otherwise hums along at below 40MB.

This makes it feasible to run it on a small server / VPS alongside other stuff - like your web-server.
Live continuous replication/backup

Setting up live continuous replication/backup to another CouchDB instance is super easy.
Having an always up-to-date replica beats daily SQL server backups by a long shot (virtually no risk of data loss vs. risk of losing up to 24 hours' worth of data).

You can even do filtered replication - providing different clients different parts of the database - something that is impossible with most other database systems.
Data is just JSON

JSON is THE universal data language.

We have to use it when doing any kind of web front-end stuff, so we might as well use it with the database too.

This also makes it possible to re-use a lot of serialization code.
HTTP REST interface

No client libraries needed.

Makes it universally and easily accessible - from code, command line, HTTP tools, etc.

For example, using .http files in Visual Studio or the REST Client extension in VS Code.
Web-based admin panel

CouchDB comes with a built-in web-based admin panel called "Fauxton" for basic server administration.

It is easy to also install Photon (a much nicer admin panel alternative), which additionally lets you do ad hoc SQL queries, diff document revisions, perform backup/restore, and much more - all through a browser from anywhere.
Map/Reduce

In addition to traditional indexes (fixed fields, sort-order, partial-condition), called "Mango indexes" in CouchDB, CouchDB also has a very powerful Map/Reduce feature.

Map/Reduce lets you define keys and conditions through JavaScript functions (the "map" part of map/reduce) giving you a lot more flexibility.

To sum (or do other calculations on) the values in a column for a set of rows, with SQL, the server needs to go through every one of those rows every time you execute the query. With CouchDB, the server can do most of this work ahead of time along with the indexing (the "reduce" part of map/reduce), making such queries much more efficient. And again, because this is defined through JavaScript functions, you get a lot more flexibility.

Map/Reduce is also what lets you put invoice-lines in the same document (record) as the rest of the invoice, while still being able to index and query those lines individually.
No schema

With SQL, I have to constantly tweak the database tables and columns as I write my code.
And I have to "normalize" my data (= structure it in a weird way - like putting invoice-lines in a separate table).
The schema-less nature of CouchDB makes life so much easier in this regard.

My data is already validated and structured by the application (like server-side code on web-sites), so repeating this in the database is just extra work.
No cloud vendor lock-in

Because CouchDB is software that runs on your own hardware (or VM / container), you can easily move your data to another CouchDB instance running anywhere - on-premise or at any cloud provider - using the built-in replication feature.

You cannot do this with Amazon DynamoDB, Microsoft Azure Cosmos DB, or Google Firestore / Bigtable.
Free / open-source / Apache

Who doesn't like free? Being under the Apache Foundation means that it will stick around for a while.

What about ad-hoc queries?

One advantage of SQL databases is that you can always write a quick SQL query to get out your data filtered, and sorted just the way you want - without regard to indexes (it may take a while but it will run).

With Photon (see above), you can actually do the same with CouchDB - query it using basic SQL statements.

CouchDB also has its own JSON-based query language called "Mango" (which is what Couch Photon SQL queries use behind the scenes).

You are NOT forced to create map/reduce views for all queries - like some internet posts would have you believe.

What about joins?

You won't need joins as much with CouchDB because of "de-normalization" (invoice-lines in same document as invoice itself).

But you can have linked documents which is a simple way of doing 1st level joins.

What about the horror stories of slow re-indexing when changing design documents?

I read them too. So I ran some tests.

I first created a CouchDB database with 500,000 documents (real-life data copied from a SQL database), then created a new design document / view, then did a query against it, then waited... for about 1 minute, and then it was all indexed and responding crazy fast. And this was with CouchDB running on my old laptop!

This does not scare me.

What about rumors that CouchDB is a disk hog?

I read them too. So I ran some tests.

Compared to SQL Server, it does use almost twice as much disk space for data (after compression / compacting).
This is understandable given that "column names" are stored in every "row".

And it seems that you need to schedule compression on a regular basis to prevent data files from "exploding".

For me, this is an acceptable tradeoff.

One of the original selling points of SQL and "normalization" was preservation of disk space - because disks used to be slow and expensive. Neither is the case today.

What about MongoDB?

I did of course also look at MongoDB - the more popular choice amongst No-SQL databases and similar to CouchDB in concept.

From what I gather, MongoDB has better performance and tooling, but it is also more complex and not as lightweight (it uses much more memory).

MongoDB uses a proprietary client access protocol and thus needs proprietary client libraries/drivers (vs just using HTTP REST).

It uses BSON rather than JSON.

MongoDB is a 572MB download - CouchDB is 66MB.

From what I have seen, CouchDB is plenty fast, and I do prefer simple and lightweight over complex and heavy :-)

Conclusion

I have been "playing" with CouchDB on a few side projects, and the experience has just been fantastic so far.

I am now ready to go all-in :-)

Evaluating VB.NET to C# converters

Jesper Høy — Tue, 02 Jan 2024 11:03:00 +0000

I am converting several projects from VB.NET to C#. In preparation for this, I tested 4 different VB.NET to C# conversion tools with sample code from those projects.

I encountered several problems, and I thought that I'd share my findings with others who might be going through the same process (I initially paid for the wrong tool by mistake).

Converting the following tiny VB.NET application with each of the tools demonstrates some of the problems that I ran into:

Telerik Code Converter

Free online tool: https://converter.telerik.com (tested on Dec 30th, 2023)

On the first attempt, this converter "crashes" (included a long error message in the output) because of the date literal #1970-01-02# in line 6 of the VB code.

After changing the date literal in the VB code to New DateTime(1970,1,2), I get this output:

The only remaining issue is in line 11 of the output - the VB ternary operator if(...,...,...) was correctly converted to C# ...?...:... - but missing surrounding parentheses. This could lead to some nasty bugs...

After adding the missing parentheses, this C# code compiled and ran.

ICSharpCode Converter

Free online tool: https://icsharpcode.github.io/CodeConverter (tested on Dec 30th, 2023)

Also available as a Visual Studio extension: Code Converter (VB - C#)

Output:

Notice lines 10-12 (corresponding to lines 6-8 of the VB code). The code for those lines is just gone! This appears to have something to do with the lambda function as it does not happen in regular functions.

The same thing happens in the Visual Studio extension.

VBConversions

Windows desktop application from https://vbconversions.com

Testing with version 5.08 (paid $295 for "Lifetime License") using the "Snippet converter" function.

Output:

This converter also appears to have a problem with lambda functions (output lines 8/9).

Also, any variable declaration with an initializer of an inferred type (Dim VariableName =...) is converted to object VariableName =... (output line 13). The other converters output var VariableName= ... which works a lot better.

Also, the VB ternary operator if(...,...,...) was not converted at all (output line 14).

Also, it does not handle VB multi-line statements correctly (output lines 14-15).

Instant C# .

Windows desktop application from https://www.tangiblesoftwaresolutions.com/product_details/vb-to-csharp-converter.html

Testing with version 23.12.21 (paid $159 for a "One-Year Subscription License") using the"Code Snippets" function.

Output:

Compiled and ran correctly on the first attempt.

Conclusion

Looks like I will be using Instant C#

Revisiting site search + SQLite as a search engine

Jesper Høy — Thu, 06 Apr 2023 11:31:00 +0000

Back in 2017, I researched adding search functionality to our websites (blog post) and ended up going with Zoom Search Engine.
This has worked OK, but not without issues...

So, as I was re-structuring our web-sites, I decided to have another look at the options for this.

Full "site search engine as a service"

(= crawler + index hosting + search UI / widget + management / statistics)

I had a quick second look at the services from my 2017 round (prices for 400 documents):

AddSearch - https://www.addsearch.com - $29/month
Site Search 360 - https://sitesearch360.com - $9/month
Cludo https://www.cludo.com - $5000/month
Swiftype - https://swiftype.com - $79/month.

Also found a couple of new ones:

Findberry - https://www.findberry.com - $10/month.
Expertrec - https://www.expertrec.com - $49/month.

A few aspects (including price) of SiteSearch360 seemed more interesting than the others, so I decided to give this a try.

I got this fully implemented and running on our websites.

One thing I really liked was the way you tell SiteSearch360 which parts of web-pages to index using CSS query selectors (or XPath). I eventually ended up using this concept in my solution (see below).

The crawling and management/statistics were also nice, but I wasn't real happy with the search UI integration.

Full text search as a service

(= index hosting + management / statistics - but no crawler)

I looked at:

Algolia - https://www.algolia.com - 10,000 free searches/month, then $0.50/1,000 searches.
Meilisearch - https://www.meilisearch.com - 10,000 free searches/month, then $0.25/1,000 searches.

These are much cheaper than the "full site search engine as a service" services above, but also require more programming (crawler + search UI) to get up and running.

In recent years I've noticed Algolia search on many programming related web-sites (possibly because it is free for open source projects).

I was curious enough that I programmed my own simple crawler (including the CSS query selector trick I learned from SiteSearch360) and tried uploading the data to Algolia - just to get a feel for how all this works.

Once I had extracted the text data (with my crawler) and converted it into JSON, the upload process was simple enough and searching worked very well within the Algolia management interface.

I didn't take this any further, because at this point I realized that the output from my crawler could also easily be fed into other full text search solutions...

Dedicated full text search server software

I had a cursory look at

Apache Solr - https://solr.apache.org
Sphinx - https://sphinxsearch.com

These are open source / free, advanced dedicated full text search server software programs (running on your own server) designed for enterprise searching with thousands of documents.

But I really don't want to run and maintain yet another application on our server (one of my issues with Zoom Search Engine), and they seem like overkill as my largest website only has around 400 documents.

Database server full text search

All the major database servers (Microsoft SQL Server, MySQL, PostgreSQL, MongoDB) include some type of full text search functionality which could potentially be used for site search.

Of course as with the "Full text search as a service" providers, I would need to program my own crawler and search UI.

I already run Microsoft SQL server, so I had a look at the full text search features in this. Unfortunately I couldn't find any easy way to get out "snippets" of the indexed text with highlighting of query terms - which is pretty essential for displaying search results.

As for the other database servers listed above - again - I really don't want to run and maintain yet another application on our server, so I did not consider these further.

SQLite

In recent years, I have been reaching for SQLite in more and more situations where I would have used Microsoft SQL server in the past. SQLite is often both faster and easier to work with.

Turns out that SQLite also does full text search.

And unlike Microsoft SQL Server, it has built in "highlight" and "snippet" functions for generating text for the search result listing.

So combining my own crawler (incorporating the "CSS query selector" trick from SiteSearch360), SQLite full text search, and some existing search UI template/code from my Zoom Search Engine integration, I was quickly able to put together a full site search system - without introducing any new paid services, or any new applications running on our server (SQLite is just a library / .dll file already in use on our web-sites).

Indeed compared to the previous Zoom Search Engine setup, the complexity has been reduced, and I have much better control over the crawling process.

And performance is amazing - searches execute in 1-2 milliseconds.

Notes for using SQLite full text search with .Net

I use the official SQLite NuGet package System.Data.SQLite.Core which includes the full text search functionality (FTS5).
I have read that full text search is NOT included in Microsoft's fork "Microsoft.Data.Sqlite".

Also the full text search functionality is an "extension", which needs to be enabled and loaded (after opening the database connection) by calling:

connection.EnableExtensions(True)
connection.LoadExtension("SQLite.Interop.dll", "sqlite3_fts5_init")

My thoughts on Mithril.js

Jesper Høy — Tue, 03 May 2022 13:21:33 +0000

Mitril.js is a client-side JavaScript framework (similar to React, Vue, Svelte, etc.)

My current go-to client-side framework is Svelte - which is amazing. The only real downside is that it cannot be used without build-tools.

So when I noticed that Mithril.js can be used without any build-tools (plain vanilla JavaScript) AND it has a tiny runtime (10 kB) AND it has real components - I was intrigued.

Having (real) components, sets it apart from other no-build / small runtime frameworks (like Alpine.js and Vue-Petite), because this allows for the creation of advanced full-size SPAs.

Basically Mithril.js covers both scenarios - "progressive enhancement" (like Alpine.js and Vue-Petite) and full-size SPA (like React, Vue, Svelte).

Could this be the one?
The single tool for everything?
The holy grail?

So I played around with Mithil.js over the weekend, to see what it was like.

With Mithril.js, you generate HTML using a hyperscript dialect like this:

m("div", {style:"color:red"},
  m("a", {href:"/page2"}, "click here"))

which generates

<div style="color:red">
  <a href="/page2">click here</a>
</div>

Alternatively, you can use JSX syntax (like with React), but then you need build-tools.

Another option is using the htm library to generate the hyperscript - which would allow the use of JavaScript template literals for a development style closer to JSX or the HTML templates used with Vue / Svelte.
The problem with this is that the templates would be re-compiled (by htm) on every single interaction with the app - which I imagine would seriously slow things down.

So the way I see it, the optimal way to use Mithril.js (without build tools) is to write the hyperscript style code by hand - which actually isn't too difficult once you get used to it.
The biggest problem is keeping track of closing parentheses/brackets with deeply nested elements.

Reactivity / UI updates

Unlike the major frameworks (Reach, Vue, Svelte, etc.) Mithril.js does not update the UI in response to changes in application state / variables.

Instead, it updates the UI after each UI event has been handled (or whenever you tell it to by calling m.redraw()).

On each update it re-renders everything to a new virtual DOM, then diffs this to the previous version, and finally updates the real DOM with the differences.

This works surprisingly well. Dynamic and automatic UI updates - without any kind of state tracking. Very nice!

Test project

I recently created a small SPA with Svelte here: https://simpledns.plus/dmarc-wizard (an in-browser tool to generate DMARC-records - an e-mail security thing).

So to try out Mithril.js, I re-created the same SPA using Mithril.js - see https://simpledns.plus/dmarc-wizard-mithril (should look and work exactly the same).

The JavaScript source code (which is also the production code) is available at https://simpledns.plus/scripts/dmarc-wizard-mithril.js

Things that I really like

Ability to cover both "progressive enhancement" and full-size SPA scenarios (see above).
That no state management system is needed / included (see above).
Everything, even HTML, is expressed in plain JavaScript. No "magic". This makes debugging in the browser much easier, makes code refactoring easier, and reduces the need for VSCode extensions etc.
The possibility of using tiny render functions, for things that would require a separate a component (and file) in Svelte. This encourages and makes it a lot easier to be adhere to the DRY principle (don't repeat yourself).

Things that really should be removed

Mihtril.js (v. 2.0.4) includes a wrapper for ajax calls based on XHR. They even make a selling point out of this in the very first sentence on the web-site.

This is 2022 - all browsers now have fetch, and support async/await making fetch easy to use.
Promoting XHR as a feature makes it sound rather outdated.
And I would rather have an even leaner base framework.
Mithril.js also includes a routing feature based on "hash-bang URLs" - also a selling point in the first sentence on the web-site.

This is of course nice to have - but routing is not needed for progressive enhancements scenarios (where I see Mithril.js having potential), and developers might prefer other routing schemes (like non-hash history-push/pop).
So please remove this / make it optional (making the base framework even leaner).
Mithril.js includes a polyfill for Promise.

This is 2022 - all browsers now support promise.
So please remove this / make it optional (making the base framework even leaner).

Conclusion

Mithril.js has some really nice and unique features.

But, while the hyperscript syntax is doable for small widgets, I wouldn't want to use it in larger projects.

I just don't think that the hyperscript syntax is as readable as for example Vue / Svelte templates (standard HTML with as few additions).

And keeping track of those closing parentheses/brackets with deeply nested elements, just drove me nuts.

As the JSX docs put it (about something else, but with the same issue):

Unfortunately, the balanced braces do not give great syntactic hints for where an element starts and ends in large trees. Balanced named tags is a critical syntactic feature of the XML-style notation.

So to use Mithril.js, I would probably need JSX, which requires build tools. And if I have to use build tools anyway, then I still prefer Svelte...

Tasty Vanilla JS - 4 tips

Jesper Høy — Thu, 21 Apr 2022 09:20:31 +0000

[Definitions: "Vanilla JS" = plain old JavaScript with no framework, and no build tools etc., "Big-framework-X" = React, VueJS, Angular, Svelte, etc.]

When building light weight interactivity on a webpage, I often find myself in this space between doing it in Vanilla JS or pulling out my big-framework-X of choice.

Mini-frameworks like AlpineJS, Vue-Petite, and Stimulus exist exactly to fill this space.
But whenever I consider reaching for one of these, I usually find that the job can just as easily be done in Vanilla JS. And if it can't, it typically requires the big-framework-X anyway.

Vanilla JS is of course much simpler, ships less bytes to users, and consumes fewer CPU cycles from user devices. And with Vanilla JS my development setup is much simpler too (no npm, bundlers, build-tools, etc. needed).

Here are 4 small tips that might make you choose Vanilla JS more often:

Tip 1 - Use element IDs directly in JS code

When big-framework-X code is compared to vanilla JS, you will often see the vanilla JS sample code littered with document.getElementById(...) or document.querySelector(...) statements (making the Vanilla JS version look bloated). This is pure propaganda. There is no need for this. For simple stuff (where you would typically use vanilla JS), you can just reference HTML elements using their IDs directly in JS:

<input type=checkbox id=MyChk1>

<script>
  MyChk1.checked = true;
</script>

Tip 2 - Use "hidden" for conditionals

One reason that you might use big-framework-X is conditionals - some syntax which renders a section of HTML to the DOM - or not - depending on some condition. A simple Vanilla JS alternative to this is the "hidden" attribute / property. To show/hide a div (and its content), you can simply do this:

<div id=MyDiv1 hidden>...</div>
<div id=MyDiv2>...</div>

<script>
  // swap which divs are visible
  MyDiv1.hidden = false;
  MyDiv2.hidden = true;
</script>

Tip 3 - Template Literals

Another reason that you might use big-framework-X is templating (like React's JSX or Vue's SFC). Vanilla JS actually comes with a powerful templating system called
template literals, which can be utilized in much the same way.

<div id=MyDiv1></div>
<script>
  let Title='Shopping list';
  let Items=['Apples','Bananas','Dog food'];
  MyDiv1.innerHTML=`<h1>${Name}</h1>
                    <ul>
                      ${Items.map(itm=>`<li>${itm}</li>`).join('')}
                    <ul>`;
</script>

Tip 4 - Inline event handlers

You may have been taught that inline event handlers are bad, and that you need to use element.addEventListener(...) instead. You will often see this when big-framework-X code is compared to vanilla JS (making the Vanilla JS version look bloated).
Once again, this is pure propaganda. For simple stuff (where you would typically use vanilla JS), inline event handlers are perfectly fine, much simpler, terse and readable.

<div id=MyDiv1>...</div>
<input type=checkbox onclick="MyDiv1.hidden=this.checked">

Combining all 4

I re-created the obligatory (for big JS frameworks) To Do List application in Vanilla JS combining above techniques:

Fully functional, yet simple and short, and it can easily compete with big-framework-X.

Deep reactivity in Svelte

Jesper Høy — Thu, 17 Feb 2022 15:35:01 +0000

What is "deep reactivity"? you ask.

From the Vue.js documentation:

In Vue, state is deeply reactive by default. This means you can expect changes to be detected even when you mutate nested objects or arrays

In Vue.js, when using the data option or the reactive() function, a JavaScript object is transformed into an object where each individual property (including those on nested objects) is reactive. Each property in effect becomes its own "store".

In Svelte, there is no way to make object properties reactive like that. Reactivity is only available for local variables declared at the root level of each component.

A reactive "store" from outside the component, must first be assigned to a local variable, and then the store value can be accessed/assigned using a "$" prefix on the local variable.

Most of the time, the Svelte's reactivity model is entirely sufficient and very easy to use.

However, if you need to synchronize a large/complex JavaScript object between multiple components, views, etc. the Vue model is much more convenient.

To "fix" this, I came up with a tiny helper library "ReactivePojo", which brings "deeper" reactivity to Svelte - similar to Vue.

ReactivePojo lets you map a local variable in a Svelte component, to a property on any POJO (Plain Old JavaScript object) - via a custom store (honoring the Svelte store contract) - like this:

let v = RPStore(object, propertyName);

The property value can then be accessed/assigned using the Svelte "$" prefix syntax:

console.log($v);
$v = "New value";

Calling RPStore will create a store for the specified object/property - unless one already exists, in which case the existing store is returned. In other words - any call to RPStore for the same object and property name, from anywhere, will always return the same store.

This ensures that two separate Svelte components accessing the same object/property will get the same store and thus the property value will automatically be synchronized between the components (and the underlying object).

The first time RPStore is called for an object/property, the property will be instrumented with getter/setter methods, so that any subsequent assignments directly to the property will also trigger reactivity - ie. subscribers to the store will be notified - and any UI using the store will be updated:

let v = RPStore(Person, "Name");
$v = "Bob"; // triggers reactive updates where $v is used
Person.Name = "Joe"; // also triggers reactive updates where $v is used

This is very similar to the way Vue 2 does reactivity (Vue 3 uses a different technique).

To use this library in a Svelte component:

<script>
import RPStore from "./ReactivePojo.js";
import {Person} from "./MyGlobalData.js"; 
// Note: "Person" object could also come from a property, GetContext(...),  etc.
let Name = RPStore(Person, "Name");
</script>

Name: <input type="text" bind:value={$Name} />

This solution gives you reactivity at a more granular level (like with Vue) - preventing re-calculations/re-rendering based on the entire object when the value of some leaf node property changes.

And just like Vue, it kind of magically makes a POJO reactive.

It is actually more efficient than Vue, because it only adds reactivity to specific properties, rather than traversing and instrumenting every single property in the entire object tree.

"ReactivePojo" is available at https://github.com/jesperhoy/Svelte-ReactivePojo

Custom validity helpers for Vue.js and Svelte

Jesper Høy — Thu, 22 Apr 2021 15:32:15 +0000

HTML5 comes with a nifty feature to show custom form validation messages on form submission (see cover image).
This looks different in each browser/OS - but it is a standard HTML5 feature, fully supported in all modern browsers.

This is easy enough to use through javascript:

element.setCustomValidity('That is the wrong name!');

But when using a front end framework like Vue.js or Svelte, this means that we first need to get a reference to the DOM element and make sure that the element is mounted before executing above javascript.

Wouldn't it be nice if this could just be set as an attribute directly on each input element?
Something like this:

<input validity="That is the wrong name!" />

Here's how you can do just that:

Vue.js

Run before loading your app, to make this globally available:

Vue.directive('validity', function (el, binding) {
  el.setCustomValidity(binding.value?binding.value:'');
})

In a Vue component (.vue file):

<template>
  <input type="text"
         v-model="name" 
         v-validity="name!=='joe'?'That is the wrong name!':''" />
</template>         

<script>
  export default {
    data: function () {
      return {
        name: ''
      }
    }
  }
<script>

Svelte

In a "shared.js" file:

export function Validity(node, val) {
    if(!!val) node.setCustomValidity(val);
    return {
        update(newVal) {
            node.setCustomValidity(newVal?newVal:'');
        }
    };
}

In a ".svelte" component file:

<input type="text"
       bind:value={name}
       use:Validity={name!=='joe'?'That is the wrong name!':''}>

<script>
  import {Validity} from './shared.js';
  let name='';
</script>

Svelte vs. Vue.js

Jesper Høy — Thu, 22 Apr 2021 11:15:37 +0000

Updated February 18th 2022 to reflect new features of Vue 3 and stuff I've learned from experience in the meantime.

I have been using Vue.js for client side browser stuff for a few years and I am very happy with it. However, I have been curious about Svelte for a while, and as I had an idea for a new project where Svelte might be a better fit than Vue, I decided to take a closer look.

Also, I have a number of ongoing projects in Vue 2, and with the significant breaking changes in Vue 3,
now might be a good time to explore alternatives,
as moving to a different framework might not be much more work than the Vue upgrades that I am facing anyway.

The following is based on my own experience with Svelte and Vue:

In favor of Svelte

No runtime

The Vue runtime is not that big, but still significant for smaller "apps".

Consider, for example, the code to validate a simple contact form. Here the Vue runtime would be disproportional huge for the functionality provided.

Small Svelte apps compile to just a few kBs and need no runtime.
Two-way property binding

In Svelte this is simple (bind:propname={variable}) which I found very convenient. In Vue.js it requires emitting events and more code.
Terser and more readable attribute value binding

With Svelte, you can interpolate dynamic values anywhere in an attribute value using {...}:
```
<a href="/items?type={varType}&page={varPage}">
```
With Vue.js, the attribute name must be prefixed with v-bind: or : (shorthand), and the entire attribute value is then evaluated as JavaScript:
```
<a :href="'/items?type=' + varType + '&page=' + varPage">
```
Simpler to declare reactive variables

In Svelte you simply declare a variable in the script root (like let x=0) and it is automatically reactive.

In Vue, for a variable to be reactive, it must either be defined as a property on the data object (Options API), or be created using the ref() or reactive() function (Composition API).
Simpler to declare props

In Svelte you simply declare a variable in the script root and prefix it with export (like export let x=0).

In Vue, to make a component property, you need to define it as a property on the props object (Options API), or through the defineProps() method (Composition API).
$: label

The Svelte $: label makes the following script block re-run anytime a reactive variable used within that block changes.

This is similar to Vue computed and watch blocks, but simpler, more convenient, and much terser syntax.
Raw html rendering not tied to an HTML element

Svelte: {@html HtmlString}

Vue: <div v-html="HtmlString"></div>
No this. this. this. / .value .value .value

Unlike Vue, in Svelte you don't need to prefix everything with this. in code blocks to get at anything else within the same component.

This is also a constant cause of errors in Vue for me. Template in-line script does not need this, and so whenever you move code between template and code blocks and forget to fix this - boom.

In Vue 3, if you use the Composition API, you can avoid this. inside the "setup" function. But you still have to qualify access to reactive variable values like Refs - so this.VarName becomes VarName.value - not much better.
Performance

Svelte is faster at updating the UI - supposedly because it doesn't use a "virtual DOM" (like Vue, React, Angular, etc.).

Using browser performance tools - the measured difference is significant.

Without such tools - it is hard to tell the difference - Vue is certainly fast enough.

I imagine this being an advantage when coding for low powered devices.

In favor of Vue

"Deep" reactivity

In Vue.js, when using the data option or the reactive() function, a JavaScript object is transformed into an object where each individual property (including those on nested objects) is reactive. Each property in effect becomes its own "store".

This is very convenient and simple to work with.

In Svelte, variables declared at a script block root are reactive (based on assignment) and so are explicitly defined "stores". But it is not "deep", meaning that assigning a value to a leaf node on a larger object, will trigger re-calculation/re-rendering based on an assumption that the whole object changed.
Client side template compilation

Smaller Vue "apps" can be included as source on a web-page directly without any pre-processing / build tools.

For web-pages (not "apps") where you need just a little bit of reactivity (like order forms), this is perfect.
No need to run a compiler/bundler etc.

Another cool thing about this is, that it allows you to put dynamically server side rendered html/data directly inside a Vue template, mixing server and client side processing very nicely.

I have personally used this quite a lot, and the beauty of this was exactly the thing got me started with Vue in the first place.

There is a special version of Vue optimized for above scenario - Petite-Vue. Another similar option for this is Alpine.js.

This is not possible with Svelte. Svelte apps must always be compiled with a build tool.
Ecosystem

Vue is more established and enjoys a much larger selection of component libraries, StackOverflow answers, blogs posts, etc.

Tie

Single file components (SFC)

Both have this - which is just awesome.
Great documentation web-sites

Both have this.
Zero indentation / no curly brace mess

In both Svelte and Vue, you can write code at zero indentation enclosed by no curly braces, making code clean and easy to read.

Vue 2 required at least 2-3 levels of indentation before you write any actual program code, but this was "fixed" in Vue 3 with the <script setup> feature.
Multiple root elements in components - a.k.a. "fragments"

Both support this.

In Vue 2, you could only have one root element, but this was "fixed" in Vue 3.
Browser DevTools

Browser (Chrome/Firefox) "DevTools" are available for both Svelte and Vue.js, and with both tools, you can browse the live component hierarchy and see and change component property values.

Bundle size matters

Bundle size for small apps in certainly smaller with Svelte because there is no runtime.

But the bundle size grows faster for Svelte apps than for Vue apps - because the Svelte compiler adds stuff to the code (mainly for reactivity), while with Vue, code is largely left as is.

It appears that at some point around "medium sized" app, compiled Svelte apps could become bigger than Vue apps including runtime.

I recently did a small SPA (Danish budget calculator) based on Vue, and figured that it would be a nice test to convert this to Svelte.
I copied the .vue files to a new Svelte project, renamed the files .svelte, and then manually massaged them into the Svelte syntax.
The source code (Vue + Svelte) is available at: https://github.com/jesperhoy/Mit-Budget.dk

Minified and gzipped, the javascript for the original Vue version (https://mit-budget.dk/vue) is 9.2kb + 23.6kB Vue runtime = 32.8kB total (Note: this was based on Vue 2 - the Vue 3 runtime is significantly larger).

The Svelte version (https://mit-budget.dk/svelte) is 19.2kB.

Conclusion

Rich Harris asked the Marie Kodo inspired question "Does this code spark joy?"

Back when I discovered Vue - this really was a game changer for me - and it did spark a lot of joy :-)

I imagine many programmers feel this way when they first "get" the reactive UI model (be it in Vue, React, Angluar, etc.).

Vue still sparks joy, but Svelte does so even more :-)

I especially like the simpler and terser Svelte syntax, and not having to distribute a runtime.

Simple Deploy

Jesper Høy — Mon, 12 Apr 2021 11:33:00 +0000

Today I launched a new open source project "Simple Deploy" - an IIS webhook endpoint for GitHub / GitLab / BitBucket for easy web-site publishing.

I created this in order to simplify our own web-site publishing workflow, as I couldn't find any existing solutions like this - at least not anything very user friendly.
Prior to making Simple Deploy, I used the excellent Bonobo Git Server with a hook to checkout each repository when pushed.
This worked quite nicely, but meant that our web-servers doubled as Git servers, and that our Git repositories were scattered in several different places.
I wanted a setup where all our Git repositories were in a single and separate location (GitHub) - both for simplicity but also as an extra backup.

See https://simpledeploy.dev