Svelte is the most beautiful web framework I've seen
thefutureoftheweb.com
thefutureoftheweb.com
I got introduced to Rich Harris via a podcast (not personally), but am a big fan of his perspective on JS. I think we can all agree that; if you don't like Svelte, then fine. If you love JSX/TSX - then great! If you're a Vue person, then awesome - its exactly what makes this community great - the diversity & innovation. Not the soap-boxing antics, polarised opinions & vilification of opinions that aren't congruent with your own.
As someone much wiser than me once said - "always bet on Javascript".
Its easy to see why some folks would get riled up over this crap though. Like, if you don't like React right now, but want to do frontend development professionally, your job prospects get slashed in half or more. Really like Vue? That's awesome! But you might have a small fraction of the options your peers do when interviewing. Like a more exotic solution like Svelte or Elm? Hope you like working remote or are okay with relocating for that, because there's probably not that many places to work at in your area.
So people will try really hard to get the community to rally around their favorite choices. And the tools without cheerleader squads often fade away and die. Rock and a hard place.
I've been keeping all the modern javascript frameworks at arms distance, because I've always preferred to bet on HTML, for the client at least. That said, I've no issues with heavy reliance on JS on the developer machine, but I always prefer pages that can work without the reliance on JS.
So, it seems opportune to ask: Is there a JS framework around that actually compiles to HTML and CSS rather than embedding the HTML in JS/DOM calls? In my rudimentary analysis of React/Vue and others (eg svelte), I can't find out how to have the end result without the framework sitting in there too. Perhaps I keep missing something in my understanding?
CSS is extracted at build time; typically your styles will be served as static .css files for maximum efficiency.
Svelte compiles down to JS.
That'd be 95% of all these dev.to articles
Has anyone with React/Vue experience used Svelte for a significant project? I'd love to hear about your experience with it.
There are some things which weren't ready when I started, but I worked around them. The overall experience is that Svelte results in faster pages, less code, more predictability, faster builds... overall, it's a better experience.
But if I go to a content page (eg. https://www.beyonk.com/uk/6Gb_Kj/guided-ascent-of-curved-rid...), I see that the response is a 286KB blob, mostly consisting of CSS. If I reload the page, I redownload that 286KB blob. Wouldn't it be better to serve the CSS separately so it can be cached across sessions?
Being JavaScript?
That said, React's mental model is so powerful that I've almost never needed to actually debug into it to see what's going on. If you've got an issue, tracing the dataflow in your own code is generally sufficient. So, I'm okay treating it as a black box.
(Hiya, Shados!)
The source data sits in an array of objects.
On each update, I need to update the table cells with the latest values from the source array. The content of each cell can change, possibly it's css class too (from red it become blue for example).
I'm using Vue/Bootstrap-Vue table at the moment, but it's quite slow.
Is Svelte suitable for this? Other options to quickly update a <table> from data in an array of objects, one object per row?
It seems to do pretty well! I turned on the FPS meter in Chrome and scrolled around a bunch, and it seems smooth, reporting around ~50fps. It did get my CPU going pretty good, though.
https://svelte.dev/repl/061b958e665c4949bcf831fa5da474c4?ver...
EDIT: The performance is a lot better running as a standalone app (I downloaded the app and ran it locally). Maybe the REPL adds some overhead.
btw, Looks really snappy on my laptop.
I would say his next problem is going to be getting the data fast enough to feed the the UI, a nicely packed websocket protocol would work well I'd guess
E.g. the symbol for "GOOG" stored in a hash table, when GOOG updates; call that hash directly: "symbols[symbol].update(data)" then re-render the cell DOM element.
You really have to profile the code to figure out what's expensive. Maybe there is no scaling wrt. the number of nodes that change because repainting/relayouting is more expensive than updating the DOM.
They are basically free when you have this little data. 1k cells updates 10 times a second means that you have around 100 micro seconds per cell, you can do thousands of lookups in that time. The only things which could even come close to costing 100 micro seconds are if you accidentally re-flow the html each cell update, re-render the html each cell update, send a http request each cell update or if you go through all the data each cell or the framework you are using is extremely inefficient or other unnecessary work. Each of those are easily fixable by doing the html and javascript by hand instead of using frameworks.
https://opensource.janestreet.com/incr_dom/
it is built for visualizing HFT, so performance should suffice.
Not a problem for a single layout pass, but a performance problem if the data changes every frame.
WebAssembly might help you as well.
Source - I work on perspective.
I wrote a couple of hundred lines of vanilla JS. It works fine.
Huh? No, not at all. As far as I understand, React has algorithms that replace only the html that changed in a dom subtree (and that is called virtual dom, not shadow dom, which is a different concept).
But if you already know exactly what has changed and where to change it in the page, there is no need for more complex algorithms to kick in. Just take the pointer to your div or cell and change the content.
Bottom line: React is written in vanilla Javascript. Can't do better than it.
You should watch "Rethinking reactivity" on YouTube.
React is using Virtual DOM, which is not free. It is fast, but it is not free.
Of course, that's what I meant- maybe it wasn't clear. React can't be faster than vanilla js, it's written in vanilla js after all.
The whole virtual dom's purpose is to calculate the smallest possible update when you don't know (and don't care) what exactly has changed in your view. But that calculation of course has a cost. And if you know very well what changed and where, like in the case of the GP, nothing can be faster than changing it directly.
Changing the DOM doesn't cause a full re-render, the browser will optimize the repaints to only the parts that have changed.
People don't understand how the DOM works, and its become a great way to filter out people.
I bet if those 100 rows aren't even in the viewport you can get a big perf boost by only rendering a subset and rendering more when the user scrolls.
We've gotten ~30x boost on our tables with 100s of rows by using a progressive rendering algorithm.
virtualdom - preact/react/vue/snabbdom e.t.c is usually fast for most things. you can diff about a million things under a 10ms timeframe. Rendering a million things is an entirely different ballgame.
I'm using it to mimic Excel-like display of data, and it's pretty responsive, but I'm not at your scale of 10x/sec.
It also supports cell highlighting with different colors, but, unfortunately, doesn't natively support CSS-type classes on cells.
Paste this and run:
<script>
const rows = 100,
cols = 10,
table = Array.from({ length: rows }).map((_, i) => Array.from({ length: cols }).map((_, j) => ({ i, j })));
console.log(table);
setInterval(function() {
let cell = table[Math.floor(Math.random() * rows)][Math.floor(Math.random() * cols)];
cell.i = Math.floor(Math.random() * 100);
cell.j = Math.floor(Math.random() * 100);
}, 1);
</script>
<table>
<tr for="let row of table">
<td for="let cell of row" bind>cell.i + ":" + cell.j</td>
<td></td>
</tr>
</table>
Let's say you slowed it down to 1x per second, you'd increase max possible latency of an updated value being displayed by ~900ms - is that enough time to be important in your application?
See an example on how they look: https://youtu.be/DMz1CZPdI-g?t=437
You still gain a lot of benefits from your component framework this way (composability, life cycle management, easy interop with the rest of the app). It’s more work that you wouldn’t want to do all the time, of course.
> I wouldn't even know where to start to allow clicks and such.
Figuring that out should be a good exercise, then. Otherwise, you might want to use some library building on top of canvas.
Funny, that's what everyone said 5 years ago. I'll bet on React to be here for another decade, no problem - there's just way too much momentum. In a way, it's Rails all over again (that's a positive).
It may not be the glory days, but Rail's is still going strong 13 years later. React, however, has reached a popularity many times larger than RoR ever did.
https://trends.google.com/trends/explore?date=all&geo=US&q=r...
There has never been a project (I can think of), other than the Linux kernel, with the resources that companies and developers have put behind React.
> Do you remember Adobe Flex
Flex never came close to either RoR or React popularity, and was propelled mostly by the dying wave of ActionScript programmers from the aughts after cell phones killed the Flash game market.
[0]: https://trends.google.com/trends/explore?date=all&geo=US&q=r...
Seriously? Adobe Flex was a closed-source and proprietary commercial offering capitalizing on the prior decade's popularity of Flash.
React is open source with a vast and robust ecosystem of even more open source to go along with it. It couldn't be more night & day.
That confirms it: you aren't old enough to remember Flex. It was open source.
> https://trends.google.com/trends/explore?date=all&geo=US&q=r...
I'm not sure this chart is very good evidence of this claim. There are so many other things named "react" -- Nike React shoes, Kids React videos, reactionary politics, and so on -- that it's a bit like claiming Trump.js is the most popular JavaScript library in the world because of this chart: https://trends.google.com/trends/explore?date=all&geo=US&q=r...
If you want a component-based view library that is written in js, and you are happy to take on the task of assembling a build-system, styling system, routing and of course state-management, I can't see much of an architectural improvement you could make over React.
If you want batteries included - go with Vue.
If you want the Ruby/spring opinion and batteries included go with Ember.
Svelte looks kinda cool. But it seems to sit deep in the browser spec, and in my NAIVE opinion, it doesn't seem hold the component abstraction as something even valuable. It just wants you to script away. Which, is just movement within a trade-off space - if it suits you go for it.
{#if user.loggedIn}
<button on:click={toggle}>
Log out
</button>
{/if}
It doesn’t have the ad-hoc nature of “oh crap we forgot to add if-then-else” of Angular or “let’s create half-a-dozen incompatible javascript-like DSLs” of Vue.
Though I would assume Editor support of Svelte can/is being built.
On a regular basis, I encounter the need for a GUI for some API or backend I write, so I tried to get into a more modern Javascript eco system. I have created websites and even full-on forum software in a long forgotten past, so I have some basic old-school webdev and basic Javascript knowledge (from back when directly manipulating the DOM was still the way to go). So take this as a bit of an outsider look on things, who is confronted with full-time Javascript developers on a daily basis.
When I started looking into react, vue, ... it always overwhelmed me. Whatever I started doing, according to someone, it's bad practice and should just do Y instead of X. Nobody seems to agree on best practices, and there seems to be a whole lot of 'magic' going on in all those frameworks, and knowing where to start is an absolute mess. It's confusing as hell.
Now I quickly went through the tutorial and examples on the Svelte site and it felt pretty simple, I can reason with how it works behind the scenes, and can read the generated Javascript to verify that that's really what's going on. It makes the whole thing seem more manageable in my head.
As far as "the new exciting one" goes - what appeals most to me personally is its simplicity. One of the reasons Go also appealed to me. It was exciting for a while, but ended up being the boring 'it just works' solution which completely replaced C and C++ in my life (that's not a jab at these languages, they have their uses, I just don't need them anymore)
That said, I don't think boring is about age, but about real-world exposure
Also losing React Native, which is non-issue if you're just developing a web app.
function FileList() {
if (!files.length) {
return <EmptyMessage/>;
}
return <List items={files} />;
}
function FileList() {
return files.length
? <List items={files}/>
: <EmptyMessage/>;
}
/me goes back to happily "server side rendering" HTML with PHP
I think it's a matter of personal taste.
<div>
{items.length === 0 &&
<p>No items.</p>
}
{items.length === 1 &&
<p>Warning: You only have 1 item, at least 2 is required</p>
}
{items.map(...)}
</div>
It's the benefit of having a full language instead of a template DSL for rendering. Declarative syntax is easy inside of an imperative flow, doing the opposite tends to lead to problems though.
A redundant extra component is bad for performance.
<div>
{if (cond) {
<Comp1 />
} else {
<Comp2 />
}}
</div>
<div>
{switch (expr) {
| A => <CompA />
| B => <CompB />
| _ => <CompC />
}}
</div>https://www.reddit.com/r/Clojure/comments/bqh0z4/virtual_dom...
https://rawgit.com/krausest/js-framework-benchmark/master/we...
A few unvarnished takeaways from a data science / viz point of view that I was thinking of writing up, but will use HN as a sketchpad:
1. I don't really miss the React 3rd party ecosystem as much as I thought I would. Since most of what I do is data viz / data presentations, I really just need a few d3 helper functions, and most other things I can build myself w/ svelte's affordances. The biggest downside, however, is that there aren't any good accessible UX component libraries for Svelte, so I have built my own. This all said, I'm productively code-homesteading and I love it. Animating component lifecycles, component style scoping, and state management are 1st-class citizens, so these pieces are pretty high-quality, usable, and thoughtfully built.
2. my "time to first meaningful render" metric was at an all-time low with Svelte. Getting started on a new idea or project is far, far easier than w/ any React project I've ever done. Substantially less boilerplate means I can get much, much more done in the same amount of time. I feel this every time I jump back into the React projects I work on & maintain.
3. as my apps have grown in complexity, I've found that Svelte really holds up beautifully. The style/layout/behavior colocation strategy keeps the cognitive overhead of working on all the parts of multiple components to a minimum. The performance gains of Svelte, even with complex components and interactions, feels magical. Bundle sizes are bizarrely small.
4. as someone who feels CSS will absolutely outlive all of these frameworks, I think the design of Svelte really feels like the best of both worlds. And that's how it should be – css + markup should be first-class citizens.
5. the testing story isn't fully there yet, so I would say to that end, proceed with caution. I typically try to compartmentalize JS logic from presentation as much as possible, but perhaps you don't.
6. the reactivity parts shine everywhere and are fairly easy to reason about in all cases, but they REALLY shine when you're building complex visualizations.
7. this is an important one to me – building something in Svelte really tickles the same part of the pleasure centers of the brain that JQuery did for a previous generation (and d3 did for early data scientists). You just SEE the thing work, effortlessly, at a low cognitive cost, and everything fits together so nicely. I often start svelte-powered experiments and end with a great, reusable component. I think there is a large group of engineers who remember the JQuery days and sat out the React era because it just seemed like way too much to do simple things. I think Svelte is especially for them.
In sum, really highly recommended to at least try it. I wanted to find evidence to discount Svelte, but haven't found any at this point, despite my best efforts. There is probably a certain class of dev that should be trying it – one without a ton of organizational constraints, probably. But if you do data science and want to level up your data presentation skills, you should be using Svelte imo.
In the meantime, I would recommend walking through the tutorials & examples. They're very well written and I go back to them regularly to try out different parts. Try just making a simple line chart! Now make six on one page! Now try to link the rollovers for all of them! You'll probably learn a ton doing just that.
[0] http://imba.io/
Imba can also be used to make desktop applications it seems. The team behind it also released GitSpeak, a Github client that works really well.
Now I primarily use react. Vue looks great, but I don’t want to introduce yet another framework.
I could use some insights/view points from hn. I don’t feel using/learning the now-abandoned frameworks is useless though — the things I built are still working. But good luck to anyone who’d want to maintain that codebase (unlikely in my case).
[1]: http://rivetsjs.com/
https://github.com/blikblum/tinybind
I haven't used it though.
<Board {game} />
<Board game={game} />
<Board {...{game}} />
At any rate, I recommend looking at the code example linked in the post, or watching the video. Otherwise the post is pretty low in information, as the top comment at the time of writing this suggested. https://github.com/jesseskinner/svelte-tic-tac-toe
<Board {game} />
<Board game={game} />
<Board {...{game}} />
<input type="checkbox" {checked}>
<input type="checkbox" checked={someBoolean}>
<a href="page/{p}">page {p}</a>
https://svelte.dev/docs#Attributes_and_props
It seems like a neat design.
Board.draw(game)
drawBoard(game)The thing with JSX is introduces a syntax that is familiar to the rendered output (which is the status quo), and there's a relatively clear visual separation between the declarative and imperative parts; which is hard to enforce in pure JS.
No.
The lack of questions and the relentless downvoting makes me believe nobody's interested in hearing my explanations.
https://changelog.com/news/a-ui-framework-without-the-framew...
( https://choo.io )
You can view the site directly at the uglier url: https://svelte-website-mrf26sti4q-uc.a.run.app/
Someone posted a link to the Google Cloud Run issue above[1] that links to the non-vanity URL.
Sadly the latter is still under the radar despite bringing in many interesting innovations to the space: its server-side approach being one of my favorite features.
[1]: https://markojs.com/
This is not a PC. It is a Mac. So yeah, it's a personal computer.
A framework that powers the web, isn't it a web framework? It's just a very broad category that also includes backend framework.
Nginx powers the web. Chrome powers the web. Rails powers the web.
There's a webcomic of some sort to which I can't find the link, which talks about this. Some one is sick of the bloat of x framework/tool/whatever, and decides to build it better. He works hard, and finally version 1.0 is released to dramatic music. But there's a problem - it hits the real world and starts running into edge cases, bugs, and other things that can't be predicted in design and testing, necessarily. Features creep, and over time, it becomes just as bad as that which it sought to replace. Then, some bright young soul gets the idea that he can do it better...
This is not to discourage innovation. It doesn't appear it's been battle-tested like other frameworks, and I don't see many major operations on the list of users. If it ends up better, great, but I can't say I'm optimistic.
It's something most of these frameworks should have already done by now considering they need build steps but maybe it needed a new project to make it happen. It's a brand new release though so it'll take more time for uptake, and by people who think the opposite of what you typed.
On compilation, nope. Riot.js did it first, and this is literally the entire premise of typescript (I know typescript is a different language, but I see little difference here as it can mix with JS between writing only some stuff in TS).
You're right, they probably should have done it, and I'm excited to see it. But I also don't see why they couldn't have submitted a PR to react/angular/ember/meteor/vue.
I see this sentiment a lot in open source. When I made Rollup — which is now used to build the most popular libraries in the JavaScript ecosystem, including some you just mentioned! — people asked why I didn't just submit a PR to webpack?
I understand why people ask that. But it just doesn't work like that. Very often, to take a step forward, you can't simply make incremental changes to an existing project — you need to create new foundations altogether. When Svelte 1 came out in 2016 I was already responsible for a different framework (Ractive), and it wasn't possible to make the changes I wanted there. If you can't do what you need to do by making a PR to your own project, then imagining that you can do it in a PR to someone else's is a fantasy.
And it's not simply about adding some extra compiler smarts to existing frameworks. The whole point of Svelte 3 is to rethink the developer experience. It has radical opinions about how we should be building apps, which I've written about in https://svelte.dev/blog/svelte-3-rethinking-reactivity and https://svelte.dev/blog/write-less-code.
Is that really true? React and/or Angular is something I would expect. If one uses anything more exotic then one should have a "they'll figure it out on the job" attitude.
> But I also don't see why they couldn't have submitted a PR to react/angular/ember/meteor/vue.
Do you honestly believe one can just leave a "here's a full static compiler for X" at the doorstep of these projects with some expectation of it actually being accepted?
That would basically be an entirely separate program to be maintained alongside the runtime and any design considerations on either side will affect the other side.
That's a good question.
- Svelte makes far smaller files than React
- Svelte is faster to execute than React
- Svelte is easier to learn
The Web Frontend, already running on top of an apparently inadequate framework called "HTML5", somehow needs to be reinvented every year and it's a huge cost factor.
No other platform is as widespread and accessible as the web. There's more developers able to target sites that fit a massive range of uses, more than any other platform ever. So ofcourse there are going to be different needs for different use cases.
Maybe not quite every year, but the dominant frameworks have changed a lot in the past decade and if you're still running some of the "next big things" of yesteryear the developer pressure to switch is strong. The churn is real.
> React was released 6 years ago, Angular fully released about 3 years ago.
In my opinion, React being quite stable over that timeframe is a big factor in it becoming the dominant player. Angular being scrapped and rewritten is exactly what I'm talking about, lots of development effort wasted there.
> This argument that everyone needs to slow down because some people don't like hearing about change is ridiculous.
If the kids want to keep playing with the latest toys, that's fine. Just don't expect the people paying the bills to buy into them.
You seem to have an axe to grind against JS.
When I am talking about "settling down", I'm talking about the people that implement real systems for businesses to use. Those people have to make decisions on the technology they're pushing.
If those people can't settle on a stack and keep changing their minds on how to implement a user interface, somebody has to pay for that. This is akin to a "little fire" in a very real sense - it's burning money that could be used otherwise.
So telling me that "I don't have to use it" is besides the point. I don't run the whole show by myself. Developers need to be reasonably comfortable with their stack. If you are using <outdated stack X> but the whole industry is shifting towards <shiny new stack Y>, people will just quit on you.
People will experiment, and it's good for the industry to have new innovation, but there's really not that much danger of constantly shifting tech stacks unless your team and leadership don't know what they're doing - and if that's the case, you have bigger problems then the tech stack.
That's not really how hiring works. Nobody is going to put "I failed to get anything done because we re-wrote everything in Svelte" on their resume.
> People will experiment, and it's good for the industry to have new innovation, but there's really not that much danger of constantly shifting tech stacks unless your team and leadership don't know what they're doing - and if that's the case, you have bigger problems then the tech stack.
If you're switching a tech stack, by definition, you don't really know what you're doing. You're treading in unknown territory. You're spending real money for the promise of hopefully increasing productivity in the future. You are speculating.
I'm not saying this is a risk you should never take, there's a downside to never switching stacks too. The idea that you just need the right team and everything will be fine is a fantasy.
Of course there are a few teams (even in praised companies) that chase the fad, but they're the sames ones that do things like use CQRS and Kafka for a basic CRUD app.
Well, fair enough. I never claimed that businesses switch stacks "constantly" anyway. Still, at the industry level, there is constant flux - much more so than on other platforms. Unless you use one of the big players like React, chances are your framework of choice won't last and become legacy software quite soon.