> 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.
> 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):
> 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.
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.
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.
I think it really depends on foundries. For klim and commercial type are example of famous, older, established foundries. There are many foundries with more permissive licenses. For example fonts.floriankarsten.com has weblicense that is not tied to domain but only total monthly views with generous 50k month its perfect for many small and hobby projects especially of some other project pays for license. I have feeling the type market is going to be really disrupted by new small foundries. There just too many newcomers and it became quite a bit easier technically to make fonts.
> 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?
I take issue with opinions like this that are espoused as fact. I've built large apps in both Angular and React. The React code base needed everything that I got out of the box from Angular. The difference is that React had no one true way to do things which I suppose some people would consider a good thing. I don't.
Angular is a framework. Its not over engineered, its complete. You might not like its chosen abstraction but for people like me who just want to get shit done without needing to worry about plumbing and boiler plate, its really nice.
All that said, Svelte looks cool. I'll check it out. I think its a fair criticism to say that Angular has a steeper learning curve and if I can reap all the benefits with a shorter ramp up time, its worth adding to the tool belt.
To understand why people say Angular is over-engineered Google something simple like "Angular http request". You'll end up at this page: https://angular.io/guide/http
It's almost comical. I can't believe how long that guide is and how many concepts Angular invented just to fetch some JSON from an http service.
Interestingly, they explain some of the reasoning behind the extra info in the docs.
WHY WRITE A SERVICE?
This example is so simple that it is tempting to write the Http.get() inside the component itself and skip the service. In practice, however, data access rarely stays this simple. You typically need to post-process the data, add error handling, and maybe some retry logic to cope with intermittent connectivity.
The component quickly becomes cluttered with data access minutia. The component becomes harder to understand, harder to test, and the data access logic can't be re-used or standardized.
That's why it's a best practice to separate presentation of data from data access by encapsulating data access in a separate service and delegating to that service in the component, even in simple cases like this one.
I find it a little strange that you are pointing out comprehensive documentation on a module as proof of a problem with the framework...
Lets talk about what you get with HttpClient:
- Easy testing. Because its using the DI system, its very mockable. You can totally set this up with fetch or whatever behind a service but, well why? Its already done.
- Robust type safety. Again you can set this up with fetch, but why? Its already done.
- Integrated with rxjs/observables for data transformation, piping, and filtering. You can set this up with fetch but why? It's already done.
- Discoverable API because of the deep framework integration and type intelligence. You can set this up with fetch buy why? It's already done.
- HttpInterceptor is awesome for checking for things like auth tokens and such. You can set this up with fetch but why? It's already done.
Not specific to HttpClient but:
- AOT compiler means that unneeded code gets pruned keeping your bundles small.
- AOT compiler means that you literally can't compile incorrect code (but it provides an escape hatch if you want to live your life that way)
I can make this same argument for pretty much any module you throw at me. Like I said, Angular is _complete_. Is it the right fit for every situation? No! :) It's overkill for smaller projects but if you are building anything of sufficient complexity, you _will_ need all this stuff. The question is, do you want it to be something you had to roll yourself and didn't have time to document for your teammates or do you want something that did all the hard work for you and is ready for whatever you throw at it?
I mean it's really not "already done" if you have to use all this boilerplate to get those features.
> Robust type safety. Again you can set this up with fetch, but why? Its already done.
Not sure what you mean here. Fetch has high-quality TypeScript bindings. For the rest it's mostly YAGNI. The boilerplate confuses new developers (try explaining what NgModule does to a junior dev just trying to build a simple page) and experienced developers know how to do this stuff themselves.
It's YAGNI until you do. Since we're busting out the acronyms a lot of what you are saying sounds like a case of NIH syndrome. :)
I have trained junior devs on Angular and I think it's a fair criticism to say it's a steeper learning curve. They do fine tho and as an added bonus they get introduced to concepts like IoC and the like which sets them up for other languages.
Experienced developers can set this stuff up its true. I have in fact. It's fun the first few times. Then you get annoyed and want to actually work on your problem domain. I'd much rather spend my time and brain power on that stuff.
The apps that I've built that had an established pattern and all the infrastructure needed from go tended to age better and tolerate changes to business requirements. The ones where we rolled it all hodge podge needed more extensive refactoring later.
I mean look: this really boils down to very different philosophies. You either go light and build as you go or go everything and the kitchen sink and deal with (what some would call) bloat. I think both have their pros and cons. No silver bullet and all that. You gotta look at the situation and make a call. The rest is just preference and gut instinct.
Angular uses an RxJS interface to XMLHttpRequest, which has a few advantages. For example, only relatively recently did fetch() (including polyfills) support cancellation.
That said, there's absolutely nothing that requires you to use @angular/common/http. Angular created it because developers have to solve those problems over and over, but it's just a library under the Angular roof; you can use fetch() function instead.
Possibly because vue does not have any builtin http capability... which is kind of the point GGP is trying to make up there.
Angular is not overengineered, it's just feature-complete. vue is not "simple made easy", it just delegates lots of functionality to 3rd party, leaving the confused developer to read medium posts on the line of "axios vs. vue-resource".
I prefer the vue way, but it's a subjective personal preference and should basically be ignored by others.
They're not invented by Angular but for each and everyone one I have to learn how to do it the "Angular way", usually with an Angular-specific API. That's why it's over-engineered.
Angular is (loosely) a superset of what Svelte provides: it's a templating engine, it has a built-in forms library, built-in routing, dependency injection, baked in i18n support, and better XSS sanitization than other frameworks. Angular's templating engine is fairly complex too; it, for example, has a concept of "pipes", so you can write something like this: "<div>{{data | json}}</div>" which will take a JS object, data, and pipe it through a function that returns a stringified version of it, which is what is used in your template. (Compared to other frameworks, this might seem obsolete since JSX is syntactic sugar for JS: in React, you'd just write: "<div>{{JSON.stringify(data)}}</div>").
It's commonly used with Angular CLI to have simple commands like "ng serve" and "ng build" to bundle your application. It also heavy handedly imposes constraints on the architecture of your application-- to some, that's a benefit. All Angular apps kind of look the same.
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).
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.
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.
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
This is something very new (a few weeks) and still a work in progress, it's nowhere near complete. It's going to be a “way of doing things” instead of a full-on framework, but at the same time, we could use more examples on how to exactly do what it prescribes. A tutorial, a sample project following the conventions etc.
It will be interesting to read the comments on this early version but it's not really “released” yet.
Wolfr_- Just read over ygdir and wondering: We've had such phenomenal success with 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.
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.
> - 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...)
Pretty much this, utility-first leads to unmaintainable codebases, I try to explain why I want to change this with a combination of conventions on this page: https://ygdir.dev/rationale
I prefer non-semantic class names (“messy” is up for debate). I find it much easier to reason about the markup when I can see exactly how each element is styled right there _with_ the element. Not only does semantic naming add a layer of indirection, I have have never found it to be as “clean” as you are insinuating. I can’t count the number of times I’ve found myself having to invent names for elements, containers, etc. just so I can apply a style when it would have been much easier to just “style=whatever”. All the naming conventions in the world don’t solve this: is it list-item__header or list__item-header? Who cares?
I don’t find your arguments about maintenance very compelling either. If you want an element with “p-3” to have more padding, just... change it to “p-4”. That’s the whole point! You don’t have to wrangle with the _semantics_ of the element. You style it exactly as you want. It’s akin to using the `style` attribute but terser. The only vector of change for the definition of a class name becomes the CSS spec itself. “p-3” === “padding: 3px” and cant _ever_ mean anything else (or it would have a different name).
I see your point about SaaS tools, but why can’t you just add a class name for that purpose alone? Seems simple enough to me.
I’ve tried just about everything when it comes to organizing CSS/styles and I have come to the conclusion that semantic naming is more trouble than its worth.
Thank you for explaining. I think the difference between tailwind and styled-system is that the CSS-in-JS approach (while still being able to write normal CSS via styled-components) eliminates most of these issues up front in favor of a component-based approach that contains said complexity very efficiently.
One request: I read your gaming section eagerly and all the games you mentioned look super cool, but would you mind adding some links / details about each of them? I’m still not sure exactly which racing sim you’re talking about and the other screen shots look super cool but I had to google each game to figure out what the deal was. Not a huge deal but a small suggestion.
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?
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.
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
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.
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.
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.
Scale. Just because it was posted on their website doesn't mean they intended to draw a large, extremely critical crowd to it.
It was also the tone the commenter posted in here and across this post that came across very condescending with a holier than thou feel. They also created this account today and have been flagged and had a mod post about their postings. So if they offered some helpful advice in a more constructive way their wouldn't be a need to tell them to stop.
This is much more about what the framework solves: UI as a function of the data, no spaghetti code full of DOM handlers and cross-references that are hard to follow.
Now I just used Svelte for this project, which is indeed a simple website which might not need this at all.
Still, I invite you to do similar transitions as I have between every page and on the homepage without a framework.
I didn't see any real transitions. I think I might have seen a bit of fade-in after page load, but that might just be a browser quirk. If the fade is why you're talking about, that can be easily accomplished with just a few lines of CSS; no framework needed.
If there's some transition I didn't see because of the browsers I used (I tried two different browsers on two different devices), then it might be worth using the framework, but I maintain that I haven't seen the demo site show anything that couldn't be done with vanilla HTML and CSS.
In my experience, there’s seldom such thing as a “super simple web site”. I always run into situations where some dynamic functionality is required and vanilla JavaScript gets messy very quickly. Svelte is so compact and easy that it is the ideal tool for such scenarios.
I did that the years before: using a static site generator. The goal is to explore new technologies so I can decide what to use at work. I spent quite some time on the router aspect here, which I know now more of, that I can use during the work year (where I won't have time to explore this.)
But this is not a regular static site, right? In the sense that it does not work with Javascript disabled, which is why you needed to do this:
> Then I remembered that I would probably need to redirect all requests to index.html.
Compare that to e.g. my blog (also the result of an experiment), which has the fast page changes you were looking for, but also works without Javascript, albeit with full page refreshes when switching pages: https://vincenttunru.com/
I agree, the reality is most people in the software world are too nice and polite, which is great but tend to foster the amount of nonsense because few people are willing to call it out for fear of being branded a hater.
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?
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.
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.
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.
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.
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.
Things like Hiccup and React/JSX were a breath of fresh air next to templating languages like Handlebars/Mustache/Jinja. I prefer to just write simple code instead of learning the idiosyncrasies of yet another DSL.
In your first example, if invokeFunction() returns 0, the text "0" will be inserted into the page. 0 is falsey, so `0 && <p>Hi</p>` evaluates to 0, but 0 is a number so React pastes it into the page contents.
React has footguns like this because JavaScript expressions were not designed to be used as a templating language.
Thinking your function returns a boolean when it returns an int seems like another issue entirely, like habitually depending on implicit conversion like "==". If that's a common issue for a team, maybe it's time to look into Typescript. Seems like a very minor reason to use a whole new DSL with a whole new set of warts for all of your templating.
I agree. Some argue that this kind of template syntax makes it easer for html folks to write logic, but really what it's doing in the long run is introducing yet another abstraction for them to learn while also poorly assuming that they "can't learn JS". Teach a person how to fish... I think the real reason, however, is that it allows for easier compiler-level optimizations.
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
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.
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!
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.
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.
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..
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)?
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.
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.
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)
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?
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.
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.
> "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?
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.
Unless you're using something else than a regular text editor/IDE for editing CSS, using UI controls to experiment with how things look would normally be faster for many. I'm a programmer myself, but having UI widgets I can drag or interact with is way faster than writing numbers and attributes, when it comes to coming up with a design.
Although, this assumes you're in the initial design phase of something, not the typical designer->developer handoff where you basically just want to implement a specification someone handed you.
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.
With all respect: why is any post important? Why is your comment?
It's a blog post by someone giving their individual experience working with Svelte, a somewhat new framework with some interesting and somewhat unique ideas and approaches. It has a lot of buzz, so seeing someone else postmortem of how a small project was implemented using it is useful.
Could you please stop posting unsubstantive comments to HN?
Could you please also stop creating accounts for every few comments you post? We ban accounts that do that. This is in the site guidelines: https://news.ycombinator.com/newsguidelines.html. HN is a community. Users needn't use their real name, but do need some identity for others to relate to. Otherwise we may as well have no usernames and no community, and that would be a different kind of forum. https://hn.algolia.com/?sort=byDate&dateRange=all&type=comme...
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.
How can I explore new technologies if I impose limits that others don't set for themselves? The job market asks for JS skills. Look at my conclusion at the bottom of my post: I state that this might be a technology downgrade instead of upgrade.
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/):
> 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):
> 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.