11 ms·

It's just "JavaScript" in that it needs a translation layer and has a bunch of special syntax/semantics around reactive variables. Lol. I don't understand the

It's just "JavaScript" in that it needs a translation layer and has a bunch of special syntax/semantics around reactive variables. Lol. I don't understand the cult following around Svelte. There's a lot of magic and complexity hiding in there. At the end of the day state management is not trivial and something has to handle it. React doesn't impose a specific state solution which is what I like about it. But while React isn't perfect, Svelte is not the next step imho.

capableweb 3y ago
> I don't understand the cult following around Svelte. There's a lot of magic and complexity hiding in there. What's new is old again :) People started doing React because they got tired of mixing languages for logic, structure and styles, why not do it all in JS? They got tired of that, so why not separate them? They got tired of manually doing bindings, so now that's hidden behind abstractions ("Hello 2000s templating magic"). I wonder what they'll get tired of next.
- jbman223 3y ago
  Next is writing code entirely. Whatever has the most robust documentation will be the next big thing, since AI agents will be writing the code for the programmers.
  - teraflop 3y ago
    I'm concerned about the opposite possibility. All the effort will go into tweaking models and adjusting their training data until they generate acceptable output, and documentation for human consumption will be an afterthought.
    - codaphiliac 3y ago
      Wait till you fight a prompt to update the project in minor ways...
    - capableweb 3y ago
      > documentation for human consumption will be an afterthought. The documentation just changed a layer upwards in the abstraction ladder. Instead of docs for the code that runs on the machines, we'll write docs for the programs we've built that can generate the code that runs on the machines.
  - jes5199 3y ago
    honestly if this is what makes literate programming happen, I think it’s a win
- aleksandrm 3y ago
  You're still mixing HTML and CSS with JS, which is way worse if you ask me.
  - capableweb 3y ago
    My point being: If I ask you today, I'm very likely to get a difference answer compared to in 2-3 years, and if I wait yet again 2-3 years, another answer :)
gochi 3y ago
>There's a lot of magic and complexity hiding in there. That's kind of the point. It's for people who want that magic, not for people who are likely just going to start using Rust instead of continuing to force such rigidity and verbosity into JS/TS.
- Timon3 3y ago
  >> There's a lot of magic and complexity hiding in there. > That's kind of the point. But it goes against the title of this post: "You Don't Need to “Learn” Svelte: Embracing the Simplicity of JavaScript". If the point of Svelte is the magic, why tell people they don't need to learn anything? The magic isn't part of JavaScript, so they'll have to learn it.
  - gochi 3y ago
    I'm not a fan of the article either, I'm specifically referencing the comment that doesn't understand why people like Svelte.
_xivi 3y ago
> There's a lot of magic and complexity hiding in there I mean there's a lot of magic and complexity hidden in frameworks, interpreters, compilers, all the way down, not to mention browser engines. Or did I miss something?
- meiraleal 3y ago
  when you code in svelte you name the files .svelte, it can't be parsed as javascript. This is more than framework magic, it is a new language. You can't create a preact like framework based on svelte.
- gabereiser 3y ago
  Magic is only magic to the ignorant. Complexity is only complex because of humans (mostly). My issue with all of this is that vanilla is better than any framework. It’s fast, it’s has dependency trees, module loading, components, it works well with npm, and it doesn’t force me to learn yet another flavor of the same broken concept. >did I miss something? Yes, that all of this is just code…
  - _xivi 3y ago
    > My issue with all of this is that vanilla is better than any framework. Vanilla JS is an abstraction over something else which in turn an abstraction over another and so on... So your problem here isn't really with abstraction/magic/complexity in itself. You like a 5 layers cake, you think it's just perfect, a group copied the recipe and added a layer because they want to add another flavor. They didn't ruin your cake, they just have different taste.
    - gabereiser 3y ago
      My point is it’s all cake. Everything’s an abstraction on something.
LapsangGuzzler 3y ago
I’ve been using Svelte for a about 3 years on smaller visualization projects and it works really well in that context. Being able to declaratively define your UI behavior is massive for tools like D3js compared to the more traditional imperative JS style. This unlocks the ability to abstract your UI in really nice ways for defining complex visualization behavior. The other thing that I really like about Svelte is that’s a compiler and not a runtime framework. This keeps builds performant and makes it easy to import vanilla JS packages without needing framework-specific bindings I also find Svelte’s syntax to be very intuitive and easy to pick up. The Svelte REPL tutorial docs are some of the best I’ve seen as far as getting up to speed with the tooling. > React doesn't impose a specific state solution which is what I like about it. But while React isn't perfect, Svelte is not the next step imho. This one area where we’re going to disagree. Svelte feels more like Rails in that it ships with most of your basic utilities to build a UI, which allows the community to agree on a preferred solution to a given problem. I prefer this because it makes it easier to find solutions to problems that aren’t dependent on some package that I don’t have. Solution discoverability is a massive pain point in react compared to Rails, where there’s pretty uniform agreement on how to solve problems. All that said, I’ve never worked on a large commercial Svelte codebase so I can’t speak to the ways it which it becomes painful. For smaller projects, I find the DX to be far superior than react.
- fullstackchris 3y ago
  > smaller visualization projects ... works great in that context therein lies the entire drama too many people probably get into svelte and realize only too late that its not intended / useful for larger projects
  - LapsangGuzzler 3y ago
    Perhaps, but given the issues I’ve seen with the larger react codebases I’ve worked with around performance and shifting best practices, I wouldn’t necessarily write Svelte off without giving it a fair shot. It’s not like large React apps are much fun to work on either. Ultimately, big codebases are hard to manage, regardless of the language or framework. I don’t see a particular dealbreaker with Svelte compared to React in this regard.
ravenstine 3y ago
There's complexity in there, but magic? I'm not sure what you mean. Metaprogramming? The reactivity layer? Otherwise, it's hardly more complex than competing "frameworks". The internals of the rendering engine are a bit cryptic but are otherwise very straight forward to figure out if you want to add custom behavior.
- eyelidlessness 3y ago
  Reactive declarations using label syntax definitely qualify as magic. It’s clever, maybe even the good kind of clever, but it’s definitely magic. And it’s definitely not “just JavaScript”.
- meiraleal 3y ago
  $ and $:{} are magic and not a great one.
pier25 3y ago
> At the end of the day state management is not trivial and something has to handle it There are many critiques that can be argued about Svelte, but state management is certainly not one of them. Component reactivity seems magic but it's very predictable once you get the hang of it. And the productivity gains are immense compared to React. For application reactive state (outside components) you get reactive primitives for free without any dependency like MobX.
tescocles 3y ago
>I don't understand the cult following around Svelte. What I don't get is how I never (at least on HN) see any criticism of it. Like... never ever. And sure I've probably missed the odd negative post about it, but as someone who has never used it and whose entire knowledge of it is based on what I've read on here, I couldn't tell you a single supposed downside of using Svelte. And sure, it could just be That Good, but... I dunno? There's something off about that.
- shynrou 3y ago
  I tried using it 2 years ago on a mid complexity webapp and it blew up in my face as soon as things got a little more complex. The hidden mechanics of everything made it absolutely horrible to debug. Including some serverside rendering issues in the svelte code base at the time. The pain wasn't worth it in the end. I'm probably never gonna touch svelte again without having to. Similar experience with preact. It works till it doesn't.
- dminik 3y ago
  If you want to see some criticism of svelte, one of the core maintainers recently asked about some things that could be improved about svelte in the next major version: https://twitter.com/trueadm/status/1676694161188159490 https://twitter.com/trueadm/status/1676694161188159490 That should give you some rough ideas about the things that the community itself thinks need improvements.
  - rpbiwer2 3y ago
    I have no expectations, but I thought I might as well ask: do you know if there are any apps that will unroll a Twitter thread given a link like the one in your comment? The web version of Twitter no longer shows threads, and I've spent enough time scrolling through the shitty Twitter user page UI looking for old tweets that I'd really prefer an alternative if there is one.
- thomascgalvin 3y ago
  My team switched from React to Svelte a couple of years ago. We were working on new app, not refactoring or rewriting an old one, so we had the opportunity to choose whatever tooling we wanted. The whole team loved Svelte. It did the stuff React did, without a lot of the ceremony or boilerplate. It was easy for the junior devs to pick up, and powerful enough for the senior devs to what needed doing. We weren't pushing it very hard; the app was basically data entry and data display, and I assume that if you got deep enough into corner cases, it would break down like any other framework. But for our purposes, Svelte felt like someone had taken the time to understand React's issues, and fixed them.
alternatex 3y ago
Most front-end devs already use a translation layer - Typescript. So I don't understand the need to draw an arbitrary line between what can and cannot be used to make a good web application.
- spankalee 3y ago
  There's a big difference between adding types - which is essentially a linter - and semantic changes to the language.
  - alternatex 3y ago
    Alright but the types are a wholly different language and cannot be parsed by JavaScript linters. Same as Svelte. People need to learn Typescript in order to use it, it does not come naturally. I don't understand how the same argument cannot be applied for Typescript. I do remember people complaining about Typescript before it became popular. Eventually people understood it made their projects more maintainable and dropped the purist arguments that provide no value to the product.
deleted 3y ago
[deleted]

capableweb 3y ago

> I don't understand the cult following around Svelte. There's a lot of magic and complexity hiding in there. What's new is old again :) People started doing React because they got tired of mixing languages for logic, structure and styles, why not do it all in JS? They got tired of that, so why not separate them? They got tired of manually doing bindings, so now that's hidden behind abstractions ("Hello 2000s templating magic"). I wonder what they'll get tired of next.

jbman223 3y ago
Next is writing code entirely. Whatever has the most robust documentation will be the next big thing, since AI agents will be writing the code for the programmers.
- teraflop 3y ago
  I'm concerned about the opposite possibility. All the effort will go into tweaking models and adjusting their training data until they generate acceptable output, and documentation for human consumption will be an afterthought.
  - codaphiliac 3y ago
    Wait till you fight a prompt to update the project in minor ways...
  - capableweb 3y ago
    > documentation for human consumption will be an afterthought. The documentation just changed a layer upwards in the abstraction ladder. Instead of docs for the code that runs on the machines, we'll write docs for the programs we've built that can generate the code that runs on the machines.
- jes5199 3y ago
  honestly if this is what makes literate programming happen, I think it’s a win
aleksandrm 3y ago
You're still mixing HTML and CSS with JS, which is way worse if you ask me.
- capableweb 3y ago
  My point being: If I ask you today, I'm very likely to get a difference answer compared to in 2-3 years, and if I wait yet again 2-3 years, another answer :)

gochi 3y ago

>There's a lot of magic and complexity hiding in there. That's kind of the point. It's for people who want that magic, not for people who are likely just going to start using Rust instead of continuing to force such rigidity and verbosity into JS/TS.

Timon3 3y ago
>> There's a lot of magic and complexity hiding in there. > That's kind of the point. But it goes against the title of this post: "You Don't Need to “Learn” Svelte: Embracing the Simplicity of JavaScript". If the point of Svelte is the magic, why tell people they don't need to learn anything? The magic isn't part of JavaScript, so they'll have to learn it.
- gochi 3y ago
  I'm not a fan of the article either, I'm specifically referencing the comment that doesn't understand why people like Svelte.

_xivi 3y ago

> There's a lot of magic and complexity hiding in there I mean there's a lot of magic and complexity hidden in frameworks, interpreters, compilers, all the way down, not to mention browser engines. Or did I miss something?

meiraleal 3y ago
when you code in svelte you name the files .svelte, it can't be parsed as javascript. This is more than framework magic, it is a new language. You can't create a preact like framework based on svelte.
gabereiser 3y ago
Magic is only magic to the ignorant. Complexity is only complex because of humans (mostly). My issue with all of this is that vanilla is better than any framework. It’s fast, it’s has dependency trees, module loading, components, it works well with npm, and it doesn’t force me to learn yet another flavor of the same broken concept. >did I miss something? Yes, that all of this is just code…
- _xivi 3y ago
  > My issue with all of this is that vanilla is better than any framework. Vanilla JS is an abstraction over something else which in turn an abstraction over another and so on... So your problem here isn't really with abstraction/magic/complexity in itself. You like a 5 layers cake, you think it's just perfect, a group copied the recipe and added a layer because they want to add another flavor. They didn't ruin your cake, they just have different taste.
  - gabereiser 3y ago
    My point is it’s all cake. Everything’s an abstraction on something.

LapsangGuzzler 3y ago

I’ve been using Svelte for a about 3 years on smaller visualization projects and it works really well in that context. Being able to declaratively define your UI behavior is massive for tools like D3js compared to the more traditional imperative JS style. This unlocks the ability to abstract your UI in really nice ways for defining complex visualization behavior. The other thing that I really like about Svelte is that’s a compiler and not a runtime framework. This keeps builds performant and makes it easy to import vanilla JS packages without needing framework-specific bindings I also find Svelte’s syntax to be very intuitive and easy to pick up. The Svelte REPL tutorial docs are some of the best I’ve seen as far as getting up to speed with the tooling. > React doesn't impose a specific state solution which is what I like about it. But while React isn't perfect, Svelte is not the next step imho. This one area where we’re going to disagree. Svelte feels more like Rails in that it ships with most of your basic utilities to build a UI, which allows the community to agree on a preferred solution to a given problem. I prefer this because it makes it easier to find solutions to problems that aren’t dependent on some package that I don’t have. Solution discoverability is a massive pain point in react compared to Rails, where there’s pretty uniform agreement on how to solve problems. All that said, I’ve never worked on a large commercial Svelte codebase so I can’t speak to the ways it which it becomes painful. For smaller projects, I find the DX to be far superior than react.

fullstackchris 3y ago
> smaller visualization projects ... works great in that context therein lies the entire drama too many people probably get into svelte and realize only too late that its not intended / useful for larger projects
- LapsangGuzzler 3y ago
  Perhaps, but given the issues I’ve seen with the larger react codebases I’ve worked with around performance and shifting best practices, I wouldn’t necessarily write Svelte off without giving it a fair shot. It’s not like large React apps are much fun to work on either. Ultimately, big codebases are hard to manage, regardless of the language or framework. I don’t see a particular dealbreaker with Svelte compared to React in this regard.

ravenstine 3y ago

There's complexity in there, but magic? I'm not sure what you mean. Metaprogramming? The reactivity layer? Otherwise, it's hardly more complex than competing "frameworks". The internals of the rendering engine are a bit cryptic but are otherwise very straight forward to figure out if you want to add custom behavior.

eyelidlessness 3y ago
Reactive declarations using label syntax definitely qualify as magic. It’s clever, maybe even the good kind of clever, but it’s definitely magic. And it’s definitely not “just JavaScript”.
meiraleal 3y ago
$ and $:{} are magic and not a great one.

pier25 3y ago

> At the end of the day state management is not trivial and something has to handle it There are many critiques that can be argued about Svelte, but state management is certainly not one of them. Component reactivity seems magic but it's very predictable once you get the hang of it. And the productivity gains are immense compared to React. For application reactive state (outside components) you get reactive primitives for free without any dependency like MobX.

tescocles 3y ago

>I don't understand the cult following around Svelte. What I don't get is how I never (at least on HN) see any criticism of it. Like... never ever. And sure I've probably missed the odd negative post about it, but as someone who has never used it and whose entire knowledge of it is based on what I've read on here, I couldn't tell you a single supposed downside of using Svelte. And sure, it could just be That Good, but... I dunno? There's something off about that.

shynrou 3y ago
I tried using it 2 years ago on a mid complexity webapp and it blew up in my face as soon as things got a little more complex. The hidden mechanics of everything made it absolutely horrible to debug. Including some serverside rendering issues in the svelte code base at the time. The pain wasn't worth it in the end. I'm probably never gonna touch svelte again without having to. Similar experience with preact. It works till it doesn't.
dminik 3y ago
If you want to see some criticism of svelte, one of the core maintainers recently asked about some things that could be improved about svelte in the next major version: https://twitter.com/trueadm/status/1676694161188159490 https://twitter.com/trueadm/status/1676694161188159490 That should give you some rough ideas about the things that the community itself thinks need improvements.
- rpbiwer2 3y ago
  I have no expectations, but I thought I might as well ask: do you know if there are any apps that will unroll a Twitter thread given a link like the one in your comment? The web version of Twitter no longer shows threads, and I've spent enough time scrolling through the shitty Twitter user page UI looking for old tweets that I'd really prefer an alternative if there is one.
thomascgalvin 3y ago
My team switched from React to Svelte a couple of years ago. We were working on new app, not refactoring or rewriting an old one, so we had the opportunity to choose whatever tooling we wanted. The whole team loved Svelte. It did the stuff React did, without a lot of the ceremony or boilerplate. It was easy for the junior devs to pick up, and powerful enough for the senior devs to what needed doing. We weren't pushing it very hard; the app was basically data entry and data display, and I assume that if you got deep enough into corner cases, it would break down like any other framework. But for our purposes, Svelte felt like someone had taken the time to understand React's issues, and fixed them.

alternatex 3y ago

Most front-end devs already use a translation layer - Typescript. So I don't understand the need to draw an arbitrary line between what can and cannot be used to make a good web application.

spankalee 3y ago
There's a big difference between adding types - which is essentially a linter - and semantic changes to the language.
- alternatex 3y ago
  Alright but the types are a wholly different language and cannot be parsed by JavaScript linters. Same as Svelte. People need to learn Typescript in order to use it, it does not come naturally. I don't understand how the same argument cannot be applied for Typescript. I do remember people complaining about Typescript before it became popular. Eventually people understood it made their projects more maintainable and dropped the purist arguments that provide no value to the product.

deleted 3y ago

[deleted]