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

Svelte 4

svelte.dev

Post reply on HN
Print view View original

151–160 of 227 posts

Re: Svelte 4

#151

Post by benmccann »

jankiel wrote: post #147
Capricorn2481 wrote: post #43

Earlier quoted context omitted.

It's the opposite for me. React can be verbose but that's because a lot of it is explicit and has escape hatches. Svelte has magic that works until it doesn't and then you're stuck in Svelte land. It's not "just JS" despite people marketing it as such

I was stuck once by abusing `bind:` and other time with global exit transitions + sveltekit routing, but that's about it. React on the other hand feels like a pot warming up and we're the frogs being boiled alive at this point. You can write some perfectly valid, but naive React code and it's going to have some footguns. We're so used to write idiomatic React code we don't even notice that anymore. You learn to use s…

> global exit transitions

you'll be happy to know that those are no longer the default in Svelte 4!

Re: Svelte 4

#152

Post by khromov »

Super happy Svelte user. Have recently published an iOS + Android app using SvelteKit and blogged about the process for those interested: https://khromov.se/how-i-published-a-gratitude-journaling-ap...

I tested the beta version of Svelte 4 on my app and it worked without requiring any changes other than running the migration script. Excellent work from the team!

Re: Svelte 4

#153

Post by khromov »

synergy20 wrote: post #99

hope it adds a client side router, and provides a true SPA mode(not the sveltekit stuff), before then, no plan to use svelte again as my use cases is 100% SPA with 0% SSR, absolutely nothing with SSR.

It sounds like you have a misunderstanding about SvelteKit. It does have a client side router and you can use SvelteKit as a pure SPA today very easily, all you need is to set `export const ssr = false;` and `export const prerender = false;` in `src/routes/+layout.ts`. Then export with `adapter-static` and you're done.

Swing by the official Svelte Discord, we're happy to discuss your questions! https://discord.com/invite/svelte

Re: Svelte 4

#154

Post by benmccann »

silverwind wrote: post #125
afavour wrote: post #16

> The number of dependencies in Svelte has been greatly reduced from 61 down to 16 Adore this. Would love to see more JS frameworks reduce their dependency trees.

Should just bundle the npm module to a single file with esbuild before publishing it.

There are tradeoffs there. E.g. many of Svelte's dependencies are shared by bundlers such as Vite, Rollup, and their plugins. If you bundle those dependencies it means they have to be downloaded multiple times. It also means you can't use the cache from efficient package managers like pnpm. And lastly, it makes it harder to deal with security issues. If there's a security issue in a dependency then Svelte would need to ascertain whether it could affect users, upgrade the dependency, and file a CVE against Svelte itself. Users would then have to upgrade Svelte in addition to the dependency if it's shared by any other libraries.

Re: Svelte 4

#155

Post by naet »

jawngee wrote: post #120
adamnemecek wrote: post #36

Earlier quoted context omitted.

I have little experience with Vue but to me Vue is very similar to React. What sold me on svelte is the fact that I learned like all of it in maybe 3 hours. I have tried to pick up React here and there and I get the fundamentals but I hate that you need an architecture framework, a router framework etc. Svelte has a standard way of doing that. Writing Svelte, I actually had "fun" building stuff, I can't say the same…

If you compared svelte to vue to react, vue is much more like svelte than it is react.

In my limited experience Vue felt more like React than Svelte felt like React. But I only used Svelte for a small personal project, and mostly only used Vue 2 + Nuxt for a couple of client marketing sites, so my experience might not be the best view into each.

Re: Svelte 4

#156

Post by nickstinemates »

Can someone point me to a concise location of getting a development environment setup for Docker.

Spent an hour or so after reading this and found conflicting information/out of date documentation. The tutorial[1] on the website is not helpful for actual deployment/development.

I found Svelte for New Developers[2] which is slightly better, however, when building according to the instructions what I expect to happen is not happening. i.e, a static index.html is rendered vs. the src/App.svelte getting rendered.

Wrangling all of this is the worst part of modern day Javascript.

1: https://learn.svelte.dev/tutorial/welcome-to-svelte 2: https://svelte.dev/blog/svelte-for-new-developers

Re: Svelte 4

#157

Post by IamFr0ssT »

Covzire wrote: post #135

I have a project I'd like to work on that shares a lot of similarities to how I imagine a "family tree maker" webapp might work, would Svelte be a good choice for it? Basically I'd need the ability to drag and drop, move the tree around like a Map, detect clicks to add new nodes and new branches, stuff like that. I'm thinking an HTML5 canvas would be best but idk.

I don't think it would be a bad choice for it, there is even Svelvet which I think could be a good starting point.

Re: Svelte 4

#158

Post by hajile »

afavour wrote: post #145
hajile wrote: post #140

Earlier quoted context omitted.

I find reactive systems to be at least as complicated as React's declarative model. I was glad to move on from Knockout more than a decade ago and Svelte is conceptually the same thing in how they work, but with a different proprietary syntax and a faster renderer. I also don't understand the styling complaint. React devs used "just CSS" for years before some of them started pushing for CSS-in-JS. In fact, SCSS/CSS i…

As I said most of this is subjective so I won’t disagree but: > copying similar code over and over This isn’t true. Svelte is more than capable of reusing code internally.

What code does Svelte use internally vs what code winds up compiled into your components? Last I checked, MOST of the code wound up in your components. In fact, this was their entire argument for why people should use Svelte when it launched.

Just look at their "Hello World" application on the Svelte website. 5 lines of code transform into 45 lines of code.

Re: Svelte 4

#159

Post by naet »

usrusr wrote: post #107
samwillis wrote: post #25

Earlier quoted context omitted.

JS frameworks are like coffee, some people like them milky and full of sugar, some people like them like them lean and black, some are obsessed with making the "worlds best coffee" at home every morning, and some drink whatever brown water comes out of a vending machine. We all like our coffee different, just as we all have favourite features and designs of frameworks. There is no correct, or best, framework, only pe…

Big disagree on the not using a framework part: far too often that's not so much a lovingly honed craft but an echo of the "websites should work just fine without JavaScript" that has long been given up as a goal but still haunts decisionmaking as an ideal that now serves as an excuse to consider everything client side secondary citizen. "It's JavaScript, right? It's supposed to an unmaintainable mess." If you dig de…

It's definitely not a perfect metaphor but I enjoy working with vanilla JS or without a framework and I think it's very different from "no JS" (I mean... seems obvious given that it's JS).

You can technically do anything a framework does in your own JS, since they're all just opinionated JS libraries. You can make your own SPA or implement your own VDOM or SSG but it might take a long time and not be as battle tested. On the other hand you're also free to make your own optimizations that might work well for your needs without worrying about a huge framework.

Re: Svelte 4

#160

Post by usrusr »

samwillis wrote: post #110
usrusr wrote: post #107

Earlier quoted context omitted.

Big disagree on the not using a framework part: far too often that's not so much a lovingly honed craft but an echo of the "websites should work just fine without JavaScript" that has long been given up as a goal but still haunts decisionmaking as an ideal that now serves as an excuse to consider everything client side secondary citizen. "It's JavaScript, right? It's supposed to an unmaintainable mess." If you dig de…

People can lovingly craft really bad coffee, just as much as good. To them it may be exactly what they want, and that's all that matters.

I'm not saying that there's no good handcrafted bare browser code out there, and I guess some of the bad wasn't made without love at all. But I've just seen too much of the stuff that seems like it's still standing with half a leg in the age of internet explorer vs netscape, and that was perhaps crafted laboriously but certainly with more contempt than love to consider the loved stuff mow than a rare exception. I guess part of my gut reasoning goes like this: chances are the loved ones have been modernised three times over, while the contemptful implementations live on.

But I can't come up with any coffee analogy for that, there's just no mapping between those spaces that makes any sense.

Post reply on HN