7 ms·
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 make
by 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 agoI 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 agoI'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 agoadapter-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 agoInfrastructure adapters are becoming table stakes for frontend frameworks.
- mcintyre1994 3y agoWhich other frameworks have them out of interest? Sounds like a great feature. AFAIK Next doesn’t and it’ll be interesting to see if it gets them given it’s from Vercel. When I tried Remix you had to choose your deployment when initialising a project and it didn’t look trivial to change it, but that was a while ago.
- threatofrain 3y agoSolid & Astro.
- willsmith72 3y ago> Having everything just be explicit JavaScript code This is funny because it's exactly the reason I prefer react
- kipple 3y agoAgreed, I want markup in my logic — not logic in my markup
- popsticl3 3y agothis!
- vdeveloper 3y agovery interesting, i wonder what's your opinion on tools like htmx which work on the exact opposite basis
- canadianfella 3y ago[dead]
- ttfkam 3y agoCSS and HTML in JS was always a bad idea. HTML can live on its own. JS is a dependent technology, on the same level as CSS. The HTML was always the foundational technology. Centering JS has always been like putting the cart before the horse.
- lucideer 3y agoThis seems intuitively right but doesn't really result in good outcomes in practice (I'm curious if you have any concrete reasons to justify saying it "was always a bad idea"). In practice what I've found is that HTML is fine/optimal for event-driven interactions layered onto entirely static content, but for inherently interactive UIs, what ends up happening is you get one of two systems: 1. If you start from a HTML-forward standpoint, you can go a certain distance separating your concerns entirely, but at scale the drawback is maintaining disparate references, negatively impacting code colocality: having to edit a reference in three separate files in a repo is incredibly bad for DX and readability. To overcome this, a common approach is to make the JS side generic by embedding DSL with dynamic functionality into your HTML: the worst of both worlds, creating both a Frankenstein HTML+weird-extras language and still needing to bundle JS with it. 2. If you're starting a greenfield project with the early intent of having a fully interactive UI, instead of growing into it, you can avoid the above mess and architect your project from the offset with good code colocality by embedding templates for highly dynamic/transient UI components into the imperative part of your application logic (i.e. the JS).
- erikpukinskis 3y agoI don’t follow… in what sense is this JavaScript? <button on:click={incrementCount}> Specifically, what is on:click? It doesn’t look like JavaScript, and it doesn’t look like the DOM. It looks like a new language which is specific to Svelte. Or what about this… is this JavaScript? $: doubled = count * 2; Or… {#if user.loggedIn} <button on:click={toggle}> Log out </button> {/if} Or… <button on:click|once={handleClick}> Click me </button> I am willing to believe that all of that is ergonomic in some way, but it doesn’t appear to me at first blush as very JavaScript-y, or explicit. I see a lot of black box stuff controlled by a declarative API.
- diob 3y agoReminds me of Angular
- Bilal_io 3y agoAngular template syntax is correct HTML syntax. It's nothing like the examples abovd.
- russelg 3y agoYou're telling me on:click={toggle} is nothing like (click)="toggle()"?
- wirahx 3y agoit's not. `toggle` is a pointer to a function name and "toggle()" appears to be an expression which is parsed and then executed (scary). you can on on:click={() => toggle()} in svelte which is more similar, but it isn't parsed and executed, it is a pointer to an anonymous function which is directly executed. on:click={toggle()} in svelte would run the function immediately (probably not what you want) and return the result as the handler for the on:click so quite different, really.
- ttfkam 3y ago
- pacomerh 3y agoFirst we were excited for the virtual DOM which is good for batching updates, flexibility, efficiency, etc. But now the cool thing is to get rid of it?
- wirahx 3y agonot everybody was excited about the virtual dom. people who looked closely at it weren't particularly excited.
- anonzzzies 3y agoNever been excited in the least by it. Being too clever imho. Problem is: I don’t often get to dictate what we use so there I am, caught in the web.
- ttfkam 3y agoBrowsers are not the same as they were ten years ago.