Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Thoughts on Svelte

tyhopp.com

Post reply on HN
Print view View original

141–150 of 194 posts

Re: Thoughts on Svelte

#141

Post by rk06 »

muyuu wrote: post #74
fenomas wrote: post #26

I switched my game's UI from Vue2 to Svelte maybe a year ago, and I agree with almost all of the article. One thing I think the author overlooks: the appeal of Svelte's built-in animations and transitions is that they work correctly when the element's lifecycle is being managed by Svelte. E.g. with code like this: {#if showFoo} Foo! {/if} When `showFoo` changes to false, Svelte will first play a flyout transition and…

given that Svelte aims to be mainly pre-processed, how hard is it to combine it with more real-time solutions like Vue for instance? (you mention that you migrated from Vue2) is it possible to use Svelte more for client-only or client-mainly views, and use other solutions for stuff that communicates more with the back-end? or do they get into each other's way?

Svelte is compiled, but not compiled to html. It is compiled to js. It works like any other client side js framework like react/vue

Re: Thoughts on Svelte

#142

Post by ttfkam »

dimmke wrote: post #39
TechBro8615 wrote: post #10

Earlier quoted context omitted.

What makes something good for small projects? Does that mean it's not good for big projects? What's the difference between big and small projects that makes Svelte good for one and bad for the other?

Svelte doesn't use a virtual DOM and when it compiles, it only targets what you are specifically using it for. The thing with Svelte is that for a big project (like an SPA) you're going to end up using SvelteKit, because that's where all the development focus is for things like routing etc... and SvelteKit isn't nearly as settled. As in, there aren't developed "patterns" for doing a lot of things yet so it's a lot of…

Honestly, SvelteKit is pretty solid. They took their time trying to make consistent decisions rather than rushing 1.0 out the door and trying to backtrack later. All design decisions were out in the open on GitHub issues, and they spent a really long time looking at other frameworks and what they got right and wrong. The lack of navel gazing was refreshing.

Re: Thoughts on Svelte

#143

Post by Rapzid »

A lot of the pluses mentioned are things I really enjoyed about Vue. The bind system works great for syncing inputs to arbitrary reactive objects(or not reactive), the in-built transition support, the event system, and I don't know if Svelte has this but Vue's async component factory support is fantastically useful.

Just can't get on board with yet another compiler and string template language. Towards the end of my time with Vue I was favoring JSX more and more. The VSCode Vue extension of choice at the time(this was a couple years ago) was Vetur and they really struggled with performance regressions and great intellisense support.

These libraries with their custom string templates I expect to really struggle to achieve and maintain the level of tooling support I've come to expect. And even if they can; why god, why another custom language requiring a pre-compiler? Felt like we were finally getting out of that a bit with fall of coffeescript, SASS falling out of favor due to the performance issues, babel falling by the wayside in favor of fast SWC or Esbuild with the death of IE and the rise of greenfield browsers.

IMHO MobX has shown us how fine grain reactivity can be accomplished with proxies ages ago; with great DX. SolidJS is showing us what can be done without a compiler(it does some light JSX transformation but AFIAK it doesn't have too and there is no custom language). Vue has made most of the goodness of their string template syntax available in JSX via the newish attribute extensions.

Why do we need another string template language? Why another compiler? React Optimizing Compiler? This is not the way.

Re: Thoughts on Svelte

#144

Post by ttfkam »

willio58 wrote: post #7

Thanks for this overview, I definitely had some svelte fomo and now I’m feeling better in a react land.

So rather than fearing you're missing out, you went back to React to make sure you were missing out? ;-)

Life is too short for constantly writing boilerplate and performance analysis on a virtual DOM. Don't fall victim to Stockholm Syndrome.

Re: Thoughts on Svelte

#145

Post by Pr0ject217 »

"The $ label is one technical reason why I would be hesitant to adopt Svelte for larger projects. It's a core part of Svelte that you can't always avoid, and I think the potential for introducing bugs through it is high to start and very high at scale."

At work, we use Svelte throughout our entire FE platform in many SPA micro-frontends, on both the web and mobile (w/ Cordova). We have 10,000+ daily active users. Our team has used Svelte in production for a few years. All of our developers learned it during the coding interview project, and on the job. It's fun and enjoyable to use.

I disagree strongly with this statement (not using it in production because of the reactive syntax). Reactive-blocks will trigger an update if their direct top-level dependencies change, not if one of their dependencies change from within a new scope/block (e.g. function-call) - that's all. Also, we only use reactive statements when we need to - we typically use data-binding instead.

Re: Thoughts on Svelte

#146

Post by schwartzworld »

azangru wrote: post #111
schwartzworld wrote: post #66

Earlier quoted context omitted.

> what if you only want to perform a side effect when a particular value changes? https://react.dev/reference/react/useEffect That is literally what useEffect is for! Describe your side effect, provide a list of values that you want the hook to watch for when they change. `useEffect(someEffect, [value1, value2, value3])` > the very natural, and often inevitable, concept of side effects React uses a functional program…

> That is literally what useEffect is for! No, sorry; for useEffect to fire, a prop or a state needs to change; which means that the component is going to re-render. My point is that sometimes we want to observe properties passed to the component for side-effect purposes without re-rendering the component. > Functional programmers believe in minimizing side effects. In order to do something — anything — in the real w…

>> Functional programmers believe in minimizing side effects.

> In order to do something — anything — in the real world, we need side effects. Even Haskellers know this :-)

Hence the use of the word "minimize"

Re: Thoughts on Svelte

#147

Post by rk06 »

dmix wrote: post #110
h4ch1 wrote: post #83

Earlier quoted context omitted.

I think this is what you're talking about ? https://chrome.google.com/webstore/detail/solid-devtools/kmc...

Is there something similar for Vue?

I don’t think vue devtools have this capability. But if you are facing issues with large Vue components, then you should split it into smaller components. And use composables(vue hooks) to split js logic. That will get you quite far

Re: Thoughts on Svelte

#148

Post by satvikpendem »

ttfkam wrote: post #127
lozenge wrote: post #27

Earlier quoted context omitted.

You shouldn't use useEffect just to bring state mutations from the store into the component or to calculate "view model" from your state. Have a look at the new react docs. https://react.dev/learn/you-might-not-need-an-effect

Or… y'know… just stop worrying about niggling details like this and just use Svelte. Svelte out of the box is much faster than React. You have to be well down the road of optimization before you hit parity, and optimized is almost never easier to understand. Computers don't care about code. They're satisfied with 1s and 0s. Code is for humans. The cleaner, the simpler, and the less of it, the better. More code = more…

I won't use Svelte for the simple reason that I don't like templating languages. Same reason I switched from Vue to React.

Re: Thoughts on Svelte

#149

Post by robertoandred »

ttfkam wrote: post #123
davidjfelix wrote: post #30

I think Svelte/sveltekit (especially) has really pushed a lot of the ecosystem forward and I love the effort made to exposing platform primatives more explicitly while attempting to make the framework disappear. I think the store mechanism is really great but I have noticed a few usability complaints coming from react land. The main one for me is typing props for a component feels extremely wack. In react I have a fu…

It's what you consider central in a framework. For React, JS/TS is king. All markup and all CSS is subsumed in JS/TS. In Svelte, HTML/CSS is king, with the bare minimum of JS/TS necessary for any given task. With that in mind, of course React tends toward type definitions. Also explains why Svelte tends toward markup-oriented definitions.

React doesn’t care where or how you have your CSS.

Re: Thoughts on Svelte

#150

Post by hbrn »

seanwilson wrote: post #32

What's a good frontend setup right now if you want strong static typing? I know Vue 3 supports TypeScript for example but it doesn't look like that's their core audience? I don't get the appeal of frameworks introducing template tags like `{#if showFoo}` vs JSX personally. You have the learn new syntax for things you already know how to do in JavaScript but with less expressibility, and JSX can at least be type check…

"you have the learn new syntax" is a really weird argument. Every approach, be it Vue, Svelte or React introduces a new alien syntax. In my personal opinion React approach is the most alien.

React's "it's just Javascript" mantra is a manipulation that only gullible folks will fall for: you can't just add a bunch of stuff to Javascript and then claim "it's just Javascript". If I throw a piece of steak in your coffee, you won't consider it "just coffee" anymore. And certainly you can't claim you're still a vegetarian after consuming that "cup of coffee".

I personally find it much harder to reason about the weird

  condition &&
syntax, compared to perfectly reasonable

  {#if condition}
    
  {/if}
The latter so readable that it can even be understood by a non-engineer. The "new syntax" is as close to natural language as it gets.

Understanding the final layout is much harder in React.

That said, custom template syntax has indentation issue (you typically want indent both HTML elements and custom template tags, so anything inside conditions/loops has double indentation), so I actually think Vue template syntax () offers the best tradeoffs.

But regardless, at least when I'm looking at all 3 options, I see their tradeoffs and making an informed choice. React folks typically fail to even understand that there are tradeoffs. Even if you buy the "it's just Javascript" mantra, Javascript was never a good option represent a document layout.

Post reply on HN