Live data from Hacker News

Rich Harris joins Vercel to work on Svelte full time

twitter.com

371–380 of 571 posts

Re: Rich Harris joins Vercel to work on Svelte full time

#371
post #330

I'm tired of having to learn yet another templating language without a very compelling reason. Why do I have to learn, what is essentially, a new programming language for each of these frameworks (Angular, Svelte, Vue, React... Do I really need to learn yet another language construct for stuff like `loops`, `if/else`, event handlers...etc. Why must all of these frameworks re-invent the wheel? At least with React it i…

Because Svelte can look through the template, and at compile-time determine exactly which parts of the output need to be "surgically updated" in the DOM when some of the inputs change, without needing any runtime like a virtual DOM implementation. I don't know how you could implement such a thing (with good ergonomics) without a template language.

> I don't know how you could implement such a thing (with good ergonomics) without a template language.

Parse Javascript? I don’t see how it would be any different, except you have more constructs to work through.

Re: Rich Harris joins Vercel to work on Svelte full time

#372
post #88

I've been pretty skeptical about SPAs but having tried out Svelte for a few side projects, I have to admin I was probably directing my skepticism to the wrong thing, probably React was the cause of my dislike for SPAs. Svelte looks really awesome and the simplicity it brings back is invaluable. I really wish it takes off, for real. Looks very promising.

FWIW I would give Inertia a look. I’ve been using it as the glue between an SPA and my backend, and for me it’s been a best of both worlds experience. Nearly stateless front-end, atomic deploys, easy to understand, no client side routing. Yet you still get the very snappy SPA experience and the nice DX from componentization of your UI. I highly recommend it.

Re: Rich Harris joins Vercel to work on Svelte full time

#373

I 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 ar…

How about unstyled components like a dropdown menu or a multi-select with autocomplete?

Re: Rich Harris joins Vercel to work on Svelte full time

#374
post #371
post #330

Earlier quoted context omitted.

Because Svelte can look through the template, and at compile-time determine exactly which parts of the output need to be "surgically updated" in the DOM when some of the inputs change, without needing any runtime like a virtual DOM implementation. I don't know how you could implement such a thing (with good ergonomics) without a template language.

> I don't know how you could implement such a thing (with good ergonomics) without a template language. Parse Javascript? I don’t see how it would be any different, except you have more constructs to work through.

The "more constructs to work through" is precisely the problem. Without restricting JavaScript to some subset, you're not going to be able to statically determine the behavior of any given program.

Re: Rich Harris joins Vercel to work on Svelte full time

#375
post #311

I like React’s opinionated top-down model (with callbacks passed downwards as needed either directly as props or through a store / context) for handling state changes, as this improves composability and ability to reason about state. My understanding is that Svelte’s main difference from React is that it is not opinionated in this way, and this is considered a positive feature by its proponents. Is my understanding i…

Yep, at least it is for me.

I think it is so much easier to simply `bind:value` than have to write my own event handler to update inputs, etc. Similarly, it's much simpler to have the parent bind to a property of the child rather than passing the value down along with a function to update the parent every single time. In effect it works the exact same way, but I have much less to do to get there.

Store-wise, Svelte stores aren't fundamentally different from having all of your state in Redux, and I prefer that it encourages smaller stores rather than one giant one.

On top of that, it just feels better to me writing HTML, CSS, and JS instead of trying to shoehorn everything into JS.

Re: Rich Harris joins Vercel to work on Svelte full time

#376

I 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…

> Built in reactive store is cool, but our developers all ended up using it for tight coupling and global variables

I see this in every project where juniors or just undisciplined developers get to run without oversight. There's nothing special about Svelte stores here. Any store has this trap. There's no framework or library solution for good discipline about if, where, and how you share data.

Re: Rich Harris joins Vercel to work on Svelte full time

#377

Earlier quoted context omitted.

JSX is JS. Nested brackets are simply converted to nested function calls & objects, attributes convert to properties. This is evident when comparing conditionals, loops, etc. Instead of learning template syntax you simply use JS syntax, albeit a declarative subset (no branches). JSX is simply syntactical sugar for nested JS, you can use it without, but it's prettier with. One could add this syntactical sugar natively…

I agree 100%... Adding JSX to the language spec would be interesting. It might be too heavy to include within the language spec as many JS applications do not involve the DOM at all, so then you have to essentially bundle DOM functions into every application... or common.js would omit this subset of the language.

One nice thing about JSX is that it is pretty straightforward to write the function (React.createElement replacement) that it transforms to, so you can use it to construct any complex tree-like structure. No DOM stuff is needed. For example writing a JSX factory to output a static html string is maybe 20 lines of code.

Re: Rich Harris joins Vercel to work on Svelte full time

#378

I 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…

> - Special syntax for reactivity is not javascript

> - I find the javascript-native flexibility of JSX far more expressive than any custom templating

These are odd points to combine – JSX is special syntax not JavaScript as well.

Re: Rich Harris joins Vercel to work on Svelte full time

#380

Earlier quoted context omitted.

Interested to hear if you considered compiling Rust to WASM and what your thoughts were?

I looked into it at one point and it sounded like WASM isn't as fast as native (yet?), and the main benefit would be the ability to run in a browser. That'd be useful for making a web version and I might look into it again, but for now, if I'm already shipping an Electron app, WASM seems like extra hassle with less speed. I might be wrong about this though! Happy to hear if there are benefits I'm missing.

It's pretty dam close to native. I would consider researching it again. You could do away with Electron altogether and just run it in browser. You can make it a PWA to give it that "Native app" feel so the users are none the wiser but you don't have to deal with the complexities of Electron and managing releases etc. If you want to launch a new release just deploy it to your web host and you're done for all platforms.

This is all assuming there isn't some specific OS level requirements in your app. I know there are other video editors using WASM successfully and apps like Figma.

Post reply on HN