I’ve had a personal domain since 2007 and tested many frameworks and self-host solutions. Most of them were based on C++, PHP, Python, GO, and JS. Believe it or not, back in 2005-2006 it was popular to write web apps using a system language like C / C++ and use a (CGI) Common Gateway Interface to execute compiled programs. In fact, PHP was inspired a lot by C, as it first wanted to be just a templating engine for C. I didn’t touch PHP for a few years, even though I used most PHP frameworks, but yeah, I had these apps also written in Laravel, the idea is that I mostly migrated, even if I changed the tech stack.

It's interesting to see the web ecosystem evolving for so many years, right now at least for these two apps I am pretty happy with SvelteKit, I see the WebAssembly has really taken off, and every day we’re closer to ditching Javascript necessity when implementing a web app, so we’ll go full back circle, but instead of transferring output from a compiled app, we’ll compile any language we want to WebAssembly bytecode which will be in a performant way evaluated by the browser.

Still, I thought we would reach this point faster, but for most cases, especially if we don’t have apps that run into millions of users, it’s not worth it to leave completely the JS ecosystem.

Anyway, so I migrated to the latest Svelte 5 and SvelteKit 2.2x, also I used the newest syntax everywhere, even though Svelte 5 can still execute old syntax, but what would have been the point of migrating if I didn’t use newer syntax?

I really think that SvelteKit is great, the developer experience and the performance are incredible, so few deps, so few primitives, and there’s absolutely no bloat, yeah you need to implement a lot of things from scratch, but I implemented many things from scratch, and generally even if is hard to reach feature parity with other established solutions, you can improve the performance a lot.

I’ve been watching all these JS meta-frameworks, and they all evolved pleasantly, I mean server components, boundaries, SSG, SSR, SPA, support for serverless-edge, and for most JS runtimes.

Nowadays I mostly use Bun, which seems like the most satisfactory and can replace other things that I had to use in the past, for example, tsx and tsc, yes I haven’t used naked JS for a long time, and I haven’t seen why would you not use Typescript, I know that there was some discussion last year with some heavy devs that berated TS, mainly for the convoluted type system, but everything has improved and I hope the GO rewrite of typescript to arrive as early as possible, though some people think it will be some years until that’s brought to production.

For this update, I was mostly focused on bringing the repos up to date with the latest SvelteKit tech, optimizing, and adding some light features I needed here is the list of what I did.


Front App


- Updated and migrated to the latest SvelteKi & Svelte, Tailwind (4.x.x no PostCSS just command line for better performance), and the rest of the dependencies
- Restructured components and structure for index, added a few components, changed content and design
- Changed default OG, added some config vars
- Reimplemented a Deno script that uploads many PDFs and exposes them from Mega.nz is used in the courses(/cert endpoint)
- Deleted all Netlify native edge functions and opted for reimplementing the code using svelte-kit API
- Better links between the blog app and front app & added a bunch of new icons
- Minor changes to Cert sub-app displaying images
- Changed the menu for the Cert and Projects sub-apps
- Ditched self-host Gitea links (even though I like Gitea I think I’ll just mirror some repos on community Gitlab since I could use the resource that I use now for Gitea for something else)
- Fixed a bug with GitHub contribution links (it was probably because GitHub changed links on their website to use relative links and not absolute ones like before, so added a regex to recreate absolute links)

Blog App

- Same, updated and migrated to the latest SvelteKi & Sveltet, Tailwind (4.x.x no PostCSS just command line for better performance), and the rest of the dependencies
- Committed some old code with farcaster frames that should be reimplemented as specs have changed and I committed it incomplete which may generate some bugs
- Added a tip me page that links to fiat and crypto payment processors since there was a user of one of my extensions that wanted to donate to me something and it didn’t have a way to do that
- Added a mobile menu
- Added a desktop menu
- Design changes
- Enabled 0xEcho comments, I never had them enabled but I implemented them about a year ago, I thought that service would disappear but I was shocked when I saw it still works, though no update was made to their repo for 2 years, in fact I did reverse the change because they don't work always I'll probably use gDiscuss in a new update


These apps together have risen to around 31k monthly unique visitors, still pretty low, but I only wrote on the blog two articles last year, I am trying to put some more this year even if they aren’t super high quality.

In all fairness, I did write in other places too, and I didn’t copy here, but I’ll probably try to do that sometimes.

The source code of the blog app is available on github but not updated, will probably update it soon and also include additional features.

Tags

Related Articles

Simple Proxy for puppeteer extension
Simple Proxy for puppeteer extension rewritten

I have an extension that controls the proxy of a browser. Before the rewrite, it was pretty slim, written in plain Valina JS, and I didn't touch it for three years. But manifest V3 will be mandatory as of June this year, so I rewrote it. It took me a few hours...

Read more
Pitfalls of securing SPA without backend
Pitfalls of securing SPA without backend

The only perceivable reason to want to secure a SPA without a backend is to avoid costs as much as possible. Securing without a backend is an almost impossible task. But still, you can secure some parts using browser encryption before building and deploying.An...

Read more
Semi-open Github Repos
Semi-open Github Repos

If you ever had a repo and didn't want to set it completely open, then you didn't have many choices. For example, Gitlab at least lets you have a public repo with private code, but this isn't a thing for Github.So I thought of a simple system where you have a ...

Read more

EVM Signature

Comments

Loading comments...