Reactivity News #11
Repost of Reactivity News April 2021 edition, my Svelte focused newsletter
Svelte had two new releases last month. Incredible pace with no signs of slowing down. Feels like we might go places soon, peeps!
Some commits in the Sapper repository, but no releases last months. I don't expect any either. Better to channel this energy into SvelteKit.
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.
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.
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.
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.
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.
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.
The DOM patches Phoenix sends over the wire (or websockets) are ridiculously small thanks to smart architecture and the use of Morphdom library.
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:
- The Future of Web Development
- Elixir and Phoenix after two years
- I finally escaped Node (and you can too)
Oh, and if you want to use Svelte with Phoenix, you can. https://github.com/virkillz/sveltex
Other noteworthy things#
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.
Elm is the most known language that makes all those hard decisions for you, but looks like its development has stagnated a bit.
Bad Joke of the Month#
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.