React VS Svelte - Which one should you choose in 2024? ft Rich Harris

Summary

In this insightful discussion, Rich Harris, the creator of Svelte, compares Svelte's compiled approach with React's runtime methodology. Harris argues that Svelte's design offers advantages in UI development due to JavaScript's unsuitability for describing user interfaces. He acknowledges React's robust ecosystem and advanced data handling but asserts Svelte's simplicity and performance as key benefits. The conversation also touches on the philosophical differences between the frameworks and the potential of Svelte 5 to address advanced programming needs while maintaining ease of use.

Takeaways

• 🤔 Rich Harris, creator of Svelte, has written enough React to be familiar with it but hasn't built substantial applications with it.
• 🔍 Svelte is a compiled language, whereas React is a runtime language, giving Svelte a design advantage in UI development.
• 👎 Harris argues that JavaScript is not a good language for describing user interfaces, unlike HTML which is, once interactivity is added.
• 🛠️ Svelte has to develop its own tooling, like a type checker, which is an overhead compared to other frameworks.
• 🌐 React's recent updates, like React 19's experimental compiler, show a trend towards pre-runtime compilation in web development.
• 📈 The adoption of compiled languages in web development is not inevitable, as seen with Elm or Mint, due to the familiarity gap and learning curve.
• 👌 Svelte avoids the learning curve by being similar to HTML, allowing developers to use their existing skills.
• 📱 Harris suggests that Svelte might allow for an application with no JavaScript, emphasizing its templating capabilities.
• 🔄 React's ability to write code that runs directly in the browser without build steps is a niche advantage, but not commonly used.
• 🌟 React has a strong ecosystem and job market, which are significant advantages for developers choosing to learn and use it.
• 💡 Svelte's focus on simplicity and performance for common UI tasks makes it an attractive choice for developers looking for a streamlined framework.

Q & A

What is the main difference between Svelte and React as described by Rich Harris?

Svelte is a compiled language, while React is a runtime language. Svelte has the advantage of a larger space to search for solutions to problems as it doesn't have to fit everything into JavaScript, which Rich Harris argues is not fundamentally well-designed for UI development.

Why does Rich Harris believe JavaScript is not ideal for describing user interfaces?

Rich Harris thinks JavaScript is not a good language for UI development because it is event-driven, and UIs are better described in a state-driven manner. HTML is great for static UIs, and the gap to make it interactive is smaller compared to adapting JavaScript for the same purpose.

What does Rich Harris think about the adoption of compiled languages in web development?

Rich Harris doesn't see it as inevitable that compiled languages will overtake runtime languages. He mentions that despite the advantages, there's a familiarity gap as people are reluctant to learn new languages, which has limited the adoption of languages like Elm or Mint.

How does Rich Harris view the role of compilers in web development frameworks?

Rich Harris sees compilers as a positive development in web frameworks, noting that doing more work before the application runs improves the user experience. He mentions that React 19 now has a compiler, indicating a trend towards compilers in the industry.

What are some of the advantages of using React over Svelte according to Rich Harris?

Rich Harris acknowledges that React has a large ecosystem, a wide range of available jobs for developers, and advanced capabilities for data handling and large applications. React's approach to colocating data with components is also seen as an advantage for managing asynchronous operations.

What does Rich Harris think about the learning curve for Svelte and React?

Rich Harris believes that Svelte might lead to a more idiomatic understanding of JavaScript because it doesn't introduce as many abstractions as React does with its hooks and component lifecycle. He suggests that React developers might be learning React-specific patterns rather than general JavaScript.

How does Rich Harris view the community and collaboration between different web development frameworks?

Rich Harris views the web development community as collaborative and respectful, with different frameworks occupying different niches and offering meaningful choices to developers based on their preferences and project needs.

What does Rich Harris think about the verbosity of React code compared to Svelte?

Rich Harris acknowledges that Svelte is focused on making common use cases simple and concise, while React code can be more verbose. He suggests that React's verbosity is due to its focus on composability and integration with the rest of the JavaScript ecosystem.

What are Rich Harris's thoughts on the future of Svelte, particularly with the introduction of Svelte 5?

Rich Harris is excited about Svelte 5, which aims to preserve the simplicity of Svelte while adding more power, flexibility, and composability. The new features are designed to address the limitations encountered when building larger applications with Svelte.

What would it take for Rich Harris to consider using React over Svelte?

Rich Harris would need to see React adopt features that are currently unique to Svelte, such as built-in support for transitions, animations, and styles as part of the component definition, and a shift in philosophy to be more encapsulated and focused on day-to-day UI problems.

Outlines

00:00

🤔 Introduction to React vs. Svelte Discussion

The conversation begins with the host introducing the topic of choosing between React and Svelte for web development. Rich Harris, the creator of Svelte, is invited to provide an unbiased comparison. Rich shares his experience with React, acknowledging his familiarity without having built substantial applications with it. The discussion then pivots to the differences between Svelte as a compiled language and React as a runtime language, with Rich suggesting that Svelte's approach offers a broader solution space but also comes with its own set of challenges, such as the need for additional tooling like a type checker.

05:04

🔍 Svelte's Advantages and the Role of Compilers

Rich discusses the advantages of Svelte's compiled nature, arguing that it allows for more efficient solutions due to the larger design space available before runtime. He critiques JavaScript's suitability for UI development, favoring HTML's static nature for describing interfaces. Rich also touches on the growing trend of frameworks adopting compilers, noting that React's recent addition of an experimental compiler indicates a move towards pre-runtime optimization. However, he tempers this by acknowledging that compiled languages like Svelte may not inevitably overtake runtime ones due to the familiarity gap and the resistance to learning new languages.

10:06

🛠️ The Philosophy Behind Svelte and React

The conversation delves into the philosophical differences between Svelte and React, with Rich emphasizing Svelte's focus on simplicity and directness, which contrasts with React's approach that involves more JavaScript intricacies. He suggests that Svelte's design avoids the need for external packages in many cases, promoting a more integrated and straightforward development experience. Rich also addresses the idea of 'deleteability', the concept of cleanly removing code without leaving unnecessary dependencies, which he sees as a challenge in large codebases that React has been addressing.

15:06

💼 React's Strengths in the Job Market and Ecosystem

Rich acknowledges React's dominance in the job market and its extensive ecosystem, which offers a vast array of pre-built solutions. He contrasts this with Svelte's approach, which often avoids the need for external packages by leveraging the platform's capabilities. The discussion highlights React's strengths in handling advanced data operations and its suitability for large-scale applications, areas where Svelte is currently less advanced. Rich also suggests that learning React can lead to a deeper understanding of JavaScript, contrary to the host's initial impression.

20:09

🧙‍♂️ The Magic of Svelte and the Abstractions of React

The dialogue explores the 'magic' of Svelte, where developers can write less code and achieve more with simpler syntax. Rich argues that Svelte's syntax is more intuitive and closer to idiomatic JavaScript, making it easier for developers familiar with web standards. He contrasts this with React's approach, which involves more verbose code and a style of programming that is distinct from traditional JavaScript. The conversation also touches on the challenges of understanding React's lifecycle and state management, which can be abstract and counterintuitive for developers.

25:09

🌟 The Future of Svelte and the Web Development Ecosystem

Rich discusses the future of Svelte, particularly the upcoming Svelte 5, which aims to maintain simplicity while providing more power and flexibility. He addresses the limitations of Svelte's current syntax and the need for a more robust system, particularly for advanced use cases. The conversation concludes with a reflection on the diversity of the web development ecosystem, where different frameworks cater to different needs and philosophies. Rich emphasizes the importance of choice and innovation, encouraging developers to select the framework that aligns best with their goals and preferences.

Keywords

💡React

React is a popular JavaScript library for building user interfaces, particularly for single-page applications. It allows developers to create reusable UI components and is known for its efficient update and rendering process. In the video, React is compared with Svelte, another framework for building web applications, highlighting differences in their approaches to UI development. The script mentions React's capabilities, such as managing asynchronous operations and server-side rendering, which are seen as advantages over Svelte.

💡Svelte

Svelte is a relatively new JavaScript framework that focuses on simplifying the process of building web applications. Unlike React, which uses a runtime approach, Svelte compiles components into efficient JavaScript at build time. This results in smaller, faster, and easier-to-manage code. The video discusses Svelte's advantages, such as its simplicity and performance, and how it compares to React, particularly in terms of the developer experience and the resulting application size.

💡Compiler

In the context of web development, a compiler is a program that translates code written in one language (the source language) into another language (the target language). The video script discusses how Svelte uses a compiler to convert components into optimized JavaScript code. This is contrasted with React, which traditionally has been a runtime framework but has introduced an experimental compiler in React 19. The use of compilers in web frameworks is seen as a way to improve performance by doing more work ahead of time.

💡Runtime

Runtime refers to the period when a program is being executed by a processor. In web development, a runtime framework like React manages the lifecycle of components and updates the DOM as needed. The script contrasts Svelte's compile-time approach with React's runtime approach, suggesting that Svelte's method can lead to more efficient code because it does not require the overhead of managing state and re-rendering at runtime.

💡HTML

HTML (HyperText Markup Language) is the standard markup language for creating web pages and web applications. It is used to structure content on the web. The video script mentions HTML in relation to Svelte, which is described as a superset of HTML, allowing developers to write interactive web applications using a syntax that is familiar and intuitive for those who already know HTML, CSS, and JavaScript.

💡JavaScript

JavaScript is a scripting language commonly used for web development, allowing for interactive web pages and implementing complex features on websites. The script discusses JavaScript's suitability for UI development, with the creator of Svelte arguing that it is not ideally designed for this purpose, unlike HTML. The conversation also touches on how JavaScript's event-driven nature contrasts with the state-driven nature typically desired in UI frameworks.

💡Component

In web development, a component refers to a reusable piece of a user interface. Components can contain HTML, CSS, and JavaScript, and can be used to build complex applications. The video script discusses components in the context of both React and Svelte, highlighting how each framework handles the creation and management of components differently, with React using a more traditional JavaScript approach and Svelte using a compile-time approach.

💡Hooks

Hooks are a feature in React that allows developers to use state and other React features in functional components. The script mentions hooks as part of the discussion on how React abstracts certain aspects of JavaScript, leading to a different programming style compared to traditional JavaScript. Hooks enable more complex state management and side effects in components, which contrasts with Svelte's approach where such patterns are handled differently.

💡Asynchronous Operations

Asynchronous operations refer to tasks in programming that are performed without blocking the execution of other tasks. In the context of the video, asynchronous operations are discussed as a strength of React, where it can manage data dependencies and handle asynchronous work across different components without manual coordination. This is contrasted with Svelte's approach, which is described as less capable in this area.

💡Ecosystem

In the context of web development, an ecosystem refers to the collection of tools, libraries, and community resources available for a particular framework or technology. The script mentions the React ecosystem as a significant advantage, with a vast array of pre-built solutions and packages available for developers. This contrasts with Svelte, which has a smaller ecosystem but is growing as its popularity increases.

💡Idiomatic JavaScript

Idiomatic JavaScript refers to writing code in a way that follows the conventions and best practices of the JavaScript language. The video script suggests that Svelte encourages more idiomatic JavaScript compared to React, which abstracts many of JavaScript's features through its own APIs and patterns. This can lead to a different learning curve and coding experience for developers, with Svelte potentially offering a more straightforward path for those already familiar with JavaScript.

Highlights

Rich Harris, creator of Svelte, discusses the advantages and disadvantages of Svelte and React.

Svelte is a compiled language, whereas React is a runtime language, offering different advantages.

JavaScript is not ideal for UI development, according to Harris, who favors HTML for static UIs.

Svelte's design allows for a larger solution space compared to React.

React's ecosystem and job market are significant advantages over Svelte.

React's recent adoption of a compiler in React 19 is noted as a trend towards pre-runtime optimization.

Svelte's simplicity and ease of learning are highlighted as advantages over React.

React's advanced data handling and large application management are recognized strengths.

Harris suggests that Svelte developers might have a more idiomatic understanding of JavaScript.

The philosophical differences between state-driven (Svelte) and event-driven (React) programming are explored.

Svelte's focus on pragmatism and quick expression of ideas is contrasted with React's composability.

Svelte 5 aims to address the limitations found in larger Svelte applications.

Harris envisions a future where different frameworks occupy distinct niches in the web development ecosystem.

The importance of having a choice between frameworks with different philosophies is emphasized.

Innovation in web development and the 'golden age' of frameworks are celebrated.

Harris humorously reflects on his appearance and influencer status at the end of the discussion.

Transcripts

So, you're starting a

new web development project

and you need to decide if you

want to use React or Svelte.

Well, my guest today

can give you a proper,

unbiased evaluation of the two.

I'm here with Rich

Harris, creator of Svelte.

Rich, thanks so much for joining me.

- Thanks for having me.

- So Rich, how much React have you

written in your life?

- Enough to be pretty

familiar with how it works.

I haven't built any substantial

applications with React,

but I am the guy that

people will sometimes come to

for help with their React code

because as a framework author, you know,

you got to study the enemy.

- I'm glad we got that

clip on camera, perfect.

So, you know enough

React to be dangerous.

I have a question about this

and it's following a

little bit on a conversation

you had with my

colleague, Alex, a few months back.

You guys were talking about how Svelte

is a compiled language and

React is a runtime language.

I want to know, do you

think that that gives Svelte

kind of like an unfair advantage?

- It gives us, the makers of Svelte,

a bit of an advantage in that we have

just a much larger space

in which to search for

solutions to problems

because we're not trying

to shoehorn everything into,

you know, a language that I would argue

is fundamentally badly designed

for the task that we put it to.

Like I don't think that

JavaScript is a good language

for describing user interfaces.

And a rendering

framework's job is essentially

to try and bully JavaScript

into being suitable for UI development.

HTML on the other

hand is a great language

for describing user

interfaces as long as they're static.

And so for me, the gap between, you know,

HTML and a good language

for describing user interfaces

is just adding some interactivity.

Whereas the gap between JavaScript

and a good language for

user interfaces is much larger.

So there are definite

advantages from a design standpoint,

but in other ways, it's

definitely not an advantage.

Like in terms of being

able to use existing tooling

and things like that,

like most frameworks

don't have to write

their own type checker.

Like we have to have

this separate package

for type checking

inside Svelte components

and things like that.

So it swings around about,

I think we made the right choice.

You know, your mileage may vary.

A lot of people just fundamentally don't

want to touch anything

that isn't JavaScript.

And that's fine.

But I would say it gives us an advantage,

but certainly not an unfair one.

And, you know, a lot of frameworks are

adopting compilers themselves.

Like last week, React 19 was announced,

and it has a compiler.

It's experimental for now,

but React now has a compiler.

Most frameworks have a compiler.

And I think we're

starting to see a broad agreement

that the more work you can do

before your application runs,

the better it's going to be for users.

And so there's, you know, different ideas

about what a compiler means.

Like one of Twitter's

favorite topics to discuss

is the exact meaning

of the word "compiler."

But it seems like everyone is kind of

drifting in that direction.

So, you know, while we

are probably the framework

that is most strongly

associated with the idea of compilers,

I don't think it gives us a leg up over

everyone else anymore.

But I hear what you're

saying that React has a compiler,

Vue has a compiler, but

there's still languages

that are fundamentally

designed for runtime.

Do you think it's

inevitable that compile time,

since increasingly all web, all code that

we write for the web

is compiled or

transpiled or whatever inevitably,

do you think it's

inevitable that compiled languages,

whether Svelte or

some other up-and-comer,

will eventually overtake languages that

are designed for runtime?

I wouldn't say inevitable, no.

There have been more

expansive attempts than Svelte

to apply this line of thinking.

I'm thinking of things

like Elm or Mint is a language

that is designed specifically for

designing user interfaces.

And, you know, candidly, these things

haven't seen the adoption

that they probably deserve,

and a lot of that is

because of this familiarity gap.

People just don't want to

have to learn any language.

And I think Svelte has

largely avoided that trap

because it is very similar to HTML.

In fact, we call

ourselves a superset of HTML.

And so if you know

HTML, and if you know CSS,

and you know

JavaScript, then you know Svelte.

You don't have to

learn an additional thing.

And so maybe someone will

come along and prove me wrong,

but I don't think that someone is going

to design the ideal language

for user interfaces

and see adoption with it

because people are too

busy to learn new stuff.

And in theory, you actually could write a

Svelte app with no JavaScript.

You could. I mean, it

wouldn't do very much.

But like you could just use it as a

templating language like that.

Yes, and you know, some people do.

That's definitely possible.

I think there are probably

better languages for that.

Like you may as well just

write markdown at that point.

Astro is a great example of a framework

that has leaned very

heavily in that direction.

We are a little bit more focused on

being able to create

richly interactive applications.

But yeah, absolutely.

In theory, on the flip side, in theory,

you can still write React code and send

it directly to the browser.

Do you think that for the for React to

view that's still an advantage?

That is an interesting

question for React not so much.

I mean, no one really

writes react that way.

It's sort of it's quote

unquote possible, but no one does it.

For view, it's a bit

more of a realistic option.

And in fact, a lot of

views usage comes from people

just dropping a script tag on their page

and decorating some existing HTML.

That's not where we want to be.

Like we think that the

best way to build applications

is to have a tighter integration between

the page and the things on the page.

But it's a thing that the view community

has got a lot of mileage out of.

And I don't expect them to

give that up anytime soon.

And there are other

projects with like a similar focus.

Like Alpine is an example of that where

rather than trying to own

the application development, they're just

like a thing that you add at the end.

So yeah, that's great for them.

It's not where we want to be.

So you jokingly

referred to React as the enemy.

But like we all know that this is

actually like a very

collaborative cooperative space

where there's like a lot of idea sharing

and a lot of respect

for the different players.

And in that spirit, what do you generally

tell people are the

advantages of using React over Svelte?

Yeah, I mean, they're

actually not the enemy at all.

We have boundless respect for the React

team and the work that they do.

Obviously, if you want to work in front

end, then knowing

React is a huge advantage.

There are jobs available if you write

Svelte, but there are jobs

available if you write React.

And so there's like just it's a thing

that you need to know if you're going to

be a front end developer today,

then you need to at least have a passing

familiarity with React.

But you know, the framework has a lot of

capabilities that we don't yet.

You know, managing asynchronous

operations in a coordinated fashion is

something that Svelte

isn't great at candidly.

Our server side

rendering is fully synchronous.

So if you have some data that loads

lazily, then that has to be

outside the rendering process.

Whereas in React, you can like capture

your dependencies, your data dependencies

as part of the component, which like

you're talking about

React server components there.

I'm talking about

React server components.

I'm also talking about suspense.

Okay.

The fact that it's possible to manage

asynchronous work across different

components without them having to

manually coordinate with each other.

It's a very cool idea.

And that's an idea that you know, every

framework is eventually

going to adopt in some form.

So by when you say every framework, you

mean Svelte is going to have to reckon

with this at some point?

Absolutely.

So, you know, there was this idea many

years ago that you should keep your

concerns separated and gradually people

came to understand that

that's not really true.

Like you actually want to have the

behaviors that relate to your markup

described in the same place.

You want them to be co-located.

Svelte took that one step further and

said, well, we want styles to be

co-located with your markup as well

because you know, they

relate to each other.

And because we're a super set of HTML, we

can put all of those in the same file.

But then React came

along and said, that's great.

But what we really want to have is our

data co-located with our components.

That is a separation of

concerns that makes no sense.

And gradually, like the trajectory, the

path of evolution is towards having all

of the things in one place

and not having this arbitrary separation

where your data loading happens over here

and it gets fed into

your component over here.

And then maybe you're pulling in some

styles from over there.

Like that, you know, you want

that to be in the same place.

Malta Eubel, who's the CTO of the cell

where I work, he talks about

deleteability a lot.

Like if you can remove some code from

your code base and there are

vestiges of it left behind,

like you're still pulling in the styles

that relate to the

market that no longer exists

or you're still fetching some data over

the network that is no longer being

rendered by a component, then you fail.

But that is the fate of just about every

code base eventually.

And React, because perhaps of its

background in building very, very large

applications at meta,

that's the kind of problem that they've

spent many years

thinking about how to solve.

And we just haven't because our

background has been different.

Like Svelte came out of a need to create

richly interactive widgets

on a very short timeframe.

And so that is definitely an area where

React is far ahead of us.

And there are, you know,

I'm sure there are others.

The ecosystem obviously is one thing that

people talk about a lot.

If you need to solve a problem in React,

then someone has probably

already solved it for you

and you can just

install a thing from NPM.

Kind of a blessing and a curse.

You know, we talk about in Svelte the

fact that very often you don't need to

use an external package

because it's easier to just use the

platform in many cases.

And libraries don't need special Svelte

integrations the way they sometimes need

special React integrations.

But aside from that, like the fact that

so much work has gone into solving

problems in the React world

is a huge advantage if

you're a React developer.

So jobs, ecosystem, maybe advanced data

handling or data handling

and really large applications

or areas where React is obviously

especially powerful.

Yeah, very much so.

Yeah.

Svelte does a lot of the heavy lifting

when it comes to logic and JavaScript.

React doesn't, I feel like React doesn't

hide as much of that.

I mean, it kind of

does with hooks and stuff.

Do you think that somebody who comes to

web development as a React developer

will have a more intimate

understanding of JavaScript

than somebody who comes to web

development as a Svelte developer?

Honestly, I think the reverse is true.

Particularly when Svelte 5 comes out and

we're removing some of the

magic that exists in Svelte 4.

But even today, I think, you know, if you

come to web development

and you learn React first,

which a lot of people do, a huge number

of people learn React first,

then you're kind of

learning React and not JavaScript.

And yes, React is JavaScript in a sense,

but it's also very much not.

Like you're learning a very specific

style of programming.

And the way that hooks work is like it's

not how functions normally work.

Like the idea that the return value of a

function depends on like

when it was last called

and whether it was previously called and

what it was last

called, all of these things.

That's just not how

JavaScript typically behaves.

And obviously, like you can do many

things with JavaScript and like that is

implemented without any magic,

but it still like sort of

violates your expectations.

And so, you know, the way that you learn

how to solve problems in React

versus how you would have solved them

without React, they're

quite different things, I think.

Whereas in Svelte, I think we are pushing

people towards more idiomatic JavaScript

solutions to problems.

And, you know, I think people who are

familiar with HTML, CSS and JavaScript

but have not yet encountered a framework,

very often we'll see that

those people take to Svelte

much more naturally

than they'll take to React.

Because it's just more natural.

That feels counterintuitive to me and

maybe that's why you started there.

When I learned to React, I kind of felt

like this is all just

JavaScript, you know.

I don't know if I ever fully understood

how hooks work, but

when it was taught to me,

I kind of understood like, okay, like I

could probably figure out how to

implement this or work with this,

like by understanding

the code base better.

Whereas when I look at runes, I think

this is kind of magic.

Like I don't need to

understand how this works.

Are you saying that you

don't feel like that's the case?

Like it is just JavaScript and you can

kind of understand it in those terms?

So I think the...

When I say that it's more idiomatic, I

mean the fact that, you know,

if you have a component that is on the

page and it's on the page for

a while and the state comes in,

the form of props and there's internal

state that changes and then maybe

eventually the component goes away.

The component is instantiated once and

the contents of the

script tag, it runs once.

Whereas in React, you're running that

code again and again and again.

And so you have to

understand closures very deeply.

You have to understand

why things might get stale.

And that is not how JavaScript typically

works, but it's also...

It's not really how our brains work.

You think about a component or an

instance of a component and it's a thing.

Like you can talk about

it as if it is a thing.

But in React, it's not a thing.

It is... In React, everything is sort of

this transient sort of state of flux.

And so you can get quite

philosophical about this.

The world is in a state of flux and the

labels that we assign to things,

the models of our... It's

our internal representation.

It doesn't describe anything in the

objective world and React is actually a

more faithful extension of that idea.

But the human brain has evolved to think

in terms of concrete objects.

And I think that some of the ways in

which people get confused about life

cycle in React can sort

of be traced back to that.

We think in terms of objects and React

thinks in terms of functions.

It feels like what you're getting at when

you talk about flux versus objects is the

difference between event-driven and

state-driven development.

Kind of, yeah.

Yeah, we...

It's difficult to fully articulate this

in a way that doesn't sound like...

Like it's very abstract nonsense.

But it's something that...

What else are we doing here?

Yeah. It's definitely something that I've

seen people struggle with when looking at

code and not really being

able to understand like,

why is this rerunning or what is it mean

that it's rerunning?

But JavaScript is an event-driven

language and I mean, I feel like

JavaScript does kind of

exist in a state of flux.

Yes. I mean, this is why I think

JavaScript is fundamentally not a great

language for UI development

because it is event-driven.

But when you're describing user

interfaces, you want

things to be state-driven.

Are you slicing space

or are you slicing time?

Like those are two very different things.

Let's keep going.

And all a framework is essentially is a

way to allow you to model state-driven

programming in an event-driven language.

So I'm in the process of converting a

Next.js code base to Salt right now.

And I keep on coming across these little

pieces of React or Next.js syntax that I

really kind of feel like I banged my head against a little bit.

So aside from this being a really

contrived example, how do we get here?

How do we get to the place where the

Svelte component is so concise, where the

React component is so verbose?

Yeah, I mean, as you say, it is extremely

contrived. Normally, it's

not quite that egregious.

But this is, I think, what happens when

you start from one set of priorities as

opposed to a different set of priorities.

Svelte is very relentlessly focused on

these pragmatic goals of how

quickly can we express an idea.

And React is focused on different things.

It's focused on being able to integrate

with the rest of your application.

It's all JavaScript. Everything that you

see there is, well, not valid JavaScript,

but valid JSX at least.

If you wanted, you could extract part of

that out into another function and you

could move it to a different file or

elsewhere in that module.

So it's like composable in a certain way

that Svelte maybe isn't.

And, you know, most of the time, you're

not going to need to

write that sort of thing.

So maybe focusing on that case hasn't

been a big priority.

And a lot of people prefer that. A lot of

people look at that React code and say,

well, that's much better because, you

know, I haven't had to learn this weird

new syntax, like this

hash each array as number.

Like, what is that? I don't want to have

to learn any syntax. To which I always

reply, like, if that syntax is too hard

for you to learn, then maybe programming is the wrong profession.

It's obviously pretty straightforward

what's happening there.

You know, it's just relative priorities.

Like, my background is in journalism.

Svelte was built for me to solve the

problems that I faced as a working

journalist needing to hit deadlines.

And it takes a lot less time to write the

code on the top than it takes to write

the code on the bottom.

And so that's why we

ended up where we did.

I think it's really cool thinking about

it in terms of what you're describing of,

like, managing a world in flux.

And I kind of like you said, React is

good if you're dealing with, like, a data

intensive, like, a large code base, like,

a lot of data flowing through it.

Then I feel like React does kind of feel

like it's got those power tools for

dealing with these, like,

large flows of data and stuff.

It's for, like you said, it's for slicing

time. Whereas if you're dealing with

something that feels more like objects,

something that feels more solid,

something that feels more visual, if

you're slicing space,

Svelte's got your back.

I think I'm probably going to think about

it from the thing about

it that way from now on.

Yeah, I mean, historically, I think we

probably over-indexed on that problem.

Like, how can we solve 90% of problems in

a very straightforward way?

Can we provide some syntax that makes

this common use case super easy?

And that's great for a lot of use cases.

But then when you hit that 10% of the

things where you really do need some advanced programming,

that's where Svelte 3 and 4

start to fray a little bit.

And over the years since Svelte 3 came

out, and people have started to build

more and larger applications, we've

started to see people

hit those boundaries.

And so that is really what Svelte 5 is

all about. We're trying to preserve the

simple cases, keep those

as simple as they are today,

but also give people the extra power and

flexibility and composability that people

in the React world take for granted.

Am I right in thinking that you're

talking about the dollar sign operator?

Among other things, yeah. That is a great

example of something that, you know, you

learn it in the first 10

minutes of using Svelte,

and it feels like, you know, coding with

the wind in your hair and everything.

But when you start to use it more

extensively, you find that actually it's

a little bit of a trap, because inside

that dollar colon statement,

we're operating under slightly different

rules. Like that code will rerun when the

compiler says that it should rerun.

And when you start to put more and more

logic in there, and then realize that you

can't really refactor it out without

changing the behavior,

that becomes a little bit frustrating.

And that's the kind of problem that we're

solving in Svelte 5 by taking some of the

responsibility out of the compiler and

putting it into the runtime

using our signal mechanism.

And based on everything that we've seen

from using Svelte 5 to re-implement

things that we maintain,

I think that people are hopefully going

to find that we still have this really

nice, elegant syntax for common problems,

but we also have the ability to do things

in a more robust and scalable fashion

than we could before.

What would React have to do for you to

hang up your hat and say, "All right, I'm

going to get a job as a React developer"?

Oh, wow. A lot of the things that come

with Svelte, like transitions and

animations and styles as part of your component definition,

I would really be reluctant to give those

up. And you can do those things in React.

You have to install some packages and you

have to do things in a

slightly different way,

but it's all possible. You can do all

that. But it doesn't feel as nice, and

they would have to make it feel as nice.

That stuff needs to be built in. It needs

to come with part of the framework. The

framework needs to consider these

problems to be part of its domain,

rather than, "We're just concerned with

reconciling the DOM and all of these

other problems. We're going

to leave that to userland."

That's a perfectly legitimate and

understandable stance to take, but it's

not the stance that I

want my framework to take.

And so it's not the stance that Svelte

takes. And for me to not use Svelte and

use React instead, that would have to be

quite a big philosophical shift.

Which is, I think, a good and healthy

thing. The fact that we have these

different projects in the ecosystem that

have these different philosophies.

If you want to be a React developer, if

you subscribe to the React philosophy,

then use React. If you

subscribe to the Svelte philosophy,

the thing should be a little bit more

encapsulated and focused on day-to-day

problems than come and use Svelte.

And if you're somewhere in between, if

you prefer the aesthetics of a different

framework, solid view,

whatever it is, then use those.

I don't see all of these things as in

competition so much. We're just occupying

different niches in the ecosystem.

And I think it's important that all of

those things exist and continue to be

meaningfully different so that people

actually have a meaningful choice.

This is just such an exciting time. I

feel like there's so much innovation

happening in the web development sphere.

I feel like it's really a golden age for

web development with all these different

frameworks, which are all coming up with

different approaches to solving problems,

or coming up with the same approaches to

solving problems. And I'm really excited

to see where it goes, and I genuinely

hope that you do not hang up your hat and

become a React developer.

And if you want to learn more about

Svelte, you can check out our feature

interview with Rich, which we did at his

apartment in New York

City back in December.

And otherwise, thanks very much for

joining me. Thank you.

Thank you, Sam. Do I look like a

YouTuber? Do I come

off like an influencer?

Do I come off like an influencer?

I mean, I think you're

actually smashing it.

I'm fishing for compliments here.

I'm fishing for compliments here.