
How I made a website with Svelte - Wolfr_
https://johanronsse.be/2019/12/28/making-of-best-of-2019/
======
cytzol
> What I like about these foundries is that they have permissive licenses that
> are just a one-time purchase. When I make a website I don’t want to worry
> about the font licensing for years.

I love the work of professional typographers, but tend to stay away from
commercial Web fonts, because they like to include _very restrictive terms_ in
the font licences.

For example, you're only allowed to back up Klim fonts once, which we all know
is no backup at all ([https://klim.co.nz/licences/web-
fonts/](https://klim.co.nz/licences/web-fonts/)):

> You may make one (1) copy of the Web Fonts for back-up purposes only.

And I hope you don't take a week-long holiday away from your computer:

> At Klim’s request, You agree to provide an audit to confirm the Web Fonts
> You are consuming match Your Sales Receipt. Klim will give You at least 5
> business days’ notice to complete the audit.

The Commercial licence is a bit better, but doesn't let you subset the fonts,
which means your fonts might be 5 to 10 times as big as they should be, giving
your users a worse experience
([https://commercialtype.com/licenses/web](https://commercialtype.com/licenses/web)):

> 10\. You may not modify, adapt, translate, reverse engineer, decompile,
> disassemble, or alter, the Webfonts, the Font Software or the designs
> embodied therein.

I recommend using fonts under the SIL Open Font License, where you don't have
to worry about this crap.

Anyway, nice work! I've been meaning to learn Svelte, and your site looks
really good.

~~~
spectramax
I really appreciate the amount of work that goes into making a font. On one
hand, these typographers and their foundries are _starving_ for revenue and on
the other hand they make the customer's professional life incredibly difficult
with the retrictions that you mention.

Most small foundries have been bought out by Monotype and their licensing is
now 100% subscription only. I was lucky to have purchased Univers and a couple
of other fonts under their "Creative" license which bundled everything under a
reasonable price.

Font foundries - listen up, if you want people to pay for your fonts, make the
licensing model straight up simple - download fonts and off you go. Turns out
that most people that are willing to pay for your font arent the ones trying
to pirate them. Stop fucking them over.

~~~
ljm
There have been a few fonts I was interested in until I saw the several-
hundred dollar bill and the license that basically restricted any useful
application of the font. No wonder why startups commission their own fonts
these days, so they can own them.

Typography and calligraphy is an art form so it does justify the expense, but
you've got to be able to actually use it.

------
paulddraper
[https://svelte.dev/](https://svelte.dev/)

> Svelte is a radical new approach to building user interfaces. Whereas
> traditional frameworks like React and Vue do the bulk of their work in the
> browser, Svelte shifts that work into a compile step that happens when you
> build your app.

> Instead of using techniques like virtual DOM diffing, Svelte writes code
> that surgically updates the DOM when the state of your app changes.

That sounds like a perfect pitch for Angular. What's the difference between
Svelte and Angular?

~~~
Wolfr_
The difference is that Svelte is pre-compiled while Angular will put templates
through the renderer while building up the page.

~~~
IggleSniggle
Angular has been pre-compiled for years. The AOT compiler has been available
since Angular 2, released in 2015. It has also been able to produce stand-
alone native web-components since 2018, btw.

It's only recently that it started producing multiple packages simultaneously,
however (to serve up a package optimized for the client's web platform).

~~~
ricardobeat
Most modern frameworks can be AOT compiled in that sense - React, Vue, Riot -
they load JS code only at runtime, but still use templates (VDOM, strings or
another representation) as blueprints to update/manipulate the DOM. AFAIK
Angular still uses dirty checking; Angular Ivy, yet to be released, will move
to something a little closer (incremental-dom), but still not the same.

What Svelte does is precompile the UI update code[1], changing text nodes,
attributes, children, targeting DOM nodes directly. Think Prepack[2] vs DOM
diffing.

[1] [https://svelte.dev/repl/hello-
world?version=3.16.7](https://svelte.dev/repl/hello-world?version=3.16.7)

[2] [https://prepack.io/](https://prepack.io/)

~~~
paulddraper
> Think Prepack

Angular compiler is certainly an optimizing compiler.

> Angular Ivy, yet to be released

Ivy became an opt-in feature of the Angular CLI earlier this year with Angular
v8.

> AFAIK Angular still uses dirty checking

Ivy uses "dirty checking" too [1]. AFAIK Ivy and pre-Ivy operate on similar
fundamental principals, which is why Ivy is a drop-in replacement.

[1] [https://indepth.dev/what-every-front-end-developer-should-
kn...](https://indepth.dev/what-every-front-end-developer-should-know-about-
change-detection-in-angular-and-react/)

------
Wolfr_
Every year I make an end of year project where I try some new technology. This
year I made my project with Svelte. It's a list of the best albums, films,
series etc. according to me.

~~~
flanbiscuit
Nice write-up.

I followed the link to the css framework you used/developed, Ygdir, and I am
not sure I understand it. Is the website a work in progress? Feel like it
needs to explain with more details and examples what you mean by "convention-
first". I agree what you said about utility first css but I'm not sure what
makes Ygdir better

[https://ygdir.dev/](https://ygdir.dev/)

~~~
sibeliuss
Wolfr_- Just read over ygdir and wondering: We've had such phenomenal success
with [https://styled-system.com/](https://styled-system.com/) across our team
that I'm wondering if your adversity to utility-first CSS might be due to
misuse in some way? Utility first is largely to build primitive abstractions
that expose narrow constrains for developers building UI. It's the opposite of
complexity due to the fact that it reduces options. _But_ if the utils are
incorrectly spread all across your codebase and not constrained to primitives
then indeed it could be a mess.

~~~
csande17
I'm not Wolfr_, and I haven't used that React-based library you link, but I
have seen tailwindcss.com -- which, as far as I've heard, is one of the
flagship "utility-first" CSS libraries -- used in medium-to-large scale
projects.

The problems I've seen with Tailwind in these projects are:

\- Elements end up with messy, non-semantic class name strings like "m-4 mt-0
p-3 rounded bg-blue". This makes it much harder for non-technical teams to use
out-of-the-box SaaS solutions for things like interaction tracking and A/B
testing. (These apps often use element class names under the hood, so if you
use Tailwind and change a CTA from rounded to very-rounded, the marketing guy
will discover two weeks later that all his click-through metrics are wrong.)

\- References to the utility classes wind up scattered in thousands of
unrelated places in the codebase, making refactoring and changes to the CSS
impossible. Like, if you ever wanted to remove the p-3 class (or change how
much padding it represented), it would be almost impossible: you'd have to
individually find and test/change all 9000 use sites, a task which is made
even more difficult when developers write things like class={`p-${first ? 4 :
3}`}. At least one website I know is stuck on Tailwind 0.x pretty much
indefinitely for this reason.

\- Whenever you add a new color or padding amount or anything, you pay the
full cost of generating all the variations (p-7, pt-7, bigscreen:pt-7, etc) up
front in a CSS file that needs to be loaded before anything on the page can be
rendered. (Sure, Tailwind might not generate 50K of variants when you add a
padding value out-of-the-box, but once you've set those options it's
impossible to un-set them because of the above point.)

This eventually leads to a codebase where no one wants to add, remove, or
change CSS classes for fear of breaking something unrelated or destroying
performance. In other words, it makes your CSS impossible to maintain.

~~~
vosper
> \- Elements end up with messy, non-semantic class name strings like "m-4
> mt-0 p-3 rounded bg-blue". This makes it much harder for non-technical teams
> to use out-of-the-box SaaS solutions for things like interaction tracking
> and A/B testing. (These apps often use element class names under the hood,
> so if you use Tailwind and change a CTA from rounded to very-rounded, the
> marketing guy will discover two weeks later that all his click-through
> metrics are wrong.)

IMO the problem here is tools trying to use CSS for something it’s not
designed for. They advertise themselves as not requiring technical knowledge
to use, but they’re selling a lie. Unless the marketing guy understands the
structure of the site and the CSS there’s no way for him to be sure he’s
tracking the thing he thinks he’s tracking - unless you’re instrumenting the
CSS to help him out, and are committed to not doing anything that would break
one of his selectors (or change its meaning, or reuse it for something else -
and are you sure you know all the selectors he’s using, and that the automatic
selectors the tool is creating are actually doing what he intends?).

Data attributes are probably the solution here, then CSS can be reserved for
its intended use: controlling styles. But then the tooling needs a way to
target those attributes automatically, otherwise you’ve “broken” the “no
technical knowledge required” sell of the software they already licensed
(without asking you for input...)

------
reaperducer
I'm afraid I honestly don't understand. What was the reason for using a bunch
of frameworks and JavaScript for what appears to be a super simple web site? I
don't see anything that couldn't have been done in plain static HTML and CSS.

Is there some functionality on the pages that I'm missing?

~~~
Bob312371
How else do you explore frameworks? Do you wait until you have some massive
project with financial and time constraints and then test it out on that?

This sort of site is a perfect testbed for such a framework.

~~~
83hajfjeijg
No, you make a small web app. It doesn't have to be a big project, but it
should be something that benefits from what the framework can deliver. This
doesn't.

If you're "exploring game engines" making a resume with one is probably not
what you should reach for and if you're "exploring DAWs" your testbed
shouldn't be generating a pure sine wave.

This sort of site is the opposite of a perfect testbed for a framework. This
sort of site doesn't need JS, it doesn't need a framework, it barely needs
CSS.

~~~
tashoecraft
Please stop, people can build whatever they want how ever they wish,
especially when it’s not planned to be super public. They wish to build it in
svelte, that’s all the reasoning you need.

I’ve also literally seen someone use a game engine to build a resume on here,
it was super cool and attracted a lot of interest

~~~
Vinnl
No one said people weren't allowed to build something with Svelte or whatever,
just that they didn't think it was a good way to explore it, and backed that
up with reasoning. Additionally, if there were other reasons for doing it,
those would be interesting to hear.

I wouldn't get too worked up about this: discussions about which jobs a tool
lends itself well to can be very insightful.

~~~
tashoecraft
It's more that this exact conversation happens on just about every post
someone makes using some tech. Someone comes in and claims it's wrong and they
should have done x. Was this the best use case for Svelte/any javascript
framework? Probably not, but who knows what the OP has planned for the site
further, maybe it will be beneficial to have a javascript framework in place.

~~~
Vinnl
I guess, and I recognise the frustration, but if they argue _why_ someone has
done x, or OP comes in and describes what else they have planned and why
Svelte or whatever _was_ a good fit, then that would still be interesting to
me.

------
crtlaltdel
Svelte looks interesting, however I must say that when I saw stuff like `{#if
value} <tag> stuff </tag> {/if}` it really was a turn off for me. One thing I
really like about React is the lack of template logic like that. This was
something I never cared for in Angular 1 either. I am sure that there are many
advantages to it...its just never really resonated with me. Can anyone point
to material that could help me understand the value?

~~~
BiteCode_dev
It normalizes the way templates are coded and forces people to put minimal
logic in their rendering.

In react, there are as many ways to do the same things as there are coders.
And of course, some don't follow best practices and will put logic code in it.

Personnally I also find it easier to picture the resulting DOM structure
because the stylee is forced to be declarative. Too often in react I have to
look around a tag to know whats hapening, or I have to follow some nested
map/filter/ternary chaining.

Very good react coders will not do that. They will use a lot of tooling and
abstract formatting a lot. But they are few.

~~~
crtlaltdel
I'm not sure how it forces less logic in the render. Looking at the Svelte
docs you can do this:

``` {#if invokeFunction()} <p>This function returned a truthy value!</p> {/if}
```

And with React do this:

``` { invokeFunction() && <p>This function returned a truthy value</p> } ```

and the result would be the same, a conditionally rendered string. I totally
agree in the normalizing/formalizing how templates are build and the more
verbose syntax in the Svelete example does make it super obvious. The in-line
React example is obvious to me...but maybe that's because I've been writing js
for so long.

Where I feel the cognitive overhead pain in looping. Svelete's docs say:

``` {#each collection as { vars }, i} <p key={i}> {vars} </p> {#/each}

```

For some reason, when I see this it rubs me the wrong way. I understand
it...but my instinct is to just map over the collection like I would in a
plain-old Node.js project.

``` { collection.map((vars, i) => <p key={i}> {vars} </p> } ```

I guess that saving a handful of keystrokes in exchange for super clearly
expressing the intent may be a good tradeoff, even if my inclination is
towards more terse code.

~~~
BiteCode_dev
In Vue it would be:

    
    
        <p v-for="(vars, i) in collection" :key="i">
          {{ vars }}
        </p>
    

Instead of:

    
    
        { collection.map((vars, i) => <p key={i}> {vars} </p> }
    

It's easier for me to picture what the first example is going to render
because it makes the markup the hero, with code inside, while the second
example is making JS the hero, with markup inside.

But this example is not even touching the topic. A render function is rarely
that simple. Now if you do maps, and filters, and ternary operators, and && /
|| pass trougth, and set several class conditionally, and pass an event and do
preventDefault, etc., now you have a more real life example. And in react
you'll get __a lot__ of JS, with very little markup. And you'll have either a
lot of boilerplate, or a lot of dependencies to get helpers.

While in Vue you'll get mostly markup, with a little code inside. It will read
from top to bottom as well. No needs to wrap stuff in arrow functions to get
the event object. PreventDefault has a helper. Setting classes as well. I
prefer that.

~~~
Rapzid
Vue's templates are great until they aren't, and then you wish you were using
JSX.

The IDE tooling is worlds better with JSX as well. Vetur has.. had a rough
year.

~~~
BiteCode_dev
I don't have to debug my render functions much in vue because they contains
little logic. Debugging is more common in JSX, it's better at solving a
problem it introduces.

------
dragosmocrii
It was a pleasure reading your article, I hope I can use it as reference for
my future svelte project.

And I must say that Svelte also caught my eye this year. I gave it a shot in
their playground, and I was surprised how intuitive things are. Svelte as a
compiler seems very natural an approach to building frontend apps and
independent components.

My next project will be Svelte on the frontend (SPA), and
Elixir+Phoenix+Absinthe on the backend. I personally think this will be a
killer stack for 2020

~~~
ketzo
Any particular resources you'd recommend for Elixir/Phoenix? Doing their basic
intro guides right now and liking them, but would love anything you did after
those that you liked.

~~~
dragosmocrii
I recommend the official book written by Chris Mccord for Phoenix. For Elixir,
I really enjoyed doing the assignments on Exercism. I also enjoy reading the
elixir forum, and the slack community has helped me with a couple roadblocks
in the past. But really, I think the best way is to just pick a project idea,
and start working on it. It works best for me learn while doing. I hope you
enjoy Elixir too!

------
deltron3030
I dig the simplicity, but why didn't you use Sapper?

[https://sapper.svelte.dev/](https://sapper.svelte.dev/)

(Next.js/Nuxt pendant based on Svelte, can also be used as static site
generator).

~~~
Wolfr_
I used Sapper before, I quite like it.

But now I wanted to explore how one would build something like Sapper, this is
why I went for base Svelte and then added a router. I now have pretty much
what I used Sapper for and the setup is simpler.

Also, Sapper doesn't seem to be in active development.

~~~
deltron3030
Fair enough. I'm dabbling with Svelte/Sapper myself but I'm not at a point
where I could roll my own with SSR and all that. Still trying out different
ways to build components, gravitating towards having a fat global.css file and
keeping the components themselves as thin as possible.

>Also, Sapper doesn't seem to be in active development.

For three months or so, but I wouldn't worry about that, because just a thin
layer on top of Svelte, and the maintainer is very active in the Svelte repo
it seems. It may only get bumps if something breaks.

------
indigodaddy
Some nice musical choices in the top music. Big Thief produced two amazing
albums in 2019. Glad to see Balthazar mentioned. They don't get nearly enough
love, especially in the US. Also, to note, the ratio of quality musical bands
to population in Belgium is second to none in my opinion. One of my favorite
bands is Intergalactic Lovers. One of the best female lead singers around..

~~~
Wolfr_
Thank you :)

------
Rapzid
I need to read more into svelte but I often find myself bogged down the
contrived surgical DOM update examples.

Well.. With redux or Mobx you are largely updating existing DOM attributes in
both Vue and React. The overhead in changing existing attributes on components
is fairly minimal, and it's certainly not where the bulk of the performance
issues in these systems are. It's also not where the value is.

The real value in Vue and React is reconciling data _graphs_ with the DOM
_graph_. Unfortunately the need to reconcile the full graph, or even parts of
the graph, is where a lot of the performance hit comes from. Particularly with
lists; hence virtual scrollers. With the advent of proxies though, I would
suspect both Vue and React could be retooled a bit to be more clever about how
the DOM graph gets updated in response to changes in lists and other data
graphs. More "surgical" so to speak.

Am I missing something or could the bulk of the performance gap be made up
without needing to ditch React and Vue(throwing the baby out with the bath
water so to speak)?

------
mechhacker
I've been using Vue for a while because it's possible to get things up and
running, even .Vue templates, without having to use npm tool chains. Just
linking the Vue and other source files.

But, I really like the speed and user experience here. I may actually give it
a try.

~~~
ricardobeat
Svelte has very few dependencies, and zero of them at runtime. Hot reload is
instant. A real breath of fresh air when coming from other frameworks.

~~~
mechhacker
I've been trying it throughout the day and so far I find the way of doing
things better than Vue. I'll see if I can sort a binding issue that was
causing me a bit of complexity in Vue. So far, it looks like it would make
solving that trivial.

------
Bob312371
Loads quickly. Looks good. Nice and simple UI. Well done! If you're looking
for the next challenge, consider making it render server-side.

~~~
Wolfr_
I am still 100% confused as to how it would work it I would "enable SSR"
(which Sapper would allow you to do). Would the end result be a static site
then? Something to explore next year (also see the comment below about it not
working at all without JS)

------
amelius
How well would your setup handle larger amounts of data (say 10x, 100x,
1000x)? Would Svelte be able to handle it? What would you have to change in
your design? At what point would you have to replace the entire architecture?

~~~
Wolfr_
Here's a fun demo to look at:
[https://twitter.com/rich_harris/status/1200807516529147904](https://twitter.com/rich_harris/status/1200807516529147904)

------
oskarp
Not sure if this is a problem with the website or routify but clicking on the
routify link in iOS Safari makes the browser back button unusable. Nothing
happens when clicking on it.

~~~
Wolfr_
Thanks, I am going to investigate this.

------
sergiotapia
Tried Svelte and it seemed really concise and fun to work on, however I really
miss being able to format on save with Prettier in React.

Is there an auto formatter that makes my code shift around and have one-true-
style? This is a most for any long lived project as it avoid all bikeshedding
discussions about style. We use Prettier for JS, and mix format for Elixir, at
work.

~~~
pakpoi
There is a plugin for prettier[1] and for eslint[2]. Both work reasonably
well. I hear there is good support for VSCode, but I haven't tried.

[1] [https://github.com/UnwrittenFun/prettier-plugin-
svelte](https://github.com/UnwrittenFun/prettier-plugin-svelte) [2]
[https://github.com/sveltejs/eslint-plugin-
svelte3](https://github.com/sveltejs/eslint-plugin-svelte3)

------
numbers
Thanks for the write-up! I’m interested in svelte as well and this gives me
some inspiration to try it this weekend!

------
factsaresacred
Nice writeup.

> _" In 2018 I went content-first, but this year I went design-first. I more
> or less created all of the designs first, then implemented them as opposed
> to last year."_

For somebody who believes that it's as fast to simply design in css, was this
step worth it?

~~~
Wolfr_
For me it's about testing new technology, and I consider Figma's autolayout
new technology. I think by doing things in a design app you experiment with
other things you wouldn't necessarily do in the browser. For example colors,
fonts... compared to the '18 and '17 version I believe this one looks better.

I do have to say I am quite fast with Figma as my day to day work is being a
UI designer.

~~~
factsaresacred
Cool, having looked at your design file I can see the benefit of having
everything laid out - allows you to easily explore different ideas.

Figma seems like a tool worth learning, will have to dig in some more.

------
diminish
Does svelte have any traction recently? Any big names using it?

~~~
Wolfr_
It did well in the State of JS, but there are no big names using it. I think
it will have grow in popularity in 2020. The community is still relatively
small.

~~~
arxpoetica
The list of "who is" is most certainly growing, and there are definitely some
bigger names out there:
[https://github.com/sveltejs/svelte/blob/master/site/src/rout...](https://github.com/sveltejs/svelte/blob/master/site/src/routes/_components/WhosUsingSvelte.svelte)

Jobs listings are cropping up in sundry places too. See for example:
[https://sveltejobs.dev/jobs/apple-senior-front-end-
developer](https://sveltejobs.dev/jobs/apple-senior-front-end-developer)

------
rado
Excellent site, thanks for sharing.

------
marcus_holmes
_cough_ Elm _/ cough_

------
amelius
Title makes it seem as if the website received an award.

~~~
Wolfr_
Not intentional!

------
83hajfjeijg
[https://bestof2019.johanronsse.be](https://bestof2019.johanronsse.be) just
shows an empty page.

(oh how far we've come - a simple best of list requires javascript)

~~~
karmakaze
Thanks for the quick link. Complaining about a web page not working with js
disabled is just noise, especially on a 'made with {framework}' post.

~~~
_-___________-_
I tend to agree; however, it's _really easy_ to make a site like this work
without JS.

Edited to add: to be clear, I mean _while still using the framework_.

~~~
sosodev
Is it? You either you need some kind of server side JavaScript rendering (pita
to get right imo) or you need to create a complete copy of the website that’s
statically rendered (and replaced if the user has JS enabled?)

~~~
_-___________-_
Have a look at Sapper, which is a framework built around Svelte that makes the
server-side rendering pretty easy. I worked with a next.js SSR project
recently and that was an absolute trainwreck, but Svelte/Sapper, while not
perfect, is pretty nice.

You have to be a little careful about the interactions if you really care
about it working with no JS (e.g. have an on:submit for a form and then also
have a server-side route that it can POST to) but it's not too bad really.

