Reactivity News #11

Repost of Reactivity News April 2021 edition, my Svelte focused newsletter

· 5 min

It's first Monday of the month! This issue's topics are SvelteKit, Deno and writing reactive SSR apps without JavaScript, but first things first.

Svelte Trunkpermalink

Svelte had two new releases last month. Incredible pace with no signs of slowing down. Feels like we might go places soon, peeps!

https://github.com/sveltejs/svelte/blob/master/CHANGELOG.md

Sapper Trunkpermalink

Some commits in the Sapper repository, but no releases last months. I don't expect any either. Better to channel this energy into SvelteKit.

https://github.com/sveltejs/sapper/blob/master/CHANGELOG.md

SvelteKitpermalink

SvelteKit is finally here! Although in Beta, but at least we can study the source code. I can't find the source, but I read that Svelte crew had to make the Github repo public because they run out of quota on the Github actions. That's quite funny if true.

Svelte community is currently bubbling with excitement and some brave souls have already ported their apps from Sapper to SvelteKit.

There is no official changelog yet, but you can follow the progress towards 1.0 on Github. My prediction is that it will be sometimes at the beginning of summer, but I've been wrong before.

SvelteKit is all about adapters, but it's hard to know what adapters are available at the moment. There are official ones and others built by the community.

Another way to adding new functionality to SvelteKit is by using svelte-adders. Check it out!

One of the major underlying changes to SvelteKit is the switch from Snowpack to Vite 2.0. In my last newsletter I posted a link to a secret repo on Github that I found by accident and that involved Svelte and Vite. I guess that was some kind of POC. This pull request explains the motivation for the switch.

Personally, I will wait with migration as my Sapper app is written in TypeScript and uses Auth0 Express middleware. None of the things SvelteKit currently supports. Auth is currently the biggest unknown, because SvelteKit is true serverless framework and normal things don't (yet) work.

I also see that people also started blogging about SvelteKit. Here is an good one How to Build a Website with Svelte and Sveltekit.

Denopermalink

I've been closely following the development of Deno. I like its mascot a lot, but what I like the most is its approach to imports. I believe we are currently in the middle of a paradigm shift when it comes to package imports. My guess that NPM will become less relevant in the near future and decentralization will take over. Snowpack already supports this with its streaming imports and my guess that more will follow.

There are a lot of 3rd party packages and frameworks available for Deno https://deno.land/x

Yep, Svelte is there too. https://github.com/crewdevio/Snel

One big unanswered question is how to run Deno apps in the cloud. Heroku supports Deno, but there is also Deno Deploy as an option from the creators of Deno and the company behind it.

Reactive apps without JavaScriptpermalink

Some time ago I tweeted: SPA = your users pay for rendering, SSR you pay the rendering cost. I quickly got reminded that this cost is nothing compared to code maintenance and the cost of duplication of the models on the client and the server. While using solutions like Firebase or GraphQL might ease the pain, but they will not make it go away.

I like Svelte simply because it fits in my head and also because it has a great DevX. But if we take a big step back and look at our app objectively, we will most likely discover code and complexity not directly related to the apps's functionality per se. Like code bundling or state management for example. Be honest, how many times did you pick a fight with your bundler lately? What about all the time you spent trying to keep TypeScript compiler happy? Also, are you sure that you picked the right state management library for your project? The new one that was released yesterday seems much better. Maybe you should switch to it? The complexity, FOMO and yak shaving is real in the frontend world, folks.

The answer to this on everybody's lips seem to be SSR. It's all the rage at the moment, no matter what problem you have at hand. But wouldn't it be cool if you could build reactive SSR apps, but in a much better way and (almost) without writing any JavaScript?

This thought-provoking The Future of Web Software Is HTML-over-WebSockets article really got me thinking. What if?

The article makes a few interesting points:

  • The internet is getting faster and users expect near real-time experience
  • Websockets are much faster than Ajax calls because you are already connected
  • Why send over only data when you can instead send DOM diffs and patch the DOM in the client side?

The statements got me curious and down the rabbit hole I went. Now, I wouldn't use Rails (again), but I got really impressed by Elixir and its Phoenix web framework that offers the same functionality with its LiveView feature that the article mentions.

Watch this keynote by the Phoenix author - Phoenix LiveView - Interactive Apps without Javascript to see what I mean.

The DOM patches Phoenix sends over the wire (or websockets) are ridiculously small thanks to smart architecture and the use of Morphdom library.

The most beautiful part is that you barely have to write any JavaScript. You get the reactivity for free with smart DOM patching. Mind blowing!

If the talk got you curious I suggest you watch The Soul of Erlang and Elixir by Saša Jurić next. It explains well what makes Elixir so special compared to other languages and runtimes.

After that you can read these three short(ish) articles:

I've been learning and experimenting with Elixir and Phoenix for that past month and I can't stop. It was long time ago I had that much fun while feeling productive at the same time. Crazy!

Even if you don't plan on using Elixir I suggest you give it a fair chance. It's always healthy to expand your views. Elixir is a functional programming language and it will for sure influence how you write your JavaScript code for the better. A good starting resource is the free and short online book - The Joy of Elixir. Great storytelling too!

Oh, and if you want to use Svelte with Phoenix, you can. https://github.com/virkillz/sveltex

Other noteworthy thingspermalink

TypeScript Poll

I did a TypeScript poll on Twitter a while ago where I asked if people use TypeScript in their Svelte projects. I was truly surprised by the answers. Turns out that majority of people do. Not by a lot, but still. The feelings are however mixed. Maybe the YES/NO poll options were too binary. After all, I also use TypeScript, but only for non-Svelte files.

However, in my recent personal apps I've dismissed TypeScript completely as I feel that it brings little gain and more pain. I feel more comfortable with dynamic nature of JS I guess.

Mint

There is a lot of fragmentation going on in JavaScript land today. You literally can accomplish the same thing choosing one of the 1001 libraries available. Ever needed to have state management and searched for the best option? Good luck deciding!

Elm is the most known language that makes all those hard decisions for you, but looks like its development has stagnated a bit.

Recently I re-stumbled on Mint, a language designed for writing single page applications, in this post on StackOverflow blog. Will it become a game changer or not? Time will tell.

Bad Joke of the Monthpermalink

Q: Why do French eat snails?
A: They don't like fast food

Want to get this newsletter directly in your inbox? Subscribe at reactivity.news.


If you liked what you read, it would make me really happy if you could share it on Twitter.