9 ms·

Svelte is a language

129 points by r0xsh 3y ago

turtleyacht 3y ago
> Svelte is a language. All Javascript frameworks may become implementations of SAT solvers, where rendering and state are scheduled constraints, i.e. tiny operating systems. NPM uses CSS as a query language - https://news.ycombinator.com/item?id=33136843 https://news.ycombinator.com/item?id=33136843 - 9 months ago Then apps may be instantiations of the framework.
- anonzzzies 3y ago
  They should be SAT solvers, but people also want them to be vague and super flexible. Many people I know responded to Apple UI constraints (what was the name again?) with ‘what am I, a math professor?’. People want throw poop against a wall and smear it around and when they are happy with their work, they want to press a button and get the absolute optimal result that fits their broadest use case. No different from what most non-frontend developers want by the way. Problem is; that is not yet possible at all, because ‘the spec’ is too vague and strictness generated from vagueness will either be just vagueness (cannot find any constraints to throw into a solver so just leave it) or too strict (where many cases simply are suddenly forbidden that were actually feasible cases by the author).
gervwyk 3y ago
Great insight. It feels like at some point reactivity as a language primitive should be built into js. Most frameworks start with this and then build out into a opinionated implementation, dissolving the ecosystem into framework fragments. Any known reasons why this is / was never implemented?
- rcme 3y ago
  Or maybe one day people will realize render functions explicitly listening to event emitters is actually a better pattern than implicit reactivity.
  - mst 3y ago
    Certainly I've had a lot of fun with wiring mobx up to various things that provide render functions (react with mobx viewstate classes is way nicer than hooks to me). Svelte I've never quite got the hang of to the point where I feel comfortable expressing an opinion about it (and I haven't spent enough time experimenting to claim my not having got the hang of it yet means anything either).
    - imbnwa 3y ago
      Mobx as your ViewModel/Model selector implementation is precisely where it belongs in your stack. You just need to be disciplined and not build your whole state/update loop on it. Sadly, I'm stuck on v4.5.x at work, and my big complaint is arrays not being a first-class observable.
      - mst 3y ago
        > You just need to be disciplined and not build your whole state/update loop on it. If you have a minute, I'd love you to expand on that. I have some thoughts along those lines myself but I suspect you've spent more time with mobx than I have and would rather hear yours from cold. (I also keep looking at mobx-state-tree and wondering if that would work for me, I'm not sure I know enough to judge what the trade-offs involved are particularly well)
  - bluefirebrand 3y ago
    Event emitters/listeners are entirely too magical and borderline impossible to write automated tests for imo. I don't think that's a good direction to go.
  - WorldMaker 3y ago
    I think it is a shame that the Observable proposal [1] still seems somewhat stuck in Stage 1. It's a better idea than just raw event emitters because of composability (if no other reason). Making Observables "first class" could go a long way to unifying a lot of reactivity patterns in various frameworks, in theory at least. To be fair, Observables and especially Observable composition has a rough learning curve and many frameworks like Svelte intentionally prefer implict reactivity and avoiding things like explicit Observables because they are seen as too complex/"too hard" for the average developer. (Then you get awful worst of both worlds frameworks like Angular that sort of rely on Observables but yet also don't trust teaching Observables and wind up with code that isn't properly Observable and so also has all the code for implicit reactivity and is full of nasty escape hatches that cause all sorts of composition problems and unnecessary side effects.) [1] https://github.com/tc39/proposal-observable https://github.com/tc39/proposal-observable
- paulddraper 3y ago
  https://dev.to/this-is-learning/the-evolution-of-signals-in-javascript-8ob https://dev.to/this-is-learning/the-evolution-of-signals-in-...
- recursive 3y ago
  You can pretty much do it with proxys.
mark38848 3y ago
If you want a good language that turns into Javascript I recommend PureScript
- klntsky 3y ago
  True, but PS is general purpose while Svelte is a DSL. They did a good job at creating a non-invasive DSL that JS developers can use without much learning
- tru1ock 3y ago
  I did a stint of Elm and it taught me a lot. But I found I prefer dirtier languages like elixir and typescript. I would not recommend the pure languages for anything other than learning FP.
amadeuspagel 3y ago
I love the idea of "thinking inside the box". It's a great encapsulation of the hacker mindset. A fun talk about it in another context (impro theater): https://www.youtube.com/watch?v=bz9mo4qW9bc https://www.youtube.com/watch?v=bz9mo4qW9bc
justin_kempton 3y ago
[dead]
xrd 3y ago
The really exciting thing about svelte is getting rid of the virtual Dom. Having everything just be explicit JavaScript code that modifies the Dom manually makes for really readable code. If you have not tried it, got to the svelte tutorial and look at the output code. It's awesome.
- ryan29 3y ago
  I haven't used Svelte beyond a couple toy tutorials, but, for me, the infrastructure adapters [1] are the most exciting thing. I love the idea of being able to build using Svelte and auto-magically deploy to something like Cloudflare Pages without completely giving up the potential to deploy somewhere else. 1. https://kit.svelte.dev/docs/adapters https://kit.svelte.dev/docs/adapters
  - xrd 3y ago
    I've got mixed feelings about this and I'm sure I'm in the minority. Those adapters are usually supported by the commercial company that wants you to use them. But, for example, the static or node adapters often don't work great with the important parts of svelte kit like SSR, and feel like second class citizens. I love svelte but I'm having a hard time getting the same development ergonomics out of svelte kit. It's probably just me.
    - benmccann 3y ago
      adapter-static is meant for generating fully static sites. It's fundamentally not aiming to and cannot support SSR in that context. However, SSR is fully supported in adapter-node, which is well maintained.
  - threatofrain 3y ago
    Infrastructure adapters are becoming table stakes for frontend frameworks.
    - mcintyre1994 3y ago
Tade0 3y ago
Using the label and block syntax for this was a stroke of genius. Two great things about this "thinking inside the box" approach are: 1. You're encouraged to use native APIs because they're highly unlikely to clash with the framework. 2. You can a legible stack trace. After all, the only thing the compiler does to your JavaScript is add some instrumentation here and there.
fastball 3y ago
(2019), since there is a reference to "Svelte 3 around the corner" that is confusing otherwise.
- farazzz 3y ago
  Omg I was confused because the Gist also said “Last active 23 minutes ago” which I thought was the last edited/created time
rmrfchik 3y ago
Give a quick glance to Svelte. Help me understand, how this syntax {#if expression}...{:else if expression}...{/if} can be seriously invented in our... more civilized age?
- doctor_eval 3y ago
  How would you do it?
  - rmrfchik 3y ago
    I don't know should I stick to mustaches (it can be dictated by other reasons), but if I should: {#if expr} {#elseif expr} {#endif}
    - doctor_eval 3y ago
      These sigils seem to exist to make it easier to balance the expressions. I personally find {#if} … {/if} much more intuitive. {:else} is an unfortunate compromise necessitated by the fact that elseif is ugly in most imperative languages.
  - willmartian 3y ago
    I much prefer keeping everything XML-ish: https://www.solidjs.com/docs/latest/api#switchmatch https://www.solidjs.com/docs/latest/api#switchmatch
- farazzz 3y ago
  It’s not the most pretty syntax, but it’s wayyy better than React’s terrible (expression ? … : …) or (expression && …)
  - MobiusHorizons 3y ago
    react didn't invent that syntax. This is a standard piece of C like syntax that most (but not all) languages with curly braces share. JSX/TSX used in react don't make this choice for you, you can use any javascript syntax which can be used when passing a value (eg in a function invocation, or variable declaration). If you don't like it, you are perfectly free to declare a variable and set its value using a regular if / else block and use it directly from the template. My point is this is not a syntax decision that React made, but svelte's syntax was (as far as I can tell) a decision.
monero-xmr 3y ago
Svelte is a major improvement on vuejs. It is a pleasure to work with. I can’t stand react / JSX. Highly recommend anyone who preferred vue over react to give svelte a try.
- arpowers 3y ago
  Specifics needed (please)
  - monero-xmr 3y ago
    One thing is that sveltekit is a “batteries included” opinionated framework. Everything you need is there, the docs are excellent, you don’t need to make any decisions to get the fundamentals of routing, stores, directory structure, and other basic things working. This is the opposite of the traditional nodejs / JavaScript ecosystem of selecting a hodge podge of libs to get even a minimal thing going.
- lf-non 3y ago
  I disagree. But I am someone who deals with frontend tech sporadically as opposed to spending all/most of my time working on UI. I was excited about svelte, but have found that coming back to my svelte project after a month or two of not using it was arduous because of all the myriad language level things. There are just too many little svelte specific things to keep track of in head. In contrast coming back to a react/vue project is much easier for me, because even if I forget something at the end of the day any vue-directive or react hook is just another js/ts api I can easily lookup. In particular, I find the DX that volar+vscode offer in a project with vue3, composition API & pug templates to be better than anything else I have seen in the FE ecosystem in last 5 years. I also don't find the enhancements for local reactivity to be major value additions because most of the times my state resides in a shared store. I find the vue reactivity model to be simpler to deal with because I can create shared stores which can be (deep) mutated from any component and it all just works seamlessly.
  - evnix 3y ago
    I've done a lot of contracting jobs and I get to see a lot of codebases and had the exact opposite experience, Whenever I see react or vue code, and in particular react, I feel like I have to relearn everything because the combination of external state libraries and to top it with translation specific code and libraries makes it such that each code base is very different from the other. It almost feels like you are learning a new framework altogether. The other issue is not directly related but because there are so many external dependencies, there is this constant slog work to keep everything updated due to constant vulnerabilities that keep popping in our CI tool. Familiarity wise Angular has been probably the easiest to jump into and maintain long term, but it is a pain to work with due to the amount of ceremony involved to do even the simplest of things. Svelte codebases due to the very nature of Svelte are simpler and very straightforward to get into, there are some svelte specific things but they aren't too many of them and are simpler to reason about when compared to codebases built on hooks, and even worse are hooks in combination with junior Devs. It is very very easy to write bad react code and you see this way way too often. Most react code out in the wild is badly written, you don't see problems because the browsers and modern computers are performant enough to hide them away but you do notice as the codebase grows and you realize it too late that the very foundation was wrong. I don't mind Vue and just see svelte as a nicer DSL over it.
yamrzou 3y ago
(2018)
lakomen 3y ago
Svelte Kit is great for static is "classic"-like websites. I've converted my company website to svelte-kit from first Angular, then Vue. But for SPA it's bad. If you use oidc auth. There's only Auth.JS and it's a confidential client, for Svelte Kit. If you're not using svelte-kit you can use vite to create a Svelte SPA. There you can use your PCKE client as usual and burden the load on the client. I have yet to experiment with how well it works with a graphql client. Apollo has its own cache but I'm not sure there is a svelte version of it. There is for Vue. Does it even need one? The default is for React. Is Apollo even needed? Questions over questions. Why Svelte? Performance. Performance matters, a lot. Svelte being a "language". First time using a template system? I have to wonder.
- wg0 3y ago
  SevelteKit has some rough corners. The debugging is not as smooth especially because these frontend frameworks needlessly insists on being server side framework first for no reason specifically because server side frameworks have very strong, battle tested options ranging from Django, Flask, echo, Rails, sinatra and what not. This makes tooling complicated and a debugging that works out of the box for both server and client side is non existent even in SvelteKit 4. When I'm picking up SvelteKit, it's only for its routing which isn't so great either with file based arrangements, things get out of and pretty fast.
- mrklol 3y ago
  you can still use your own backend for all of the business logic which is maybe easier than doing it in svelte directly.
blabla1224 3y ago
I wish people stopped calling websites as applications and I wish web site developers spent more time learning how the world has been building great desktop apps for years. It’s just beneficial to get out of the bubble once in awhile to validate certain ideas

129 points by r0xsh 3y ago

> Svelte is a language. All Javascript frameworks may become implementations of SAT solvers, where rendering and state are scheduled constraints, i.e. tiny operating systems. NPM uses CSS as a query language - https://news.ycombinator.com/item?id=33136843 https://news.ycombinator.com/item?id=33136843 - 9 months ago Then apps may be instantiations of the framework.

anonzzzies 3y ago
They should be SAT solvers, but people also want them to be vague and super flexible. Many people I know responded to Apple UI constraints (what was the name again?) with ‘what am I, a math professor?’. People want throw poop against a wall and smear it around and when they are happy with their work, they want to press a button and get the absolute optimal result that fits their broadest use case. No different from what most non-frontend developers want by the way. Problem is; that is not yet possible at all, because ‘the spec’ is too vague and strictness generated from vagueness will either be just vagueness (cannot find any constraints to throw into a solver so just leave it) or too strict (where many cases simply are suddenly forbidden that were actually feasible cases by the author).

gervwyk 3y ago

Great insight. It feels like at some point reactivity as a language primitive should be built into js. Most frameworks start with this and then build out into a opinionated implementation, dissolving the ecosystem into framework fragments. Any known reasons why this is / was never implemented?

rcme 3y ago
Or maybe one day people will realize render functions explicitly listening to event emitters is actually a better pattern than implicit reactivity.
- mst 3y ago
  Certainly I've had a lot of fun with wiring mobx up to various things that provide render functions (react with mobx viewstate classes is way nicer than hooks to me). Svelte I've never quite got the hang of to the point where I feel comfortable expressing an opinion about it (and I haven't spent enough time experimenting to claim my not having got the hang of it yet means anything either).
  - imbnwa 3y ago
    Mobx as your ViewModel/Model selector implementation is precisely where it belongs in your stack. You just need to be disciplined and not build your whole state/update loop on it. Sadly, I'm stuck on v4.5.x at work, and my big complaint is arrays not being a first-class observable.
    - mst 3y ago
      > You just need to be disciplined and not build your whole state/update loop on it. If you have a minute, I'd love you to expand on that. I have some thoughts along those lines myself but I suspect you've spent more time with mobx than I have and would rather hear yours from cold. (I also keep looking at mobx-state-tree and wondering if that would work for me, I'm not sure I know enough to judge what the trade-offs involved are particularly well)
- bluefirebrand 3y ago
  Event emitters/listeners are entirely too magical and borderline impossible to write automated tests for imo. I don't think that's a good direction to go.
- WorldMaker 3y ago
  I think it is a shame that the Observable proposal [1] still seems somewhat stuck in Stage 1. It's a better idea than just raw event emitters because of composability (if no other reason). Making Observables "first class" could go a long way to unifying a lot of reactivity patterns in various frameworks, in theory at least. To be fair, Observables and especially Observable composition has a rough learning curve and many frameworks like Svelte intentionally prefer implict reactivity and avoiding things like explicit Observables because they are seen as too complex/"too hard" for the average developer. (Then you get awful worst of both worlds frameworks like Angular that sort of rely on Observables but yet also don't trust teaching Observables and wind up with code that isn't properly Observable and so also has all the code for implicit reactivity and is full of nasty escape hatches that cause all sorts of composition problems and unnecessary side effects.) [1] https://github.com/tc39/proposal-observable https://github.com/tc39/proposal-observable
paulddraper 3y ago
https://dev.to/this-is-learning/the-evolution-of-signals-in-javascript-8ob https://dev.to/this-is-learning/the-evolution-of-signals-in-...
recursive 3y ago
You can pretty much do it with proxys.

mark38848 3y ago

If you want a good language that turns into Javascript I recommend PureScript

klntsky 3y ago
True, but PS is general purpose while Svelte is a DSL. They did a good job at creating a non-invasive DSL that JS developers can use without much learning
tru1ock 3y ago
I did a stint of Elm and it taught me a lot. But I found I prefer dirtier languages like elixir and typescript. I would not recommend the pure languages for anything other than learning FP.

amadeuspagel 3y ago

I love the idea of "thinking inside the box". It's a great encapsulation of the hacker mindset. A fun talk about it in another context (impro theater): https://www.youtube.com/watch?v=bz9mo4qW9bc https://www.youtube.com/watch?v=bz9mo4qW9bc

justin_kempton 3y ago

[dead]

xrd 3y ago

The really exciting thing about svelte is getting rid of the virtual Dom. Having everything just be explicit JavaScript code that modifies the Dom manually makes for really readable code. If you have not tried it, got to the svelte tutorial and look at the output code. It's awesome.

ryan29 3y ago
I haven't used Svelte beyond a couple toy tutorials, but, for me, the infrastructure adapters [1] are the most exciting thing. I love the idea of being able to build using Svelte and auto-magically deploy to something like Cloudflare Pages without completely giving up the potential to deploy somewhere else. 1. https://kit.svelte.dev/docs/adapters https://kit.svelte.dev/docs/adapters
- xrd 3y ago
  I've got mixed feelings about this and I'm sure I'm in the minority. Those adapters are usually supported by the commercial company that wants you to use them. But, for example, the static or node adapters often don't work great with the important parts of svelte kit like SSR, and feel like second class citizens. I love svelte but I'm having a hard time getting the same development ergonomics out of svelte kit. It's probably just me.
  - benmccann 3y ago
    adapter-static is meant for generating fully static sites. It's fundamentally not aiming to and cannot support SSR in that context. However, SSR is fully supported in adapter-node, which is well maintained.
- threatofrain 3y ago
  Infrastructure adapters are becoming table stakes for frontend frameworks.
  - mcintyre1994 3y ago

Tade0 3y ago

Using the label and block syntax for this was a stroke of genius. Two great things about this "thinking inside the box" approach are: 1. You're encouraged to use native APIs because they're highly unlikely to clash with the framework. 2. You can a legible stack trace. After all, the only thing the compiler does to your JavaScript is add some instrumentation here and there.

fastball 3y ago

(2019), since there is a reference to "Svelte 3 around the corner" that is confusing otherwise.

farazzz 3y ago
Omg I was confused because the Gist also said “Last active 23 minutes ago” which I thought was the last edited/created time

rmrfchik 3y ago

Give a quick glance to Svelte. Help me understand, how this syntax {#if expression}...{:else if expression}...{/if} can be seriously invented in our... more civilized age?

doctor_eval 3y ago
How would you do it?
- rmrfchik 3y ago
  I don't know should I stick to mustaches (it can be dictated by other reasons), but if I should: {#if expr} {#elseif expr} {#endif}
  - doctor_eval 3y ago
    These sigils seem to exist to make it easier to balance the expressions. I personally find {#if} … {/if} much more intuitive. {:else} is an unfortunate compromise necessitated by the fact that elseif is ugly in most imperative languages.
- willmartian 3y ago
  I much prefer keeping everything XML-ish: https://www.solidjs.com/docs/latest/api#switchmatch https://www.solidjs.com/docs/latest/api#switchmatch
farazzz 3y ago
It’s not the most pretty syntax, but it’s wayyy better than React’s terrible (expression ? … : …) or (expression && …)
- MobiusHorizons 3y ago
  react didn't invent that syntax. This is a standard piece of C like syntax that most (but not all) languages with curly braces share. JSX/TSX used in react don't make this choice for you, you can use any javascript syntax which can be used when passing a value (eg in a function invocation, or variable declaration). If you don't like it, you are perfectly free to declare a variable and set its value using a regular if / else block and use it directly from the template. My point is this is not a syntax decision that React made, but svelte's syntax was (as far as I can tell) a decision.

monero-xmr 3y ago

Svelte is a major improvement on vuejs. It is a pleasure to work with. I can’t stand react / JSX. Highly recommend anyone who preferred vue over react to give svelte a try.

arpowers 3y ago
Specifics needed (please)
- monero-xmr 3y ago
  One thing is that sveltekit is a “batteries included” opinionated framework. Everything you need is there, the docs are excellent, you don’t need to make any decisions to get the fundamentals of routing, stores, directory structure, and other basic things working. This is the opposite of the traditional nodejs / JavaScript ecosystem of selecting a hodge podge of libs to get even a minimal thing going.
lf-non 3y ago
I disagree. But I am someone who deals with frontend tech sporadically as opposed to spending all/most of my time working on UI. I was excited about svelte, but have found that coming back to my svelte project after a month or two of not using it was arduous because of all the myriad language level things. There are just too many little svelte specific things to keep track of in head. In contrast coming back to a react/vue project is much easier for me, because even if I forget something at the end of the day any vue-directive or react hook is just another js/ts api I can easily lookup. In particular, I find the DX that volar+vscode offer in a project with vue3, composition API & pug templates to be better than anything else I have seen in the FE ecosystem in last 5 years. I also don't find the enhancements for local reactivity to be major value additions because most of the times my state resides in a shared store. I find the vue reactivity model to be simpler to deal with because I can create shared stores which can be (deep) mutated from any component and it all just works seamlessly.
- evnix 3y ago
  I've done a lot of contracting jobs and I get to see a lot of codebases and had the exact opposite experience, Whenever I see react or vue code, and in particular react, I feel like I have to relearn everything because the combination of external state libraries and to top it with translation specific code and libraries makes it such that each code base is very different from the other. It almost feels like you are learning a new framework altogether. The other issue is not directly related but because there are so many external dependencies, there is this constant slog work to keep everything updated due to constant vulnerabilities that keep popping in our CI tool. Familiarity wise Angular has been probably the easiest to jump into and maintain long term, but it is a pain to work with due to the amount of ceremony involved to do even the simplest of things. Svelte codebases due to the very nature of Svelte are simpler and very straightforward to get into, there are some svelte specific things but they aren't too many of them and are simpler to reason about when compared to codebases built on hooks, and even worse are hooks in combination with junior Devs. It is very very easy to write bad react code and you see this way way too often. Most react code out in the wild is badly written, you don't see problems because the browsers and modern computers are performant enough to hide them away but you do notice as the codebase grows and you realize it too late that the very foundation was wrong. I don't mind Vue and just see svelte as a nicer DSL over it.

yamrzou 3y ago

(2018)

lakomen 3y ago

Svelte Kit is great for static is "classic"-like websites. I've converted my company website to svelte-kit from first Angular, then Vue. But for SPA it's bad. If you use oidc auth. There's only Auth.JS and it's a confidential client, for Svelte Kit. If you're not using svelte-kit you can use vite to create a Svelte SPA. There you can use your PCKE client as usual and burden the load on the client. I have yet to experiment with how well it works with a graphql client. Apollo has its own cache but I'm not sure there is a svelte version of it. There is for Vue. Does it even need one? The default is for React. Is Apollo even needed? Questions over questions. Why Svelte? Performance. Performance matters, a lot. Svelte being a "language". First time using a template system? I have to wonder.

wg0 3y ago
SevelteKit has some rough corners. The debugging is not as smooth especially because these frontend frameworks needlessly insists on being server side framework first for no reason specifically because server side frameworks have very strong, battle tested options ranging from Django, Flask, echo, Rails, sinatra and what not. This makes tooling complicated and a debugging that works out of the box for both server and client side is non existent even in SvelteKit 4. When I'm picking up SvelteKit, it's only for its routing which isn't so great either with file based arrangements, things get out of and pretty fast.
mrklol 3y ago
you can still use your own backend for all of the business logic which is maybe easier than doing it in svelte directly.

blabla1224 3y ago

I wish people stopped calling websites as applications and I wish web site developers spent more time learning how the world has been building great desktop apps for years. It’s just beneficial to get out of the bubble once in awhile to validate certain ideas