React VS Svelte - Which one should you choose in 2024? ft Rich Harris
Summary
TLDRIn 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
π€ 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.
π 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.
π οΈ 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.
πΌ 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.
π§ββοΈ 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.
π 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.
Mindmap
Keywords
π‘React
π‘Svelte
π‘Compiler
π‘Runtime
π‘HTML
π‘JavaScript
π‘Component
π‘Hooks
π‘Asynchronous Operations
π‘Ecosystem
π‘Idiomatic 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.
Browse More Related Video
5.0 / 5 (0 votes)