Any Svelte UI component libraries with good i18n and a11y support?
Not Svelte specific but daisyUI is pretty nice. It’s just Tailwind though, so any i18n and a11y are up to you to implement.
Rich Harris joins Vercel to work on Svelte full time
351–360 of 571 posts
Re: Rich Harris joins Vercel to work on Svelte full time
#352Earlier quoted context omitted.
I see your app is MacOS only at the moment. Are you re-writing it in Electron or what? Very curious
Also curious - I'm spinning up a small side project with Rust and Svelte. Was looking in Tauri as a replacement for Electron but wondering what other approaches people have worked with (assuming this is a cross platform desktop app, that is).
I'm using quickjs (rquickjs specifically) to bind GTK's C API to Javascript and adding a light DOM wrapper (get/setAttribute, add/removeEventListener, etc) that covers all the functionality Svelte needs. I've had to make a few modifications to the compiler (Working in GTK with hot reload and instantaneous esbuild rebuilds is.... insane.
Re: Rich Harris joins Vercel to work on Svelte full time
#353Earlier quoted context omitted.
The key is used by the shadow Dom for update performance; the is no shadow Dom in svelte
And yet Svelte is faster than React in pretty much every benchmark I’ve seen.
That makes sense though right? One would assume that shadow dom and dom would be slower than direct dom manipulation.
Re: Rich Harris joins Vercel to work on Svelte full time
#354Earlier quoted context omitted.
Lee from Vercel here. The governance of Svelte isn't changing – it's still the same independent, open-source project and community. We're just supporting Rich and helping the project grow!
Glad to see you here Lee! > We're just supporting Rich and helping the project grow! I'll admit that I have a negative bias towards this... in spite of Basecamp+RoR, Mozilla+Rust, or all the great OSS HashiCorp makes, it's still hard for me to believe that business do anything out of the goodness of their heart. Is there a strategic goal for hiring Rich? is it that Svelte is used so much in house that it only made se…
In the case of Vercel, I'd imagine that improving svelte's reach positively affects them commercially seeing as they're a major player in the relatively small market of svelte hosting.
Re: Rich Harris joins Vercel to work on Svelte full time
#355I have recently joined a team that had invested in Svelte. I had previous experience in Angular and React. I was happy with React, but I decided to drink the koolaid and go all-in and do my best with Svelte.
6 months later, we're moving to React. It is partly because our Svelte code was messy enough to warrant a rewrite, and partly because we wanted to leverage the React ecosystem in that rewrite. It was also partly because I just don't like Svelte very much.
I think Svelte is clever, and interesting, and I'm glad it exists. But I found a few points insurmountable:
- Too much magic. The abstraction leaks and when it does, it requires a good mental model of Svelte's magic. I noticed this threw our juniors off.
- Special syntax for reactivity is not javascript
- I find the javascript-native flexibility of JSX far more expressive than any custom templating
- There are major tradeoffs made by doing things at compile time. Things that are easy in React at runtime turn out to be surprisingly difficult in Svelte
- Two-way data binding is a constant source of bugs
- Svelte practically requires let-style variable rebinding, often at a file wide scope, which again caused our juniors in particular to write bad code
- The style system is too opinionated for me. I also find it necessary to break into the global scope for any minor restyling of a subcomponent (or worse, pass in the style as a prop)
- Built in reactive store is cool, but our developers all ended up using it for tight coupling and global variables
- The strict one component per file approach can be cumbersome. It's not possible to write a one-line function component or similar
- Much smaller ecosystem than React, requiring much more to be done in house (exacerbated by all of the above).
- The faster runtime speed in no way made up for any of the above. Bad Svelte code is still slow compared to good React code.
Re: Rich Harris joins Vercel to work on Svelte full time
#356Earlier quoted context omitted.
Seems like svelte is superior for not needing a key.
The key is used by the shadow Dom for update performance; the is no shadow Dom in svelte
List diffing is done even in svelte at runtime. Keys are used the same way as any other frameworks or frontend libraries, virtual DOM or reactive.
Re: Rich Harris joins Vercel to work on Svelte full time
#357I have recently joined a team that had invested in Svelte. I had previous experience in Angular and React. I was happy with React, but I decided to drink the koolaid and go all-in and do my best with Svelte. 6 months later, we're moving to React. It is partly because our Svelte code was messy enough to warrant a rewrite, and partly because we wanted to leverage the React ecosystem in that rewrite. It was also partly…
Perhaps a shift in mindset about how to approach using Svelte would help. Svelte is not React, and using React for an extended period really changes how you think about frontend code (structure-wise etc).
As a quick example, the Svelte 'ecosystem' is simply the Javascript ecosystem, which existed well before React. You can import any npm module to a Svelte app. Outside of the React-specific packages (which I argue are overkill), such as Redux or Redux-enabled form libraries, what are you missing? Pre-styled components like calendars, modals, popups, are available in a range of vanilla-JS packages. Anything more than that and it's possible that React thinking has over-complicated your approach.
Re: Rich Harris joins Vercel to work on Svelte full time
#358Vercel's increasing control over the frontend ecosystem worries me a lot.
There's hope: https://github.com/cheatcode/joystick.
Re: Rich Harris joins Vercel to work on Svelte full time
#359Wow, this should be great news for Svelte and SvelteKit! Hopefully with Vercel's backing these projects will fly off. Having worked with React for about 5 years (with a project in Vue in-between) and now having dabbled with Svelte, there is just something more appealing working with less higher-level abstractions. Sure with large apps React does have its benefits and its ecosystem is larger by a good amount. But ther…
Hearing about a JS framework "X" that is surely that much more elegant than "Y" feels like it's 2010s again!
At least this time Svelte is a step closer toward the native browser stack rather than yet another abstraction layer.
Re: Rich Harris joins Vercel to work on Svelte full time
#360Earlier quoted context omitted.
For all the use cases I deal with on a regular basis, Svelte looks more like vanilla HTML/JS than any equivalent React code. And the reason these things change is because that's what needed changing . One of the topline features of Svelte is that is has less boilerplate than React, and it achieves that quite handily. Unless you're criticizing particular constructs in Svelte that are unjustifiably different, I don't t…
What how can you say that??? {myItems.map({id, title}) => {title} } vs... svelte {#each myItems as item} {item.title} {/each} One is literally just javascript and html the other is an entirely different template language. You might say... JSX is not HTML... well it's very very similar... If you know HTML you JSX is very intuitive.
This JSX syntax is a perfect example of one of its subtleties: map() creates an array, and an array of elements is automatically expanded to single elements. I know that when I learnt JSX, this was not intuitive.
The word 'each' conveys the intent of this code way more explicitly.