[HN Gopher] Svelte 5 is not JavaScript
___________________________________________________________________
Svelte 5 is not JavaScript
Author : jonstaab
Score : 148 points
Date : 2025-02-18 16:29 UTC (6 hours ago)
(HTM) web link (hodlbod.npub.pro)
(TXT) w3m dump (hodlbod.npub.pro)
| ilrwbwrkhv wrote:
| Ya I knew Svelte took a wrong turn when it went from
|
| var foo = "something"
|
| foo = "something else" -> ui updates
|
| to:
|
| $state('hello')
|
| Runes and other nonsense immediately made me turn off Svelte.
|
| Even Vue sort of moved away and started looking like React.
|
| I think there is an opportunity now for another new framework
| which goes back to simplicity which Vue and Svelte tried to do.
|
| Mithril really was as close to perfection as one can get.
| ChocolateGod wrote:
| I disagree, yes it feels less VanillaJS-ey but having unwanted
| reactivity made Svelte annoying at times and caused reactivity
| loops that just made code ugly to avoid.
|
| Anyway, if you don't want it like that you can continue to use
| the old system.
| recursive wrote:
| Interesting. The new Svelte seems clearer to me. In fact,
| Svelte seems to be moving _toward_ vue to me, and away from
| react. That is components have stable identities and each piece
| of state has a subscriber list, which may directly update a DOM
| element or another piece of state. None of which requires re-
| "rendering".
| dapperdrake wrote:
| At what point will they reach SQLite?
| recursive wrote:
| I don't understand this at all. There's no plans to support
| a query language. Scalar values can exist. Heterogeneous
| lists can exist. The use case is explicitly tightly coupled
| to a UI layer. What would it mean to reach SQLite?
| mgrandl wrote:
| As somebody who maintains a very large Svelte app and upgraded
| from 4 to 5, I couldn't be happier with the changes. For simple
| components the old approach was just fine, but the larger the
| codebase gets the harder it gets to work with.
| terminalbraid wrote:
| I appreciate someone working on a sizable codebase to put in
| their opinion. Too often it's just feedback on their
| experience with a Hello World analog and it's easy to get
| hyperbolic opinions off of that.
| bangaladore wrote:
| My opinion exactly.
|
| Svelte 4 is simple in a single component. Svelte 5 needs a
| bit more boilerplate.
|
| Svelte 4 was always very confusing in multi component/files
| workflows, especially when working with .ts/.js files. Svelte
| 5 is way better in this regard.
|
| I'd pay the "slightly more boilerplate" price every day.
| Muromec wrote:
| >Even Vue sort of moved away and started looking like React.
|
| Did it? Vue has composables that look kinda like react hooks
| syntaxically, but aren't the same thing at all, they are just
| better scoped mixins.
| sensanaty wrote:
| Vue moved the exact opposite way, and in fact Svelte moved more
| towards Vue 3 and its composables/CompositionAPI.
| npn wrote:
| To be fair, the reason svelte 5 is that awkward to use is
| because they still need to be compatible with svelte 4 code.
|
| Without svelte 4 compatibility, you can just replace `$state`
| with `$`, `$derived` with `$$` or even some simpler mechanisms.
| Heck, I have vague intuition that we can reuse the `$: `
| statements someway too, and still keep the new deep reactivity
| feature.
|
| Might be svelte 6 will give us the proper answer. Or some newer
| fancy framework will take the hint and do it sooner.
| bangaladore wrote:
| > To be fair, the reason svelte 5 is that awkward to use is
| because they still need to be compatible with svelte 4 code.
|
| The way the compatibility works is by seemingly identifying
| the file and either treating it in legacy mode or runes mode.
| I don't think what you are suggesting would have blocked them
| from doing what they are doing now.
| npn wrote:
| It does thought. You can't assign new meaning to $ and $$
| and expect that it works flawlessly with magic statements
| and the stores.
|
| At the very least the conversion between the versions will
| be very messy and error prones, especially using the
| migration tools.
|
| Not to mention the designs of runes was still unstable back
| then. Heck even now it is still very awkward to use runes
| with sveltekit. You need $state and $effect everywhere for
| the page data.
| forvelin wrote:
| why mithril.js was though ? it is still a solid choice.
| rikafurude21 wrote:
| Frontend work sounds like hell. You're telling me you updated
| YOUR code to work with the latest framework release? What was
| even new in that release? They seem to have no respect for
| peoples time or any consideration for longtermism or even just
| the common decency of backwards compatibility. What are we at
| now, React 19? Is it just a reason to keep people employed?
| golergka wrote:
| > You're telling me you updated YOUR code to work with the
| latest framework release?
|
| I work on frontend right now, but I've worked on backend
| earlier, as well as gamedev and desktop applications. And it
| was always like that in every area: when your major dependency
| has a major version upgrade, you will have to spend effort on
| migrating your code to support it.
| bastardoperator wrote:
| It a software problem, not a frontend/backend problem. We've
| all been subjected this insanity in some way.
| fiddlerwoaroof wrote:
| The issue I had when I still worked in the frontend world is
| the frequency of major version updates. If you used standard
| project bootstrapping tools in approximately 2017, you got a
| whole bunch of libraries and tools that would have
| significant breaking changes multiple times over the next
| three years or so (I know because I had to maintain them).
| 2mlWQbCK wrote:
| That seems to be a problem that is getting worse with time
| though, with increasingly frequent "major" releases and fewer
| that consider backwards compatibility much at all. Also it
| used to be much more common to have published specs and
| standards that you could code to for a good chance to not
| have to rewrite your code next month.
| leosarev wrote:
| Except usual time to upgrade to next version of .net is less
| than man day.
| sieabahlpark wrote:
| Tailwind v4 just gave everyone who uses sass the middle finger.
| It's rampant in the front end to rewrite because it's actually
| a solved problem. They need to explain their salary by
| reinventing constantly..
| striking wrote:
| > What are we at now, Rails 8? Is it just a reason to keep
| people employed?
| bdcravens wrote:
| 8 major releases over 20 years vs 19 over 10.
| mardifoufs wrote:
| Yet react 19 is almost (except for some edge cases that
| only affect very specific stuff) fully compatible with
| version 1. Try running a rails 3 app on rails 8 or vice
| versa.
| morcus wrote:
| The React versioning is a bit silly, but React 15 was the
| first major version (in 2016) which makes it more like 4
| major releases in 9 years. Not that different from 8 major
| releases over 20 years.
| voat wrote:
| No one is forcing you to upgrade, Svelte 4 still works just
| fine? Svelte has had basically no major API changes since 2019,
| that's a better part of a decade. And with this new
| architecture change, they released a sophisticated codemod to
| do most of the work of updating for you.
| KTibow wrote:
| In fact, you can still use Svelte 4-style components with
| Svelte 5, even in the same project.
| cube00 wrote:
| Great until your dependency scanner picks up a vulnerability
| in the framework or a dependency that can't be upgraded
| without breaking v4, no exemptions can be given and the only
| updated version is 5. [1]
|
| [1] https://endoflife.date/svelte
| Capricorn2481 wrote:
| If it's already end of life you can fork it and upgrade the
| dependency. You'll miss nothing. This is only difficult if
| you need to maintain changes upstream, but that's not the
| case here.
|
| Security support lifetimes make sense for a widely used
| language or runtime, but not really a frontend web
| framework on the most backwards compatible language you can
| have.
| austin-cheney wrote:
| Front end development is a 90% self-induced hell. There are
| real challenges like accessibility, processing data from
| service calls, architecture, and more.
|
| Those aren't the things most developers complain about. Most
| front end developers spend their energy on concerns of code
| style, tools, build steps, framework madness, state management,
| and more. Those are fashion concerns. A decent programmer can
| solve for most of those themselves without external tooling in
| a fraction of the time and code size, but not everybody that
| does this work is confident writing original code.
| Etheryte wrote:
| I can't even begin to count the number of codebases I've seen
| where developers rolled with this idea and ended up with
| royal spaghetti. Everyone thinks they can build these
| frameworks from scratch, but they overlook the unknown
| unknowns. Nearly every custom implementation of state
| management, complex forms, async flow management, etc I've
| seen in the wild is riddled with countless bugs that could've
| been avoided if they just picked a boring and widely used
| library. And I've seen plenty, because I'm usually the guy
| that gets called up when no one else can untangle it anymore.
| austin-cheney wrote:
| Yes, I have seen that countless times too. Developers that
| have no idea how to write original software think they can
| go without a framework and then write a framework. That is
| stupid, and its because those developers know something
| about frameworks but never learned to program. Stop toying
| with irrelevant nonsense and actually release a product for
| users that solves from some real business requirement,
| which is certainly not a framework.
| johnfn wrote:
| State management is absolutely a real front end concern.
| That's what you're going to be spending a lot of your time
| on; you better make sure you do it well. Code style is
| roughly a solved problem thanks to Prettier, as is build
| steps with Vite. And I don't know what you mean that
| "framework madness" is a fashion concern. You have to pick a
| framework, you can't just avoid that part.
| austin-cheney wrote:
| Yes, it is a real concern, but its supremely trivial to
| solve for. Frameworks make this into chaos madness because
| frameworks have to solve for both the goal of state
| management in addition to their own divisible component
| concerns that come and go with user interactions.
| johnfn wrote:
| I'd be very interested to hear how state management is
| supremely trivial to solve for.
| austin-cheney wrote:
| Ummm, no. I have been through this before and its always
| a paradox.
|
| The paradox works like this: If you were capable of
| writing your own software the triviality of state
| management becomes self evident. If you are not capable
| of writing your own software, such as full eternal
| reliance on some tool set or framework, then the answer
| doesn't matter.
| skydhash wrote:
| > _State management is absolutely a real front end concern_
|
| That's because most SPAs are duplicating backend logic.
| johnfn wrote:
| A certain subset of SPAs need to duplicate backend logic
| because they necessarily and unavoidably have local
| state. For instance, optimistic updates require some
| redundancy with backend logic.
| greenchair wrote:
| thanks, I'll reuse that one!
| mlsu wrote:
| In many cases this is true (typical CRUD apps), the tools
| (react etc) are too way too heavyweight for the job. It may
| even be some large % the case that it is a self-induced hell.
|
| However, I think frontend is often quite underrated in its
| essential complexity. I don't share the opinion that state
| management is a fashion, it's often tightly intertwined with
| the UX requirements, which can be varied and have all kinds
| of difficult essential complexity of their own (often
| complexity that is under-specified, and up to the programmer
| to discover).
|
| The lack of experience of many frontend devs, combined with
| the limitations of dynamically typed Javascript, is a recipe
| for a lot of very gnarly code. Maybe it would be fair to say
| that this is self-inflicted, but I am sympathetic. It's quite
| a difficult problem.
|
| When I think of 'total own-goal', completely pointless self-
| inflicted hell, I think of Python package management.
| npn wrote:
| I'm so tired of those comments. It's almost always come from
| those who refuse to research before they talk, only echo what
| they learned from other people.
|
| Do you know why there are new frameworks, new versions every
| time? Because web is a moving target. New js/css/html5
| features are released every day and the libraries have to
| update to adopt them.
|
| Back in the day you do not have css variables, so you have
| either use sass and do all the math inside the preprocessing
| process, or crazier, using those shitty css-in-js libraries
| to calculate css properties on the fly. Nowadays you can pass
| around the variables and it can cover almost all the case. In
| able to pass the css property to the component, you need to
| improve your framework.
|
| Another example is html5 history API, back in the old days
| people implemented link components in SPA with buttons
| (hilarious but it happened), only after History API is
| introduced there raised the need to manipulate the history
| properly, thus another rewrite issued.
|
| before that, ES5 introduced `class`, proving yet another way
| to write js code, which in some situation make cleaner code
| than the plain old js functions.
|
| everything in the web is moving, new nice things are
| introduced every month, if you want to create a modern and
| performant web application, you need to keep up with the new
| fancy things, frameworks are no exception for that.
| johnfn wrote:
| What does this have to do with frontend work? Major version
| updates are common across any part of the stack. Just off the
| top of my head, SQLAlchemy has a seven step migration
| process[1] from 1.4 to 2.0, and it's absolutely not the kind of
| thing you could pull off in a few days if your code base has
| grown past a certain size.
|
| [1]:
| https://docs.sqlalchemy.org/en/20/changelog/migration_20.htm...
| afavour wrote:
| Honestly it's exhausting seeing endless posts from people who
| don't do frontend development saying "wow, looks awful!" having
| made zero effort to actually understand the scenario.
|
| > They seem to have no respect for peoples time or any
| consideration for longtermism or even just the common decency
| of backwards compatibility
|
| You mean Svelte 5, the backwards compatible framework that
| makes all of its new features an optional opt-in? That one?
|
| > What are we at now, React 19?
|
| Allow me to introduce you to the concept of semantic
| versioning, otherwise known as "a versioning system that has
| defined meaning". _Any_ breaking change means a new major
| version, which is why the numbers increment at a rate that is
| apparently terrifying. These breaking changes are often
| absolutely tiny and trivial to adapt to.
|
| I don't even like React but the upgrade path between major
| versions is rarely a big deal. You're taking a non-semantic
| versioning mindset (new version number? Guess I have to rewrite
| everything!!) and applying it in a scenario where it doesn't
| fit.
| jauntywundrkind wrote:
| > _Honestly it's exhausting seeing endless posts from people
| who don't do frontend development saying "wow, looks awful!"
| having made zero effort to actually understand the scenario._
|
| There's much bigger topics afoot in the world that also make
| me think humanity desperately needs better tools to defend &
| equip ourselves with broadscale collaborative efforts to shut
| down & reject-by-default negative-valence posts.
|
| The hater-squad has the easiest job on the planet attracting
| some fellow people who also want to resist learning, change,
| or who want to feel more secure in their current position.
| The Dark Side is strong.
| zx0r wrote:
| > Honestly it's exhausting seeing endless posts from people
| who don't do frontend development saying "wow, looks awful!"
| having made zero effort to actually understand the scenario.
|
| Inevitably we will see it in every front-end related thread
| until the end of time.
| morsecodist wrote:
| There is really no place where updating dependencies is
| dramatically better. Back end frameworks and even whole
| languages have this problem. On the front end, I mostly use
| React and it has been fairly backwards compatible. It's a
| tradeoff. If you never ever make breaking changes you can end
| up constrained by previous design decisions. If you make them
| all the time users won't be able to keep up.
| smt88 wrote:
| > _There is really no place where updating dependencies is
| dramatically better_
|
| This is absolutely untrue. There's a huge gap in how easy it
| is to upgrade some stacks vs. others.
|
| Updating dependencies in a language with strong, static types
| and/or an expressive type system is incredibly easy, for
| example:
|
| Step 1: update dependencies
|
| Step 2: fix compiler errors
|
| Upgrading major versions of .NET, for example, sometimes
| requires _no work at all_.
|
| This is not true in JavaScript, Python, and some other
| languages where you're only going to discover issues during
| runtime.
|
| TypeScript makes things a lot better, but you're relying on
| the authors of your dependencies either using TypeScript or
| keeping types up to date.
| morsecodist wrote:
| I was a bit broad here. I am sure certain projects get
| things better than others. When I said no place I was more
| referring to whole categories of development like, front-
| end, back-end, embedded, data pipelines, ect...
|
| I love types and advocate their use whenever possible. They
| help a lot but they are a spectrum. Thanks to static
| analysis tools like TypeScript or even eslint you can get a
| bit towards automated checks on front end code. Also even
| compiled languages can miss some things, different
| languages have type systems that give you different kinds
| of guarantees. For example, Java has NPEs that can't be
| caught at compile time.
| KronisLV wrote:
| > There's a huge gap in how easy it is to upgrade some
| stacks vs. others.
|
| This I can agree with.
|
| > Updating dependencies in a language with strong, static
| types and/or an expressive type system is incredibly easy
|
| Java would typically be regarded a pretty close to .NET in
| regards to its type system, yet I've seen plenty of issues
| with updating dependencies, whenever you have any sort of
| dynamic class loading or reflection going on: be it Lombok
| or MapStruct not liking a specific version of Java, or
| Spring Boot or one of its many integrations throwing errors
| during startup after a successful compile, sometimes even
| disliking specific annotations that worked previously.
|
| A decent type system will help you make sure that the code
| compiles, sure (and I'm thankful for that), but with some
| styles of writing code and handling, for example,
| dependency injection, all bets are off. The same goes for
| any dependencies that make liberal use of those features.
| I'd have to dig around for specific examples, but I know
| for a fact that there are plenty of projects that are stuck
| on old versions of Spring for that very reason.
|
| Or the fact that there are plenty of pre-.NET Core projects
| out there that won't be upgraded to anything new anytime
| soon for similar reasons.
|
| In my experience, updates suck across the board, the only
| variable is how much. And that applies to everything not
| just dependencies in code (and runtimes): I've also had
| seemingly innocuous Debian updates break GRUB and prevent
| the OS from booting, or even upgrades making exim4 start up
| for some reason and taking up the port that my mail server
| needed, preventing it from starting.
| dustingetz wrote:
| developers get what they pay for. When one values their time at
| zero, vendors also value it at zero.
| raincole wrote:
| > You're telling me you updated YOUR code to work with the
| latest framework release?
|
| Next time I'll tell you how people used to update their code to
| use Python 3! Shocky-shocky.
| procaryote wrote:
| That was also an obviously terrible idea, iirc to the point
| even python leadership aims to never do it again
| Capricorn2481 wrote:
| And yet Scala did it next. And both were dramatically worse
| than what is happening here. Just frontend FUD
| sergiotapia wrote:
| That's javascript ecosystem in general. A revolving door of
| breaking changes and yet another web framework. Not to mention
| many many many tiny libraries.
|
| To give you a simple example.
|
| "What's the best web framework these days for fullstack JS
| work?"
|
| Ok, Hono, found that. Installed it, great, it even runs well
| with Bun. Holy shit, it seems like JS is catching up! But now
| how do I talk to my database? Hono has no such thing, you're on
| your own.
|
| Ok, let's use Prisma but setting that up there is no one-true-
| way, it's all blog posts and praying you followed the right
| one. Also Prisma seems to now work with joins?
|
| Migrations? You set that up manually.
|
| Deploying is another story.
|
| Very painful.
|
| ---
|
| Compare to Laravel, Rails or Phoenix. All these things baked
| in, one blessed paved road to tackle the common things 99.9% of
| web apps need. We are blessed to have all this great work for
| free, right at our fingertips. People donated a lot of time and
| love into building them. I hope javascript one day reaches that
| level.
|
| It's still cowboyitis out there.
| zx0r wrote:
| > Ok, Hono, found that.
|
| Weird that you went with some framework I've never heard of,
| and that definitely does not come up when I google for best
| fullstack JS framework.
|
| > Ok, let's use Prisma but setting that up there is no one-
| true-way
|
| Maybe the docs? https://www.prisma.io/docs/getting-started
|
| > Deploying is another story.
|
| I mean deployment always brings some complexity, but for the
| majority of JS frameworks you can get started by building it,
| throwing it in a docker container, and hosting that
| somewhere. I don't see what's difficult about that
| madeofpalk wrote:
| I've never heard of any of these tools. Maybe you should be
| more critical of the answers you get?
|
| I've been sitting here as a react developer, quite stagnent
| in my toolset, using the same React I've been writing since
| 2015. The 'newest' technology I picked up was Typescript back
| in 2019.
| mardifoufs wrote:
| React has been almost fully backwards compatible going back to
| version 1. If you have react code that worked 10 years ago it
| will almost certainly still work just fine right now. That's
| more than a lot of other platforms. Higher number doesn't mean
| less backwards compatible.
| madeofpalk wrote:
| "What are we at now, Ubuntu 24?"
|
| For what it's worth, between 2011 and 2016, React shipped
| versions 0.0.1 to 0.14.0. Then in 2016 they said "fuck it,
| we're stable now" and jumped immediately to 15.0.0 (they
| considered 0.14.0 to be mostly equal to 14.0.0).
|
| Then they did 16 in 2017, 17 in 2020, 18 in 2022, and 19
| finally in Dec 2024. I don't think 4 major versions in ~9 years
| is a world breaking amount of churn. I have my problems with
| the team's development of React, but I think they have a pretty
| sensible view of breaking changes and limiting churn.
| conradfr wrote:
| Personally I've picked Vue over React like height years ago and
| it's been mostly great, never regretted it.
|
| Also StimulusJS and htmx are good for simple cases as long as
| you don't need a global state IMHO.
| wetpaws wrote:
| People who use observables-based frameworks are asking for
| trouble.
|
| Every single industrial scale project I saw was inevitably
| breaking apart on seams.
| mrj wrote:
| Very different in my experience but implementation matters.
| I've been using mobx for years with great results, largely
| because I move all of the logic out of components into stores.
| I think that's the actual key, since most hooks-based and other
| solutions rely on a lot of component logic that becomes frail
| and error-prone. Instead, making the view layer _only_ view
| vastly improves development complexity by making a layer
| responsible for the data that is separate from rendering.
|
| My components do as little as possible other than render html
| and bind the occasional event handler to a store function. With
| this in place, development scales much more easily than layers
| of hooks.
| brink wrote:
| That's why I like it. I did 8 years of React, and I hope I never
| have to touch it again. When I was forced to use Remix, it just
| about broke me.
| dimgl wrote:
| This sounds like a Remix problem more than a React problem. I
| really enjoyed the ideas behind Remix actually! In fact, I
| found that having both server and client code in a single file
| (a-la Next.js) made me super productive. And nowadays I bet it
| pairs well with LLMs due to having the full vertical slice
| available in the agent's context.
|
| I really wanted that framework to take off.
|
| But that community is straight toxic... I have not seen a more
| toxic community than the React Router community. It's one of
| the reasons I stopped using Remix. React Router 7 is actually
| pretty cool; I recently built a prototype on it and was
| surprised by how well it worked. But I know I'll eventually
| need some kind of support and feedback, and I can't imagine
| engaging with those devs/that community again...
| brink wrote:
| It's worth noting that I only did Remix for like 6 months
| last year. My big issue was it's intentional inflexibility.
| It creates a very narrow and inflexible mold for you to build
| your site into, creating a framework where the "cure" is
| worse than the problem. They make a huge selling point of
| loading nested data, loading the nested components with their
| data in parallel. I have never seen that to be a huge
| problem, in my experience of React - complexity has been the
| problem, and that's something that Remix makes worse, not
| better.
| k__ wrote:
| Yeah, React really fumbled the bag with server components.
| DeathArrow wrote:
| Want a sane frontend experience? Use vanilla Javascript, use web
| components, use htmx, use Blazor.
|
| JS frameworks for some reason or other are a madness.
| OtomotO wrote:
| Absolutely! I am killing a huge React app step by step and
| replacing it with HTMX.
|
| Best thing I did in many years for that project.
| davely wrote:
| I often read these threads on HN and they make me feel like
| that I am perhaps a horrible software engineer or just
| weird...
|
| I _like_ building things with React.
| sampullman wrote:
| I think it's really context dependent. If you've been
| banging your head against the wall working on a poorly
| architected React codebase for years, anything else
| probably feels like a breath of fresh air.
|
| If you have a nice codebase with good separation of
| concerns (that everybody adheres to) and reasonable library
| choices, you'll be happy regardless of what framework
| you're using.
| greenchair wrote:
| as long as you like it, keep using it! I wouldn't try to
| make generalizations from the HN or reddit bubbles.
| luketheobscure wrote:
| Honest question - have you ever tried to use the actual web
| components API? It very much feels like a set of primitives to
| build a framework on top of. I can't imagine the amount of
| boiler plate you would need to write to just use web
| components.
| breadwinner wrote:
| With a simple 500-line lib you can write Web Components just
| like React, here's an example: https://github.com/wisercoder/
| uibuilder/blob/master/WebCompo...
| mdhb wrote:
| Right and Lit is that exact framework and it's amazing.
| rpastuszak wrote:
| State management for smaller vanilla JS projects that works
| 9/10 times for me: const state = new Proxy(
| {}, { set(target, property, value) {
| target[property] = value; renderUpdate();
| return true; }, } );
|
| I'm only 1/4(.0000000004) serious here. That said, I've been
| doing this for almost 30 years, I was a kid when I picked up
| Netscape, I have gone through every mainstream and many niche
| libraries/languages replacing libraries. Now, in my late 30s I
| finally can grow a moustache (a big achievement in my family
| gene pool) but the analysis paralysis is still making me
| anxious every time I pick up a new project.
|
| - preact w. signals or Svelte are still my libraries of choice
| if I need to spike something, but that's partially because of
| signals and vite. The development experience is good, there
| isn't much magic you need to deal with on a daily basis.
|
| - Web Components are great in many ways, but they don't solve
| the problems I usually have with bigger projects (scaling
| state, orchestration for the lack of a better phrase). Lit
| makes it a bit better though.
|
| - JSX is actually not that bad, as long as you treat it as a
| DSL around functional composition. Native JSX + signals would
| probably make most of my node_modules redundant.
|
| (please don't overthink this, I didn't)
| replete wrote:
| If you want your own Web Components, you're going to build an
| entire framework around the creation and management of them
| because making proper 'web components' for your project is in
| effect a whole other project
| dimgl wrote:
| I really have not liked htmx at all. Anything dynamic with it
| is a big, big pain...
| GrumpyCat42 wrote:
| IME a lot of the pain comes from picking the wrong tool for
| the layer.
|
| By that I mean saying everything has to be a JS framework or
| everything has to be server-delivered-HTML.
|
| For very dynamic & interactive things maybe it makes sense to
| write it just in JS without a framework?
|
| For full pages for data-powered applications (that heavily
| benefit from types & Typescript), maybe it makes sense to use
| something like Golang on the server.
|
| And then you can embed those interactive dynamic islands
| inside the data-intensive application, with a thin layer of
| communication between the two.
|
| Just my 2c - I've found that pattern to be super compelling
| mixmastamyk wrote:
| Use Alpine for dynamic client-side. Htmx is focused on
| talking with the server.
| dimgl wrote:
| I should have clarified that yes, I used Alpine with htmx.
| url00 wrote:
| I agree. I really wanted to like it, I do think a lot of what
| it purports to try to do would be better for the web and
| development in general, but my experience is that HTMX (even
| with Alpine) fails to succeed in practice.
| pwdisswordfishz wrote:
| How is Blazor not a JS framework?
| mardifoufs wrote:
| Using blazor as an example of sane web development is so odd to
| me. Have you actually used it? Not only is it a mess in terms
| of development (live reloading basically does not work, you
| either depend on SignalR and your website becomes unusable the
| second you lose connection, or use wasm and have a terrible
| mess of a canvas based frontend that barely works), but it's
| also terrible for users.
|
| I know hating on frontend dev is trendy, and I guess blazor is
| the logical end to that aversion to actually using frontend
| tools, but if anything it's the perfect example to show how
| much worse web dev would be without JavaScript frameworks.
| There's a reason it's only used for internal tools.
|
| I'd take any react+JavaScript "bloated" websites over this.
| Especially on mobile. https://bootstrap5demo.blazorise.com/
| xrd wrote:
| I wasn't so excited about runes when they first came out. But,
| when I could create a reactive external component that I can
| import into a .svelte template, AND that internally encapsulates
| reactivity, my opinions changed. That means you can write vitest
| tests against it, but get the benefits of reactivity. That is
| truly powerful and, AFAIK, unique in the frontend world.
|
| But, most frontend people don't do testing at all. Typescript is
| the tool people use to guarantee correctness, and for good
| reason. But, svelte people have always cast a narrow eye towards
| typescript and for good reasons as well. So, here we are.
|
| I personally prefer writing testable frontend code, and Svelte 5
| is revolutionary in that way. It is as good as unit testing, but
| reactive in the browser.
|
| Having said all this, the blog post rings true. Adding proxies
| feels very uncomfortable. React and Vue lost me when they started
| adding abstractions on top of abstractions and proxies were the
| gateway drugs.
| CharlieDigital wrote:
| > ...when I could create a reactive external component that I
| can import into a .svelte template...That means you can write
| vitest tests against it, but get the benefits of reactivity.
| That is truly powerful and, AFAIK, unique in the frontend
| world.
|
| Isn't this the same as Vue composables?
|
| Composable: https://github.com/CharlieDigital/vue3-state-
| definemodel/blo...
|
| Vue Component: https://github.com/CharlieDigital/vue3-state-
| definemodel/blo...
|
| BTW, I agree it's a very good pattern in general; especially
| good if you end up reusing logic with different templates/UI.
| xrd wrote:
| Can you share an example of a testable vue component? I would
| like to see that.
|
| I got disillusioned around Vue 2. When they had proxies in
| front of class attributes that looked like functions, it
| really made it hard to instrument inside of tests. Maybe this
| is fixed now. But, it left a bad taste in my mouth.
| CharlieDigital wrote:
| The VueUse library is a really good place for these since
| it's all composables like `useClipboard`.
|
| Here's an example of a Vue composable for the clipboard: ht
| tps://github.com/vueuse/vueuse/blob/main/packages/core/use.
| ..
|
| Here is an example of how it's used: https://github.com/vue
| use/vueuse/blob/main/packages/core/use...
|
| And the unit tests: https://github.com/vueuse/vueuse/blob/m
| ain/packages/core/use...
|
| Another one from the same lib: https://github.com/vueuse/vu
| euse/blob/main/packages/core/use...
|
| Unit test: https://github.com/vueuse/vueuse/blob/main/packa
| ges/core/use...
|
| I'm pretty certain that Svelte took inspiration from Vue
| composables and I'd also guess that the community will have
| a bit of friction before people start to get its use cases
| (same as it was with Vue when it was introduced).
| MrJohz wrote:
| With Vue 3 and the composition API, you can do basically
| the same things you're doing in Svelte. You can also add
| SolidJS and Preact to this list as well - the magic
| ingredient in all these frameworks is signals, which allow
| you to have reactive data without having to have a UI
| framework to provide lifecycle events.
|
| A good example in Vue is the top example in this page:
| https://test-utils.vuejs.org/guide/advanced/reusability-
| comp... The other examples show some other things you can
| do if you want, although I'd typically recommend against it
| - keep your signal-related code free of
| component/lifecycle-related logic, and it will almost
| always be much easier to test.
|
| (As an aside, I'd add Angular to the list of frameworks
| that are easy to test, although the framework feels like it
| goes out of its way to convince you of the opposite.
| Services are just classes that maintain reactive data -
| originally via RxJS/Observables, although now signals are
| also supported - and if you keep them like that, they're
| fairly easy to test. Unfortunately, Angular's
| decorators/DI/module system is very pervasive, and at least
| when I was last using it, meant that even theoretically
| simple tests still needed lots of boilerplate. But
| theoretically, it belongs in the same category as the
| frameworks above.)
| CharlieDigital wrote:
| > ...the magic ingredient in all these frameworks is
| signals, which allow you to have reactive data without
| having to have a UI framework to provide lifecycle events
|
| This is something that I think a lot of devs don't fully
| appreciate. A recent writeup on the inverted reactivity
| model of React: https://chrlschn.dev/blog/2025/01/the-
| inverted-reactivity-mo...
|
| And short video walkthrough: https://youtu.be/7OhyP8H7KW0
| wk_end wrote:
| I feel like I must be misunderstanding you. React is certainly
| unit testable and developers do test it - just ask react-
| testing-library (10M weekly downloads).
|
| I'm not a Svelte dev, so I don't really follow the distinction
| you're drawing. What is it that supposedly makes Svelte more
| testable?
| xrd wrote:
| I haven't used React in a while so I'm happy to learn more.
|
| When I look at this example it does not look like the code I
| would be using inside my webapp. I have a rule of thumb: my
| test code should look the same as the code when it is inside
| my app.
|
| https://testing-library.com/docs/react-testing-
| library/examp...
|
| My Svelte 5 runes test code uses the code in exactly the same
| way that I use it inside my .svelte templates. That's very
| different in my opinion.
| zdragnar wrote:
| testing-library (and react-testing-library by extension)
| has a very dogmatic "black box" approach to testing FE
| code. In many ways it more closely resembles e2e testing
| than more traditional unit testing does.
|
| Personally, I think it's a PITA since it's pretty rare that
| copy (such as text labels) ever remains stable for very
| long, or are sufficiently unique on the page, so I do the
| "strongly discouraged" route of using data-testid
| attributes for everything (which also has the side effect
| of making people who write e2e tests happy, but I digress).
|
| With all of that said, I find myself rather appreciating
| the approach. I don't need tests to mirror the
| implementation, only the interface.
| wk_end wrote:
| Can you link to/post an example of how Svelte is tested
| that's different?
|
| In the Full Example linked, the only code that it makes
| sense to talk about being in the app itself is the code to
| render the component, and that does look precisely the
| same.
|
| The rest is the testing logic - inspecting the state of the
| DOM post-render, interacting with components by simulating
| events, and so on. I don't see how this could correspond to
| anything in the app proper.
| crab_galaxy wrote:
| Yeah to be fair testing a fetch request is not the best
| example right off the bat. That's an outlier IMO.
|
| That said it's very very easy to write similar looking code
| using react testing library as long as you're good about
| separating business logic into a hook. Where it gets dicy &
| hard to test is when components have complex state/effects
| co-mingling with render logic.
|
| Business logic is very easily testable as a hook, something
| like:
|
| ``` it('toggles switch state', () => { const {current} =
| renderHook(() => useSwitchState);
| expect(current.checked).toBe(false);
| current.toggle();
| expect(current.state).toBe(nextState);
|
| } ```
|
| Render logic is a bit different because React Testing
| Library's philosophy is to test _as a user would interact
| with the UI_ , so that looks more like:
|
| ``` it('switches state on button click', () => {
| render(<Switch onToggle={mockOnToggle} checked={false} />);
| getByRole('switch').click();
| expect(mockOnToggle).toHaveBeenCalled();
|
| }); ```
| jonstaab wrote:
| This is something I didn't cover in my post, but I feel that's
| a bug, not a feature. Using runes instead of stores (which did
| the same thing in svelte 4) implicates the svelte compiler in
| every source file. This is ok if you're married to svelte, but
| it makes vendor lock-in even more rigid, since you would have
| to refactor all your regular utilities too when moving to a new
| framework.
| tmnvix wrote:
| > svelte people have always cast a narrow eye towards
| typescript and for good reasons as well.
|
| Out of curiosity, could you elaborate on this a little?
| crummy wrote:
| Svelte supports TypeScript, but the project itself dropped it
| for JSDocs a year or so back.
|
| Here's a discussion on it, with the first post from Rich
| Harris himself with some reasoning:
| https://news.ycombinator.com/item?id=35891259
| gavmor wrote:
| > It is as good as unit testing, but reactive in the browser.
|
| I am confused about this because on the one hand, you seem to
| be hinting at my favorite, under-hyped aspect of testing, which
| is its use (via TDD) as a controlled-state print/debugger, but
| on the other you seem to be eliding the most popular--albeit,
| in my view, less important aspect (insofar as one aims for
| "working software over comprehensive documentation"[0])--the
| preservation of behavior across commits and into the future.
|
| What am I missing?
|
| Edit: re "reactive in the browser," that's how I run
| @benchristel/taste[1]
|
| 0. https://agilemanifesto.org/
|
| 1. https://github.com/benchristel/taste
| voat wrote:
| I appreciate that the author acknowledged that there must exist
| some reason(s) for the changes that he is unaware of.
|
| I appreciate Svelte's new architecture, it's going to help people
| make smaller, faster apps, even it requires you to learn about
| how it's reactive system works.
| amazingamazing wrote:
| It's a shame EmberJS fell by the wayside. The API has been pretty
| stable for a decade now. Ironically someone who wrote their
| EmberJS app last decade would have less trouble migrating than
| someone who did the same with React, Svelte, Vue, etc.
|
| Sadly the Ember team made some strange decisions in the beginning
| and it wasn't easily grokable compared to regular JavaScript
| (most of that has been fixed now, though).
|
| This is all to say that whether or not it's JavaScript doesn't
| really matter, compared to the stability of the API.
|
| My personal problem with JavaScript is that things keep changing
| too much.
| lelandfe wrote:
| I unfortunately learn best by book. I hunted for a React book,
| against the advice of the community, and found one that was
| current circa v18. It opens by saying the absolute standard for
| making React sites is create-react-app... which just got
| deprecated.
|
| And any book older than that is useless due to class syntax or
| predating hooks. Just 3 years to turn a resource into a door
| stop.
| yourapostasy wrote:
| So how up to date and idiomatic all the React code shoveled
| into production servers by LLM's can be, if their training
| data is mostly riddled with deprecated styles?
| combyn8tor wrote:
| The linter picks them up. Then you pass the linter
| warning/error back into the LLM until the linter stops
| complaining. Then the slop compiles.
| TSiege wrote:
| I haven't used EmberJS in 10 years and was eyeing svelte for
| some personal projects. Given this article it's made me shy
| about that. Maybe it's time to look at ember again. I know
| vanilla JS + htmx is mentioned elsewhere here and worth
| exploring too. However, as you've said a stable API is very
| nice these days in the JS world
| earthtograndma wrote:
| Ember is working through a migration replacing their build
| system and bundler with Vite -- all while maintaining
| backwards compatibility to a version released in 2021. Ember
| will be fun to watch in the coming year.
| real_ate wrote:
| Depending on how you count it that could be a version
| originally released in 2018 i.e. the version they are
| aiming to support is 3.28 which you should be able to
| easily update to from 3.0 (which was released in 2018)
| since it's a minor update with no breaking changes
| eterm wrote:
| I've witnessed a company that started moving away from their
| KnockoutJS solution to react.
|
| In that time, the knockout parts have kept going strong. The
| react parts have seen three different paradigms ( React
| classes, Functional react with redux, React Hooks ) and still
| hasn't fully settled down given there's also churn in the CSS-
| in-JS space.
|
| The very occassional time something in the remaining knockout
| parts need fixing, it's just a harsh reminder that it worked
| fine.
|
| I'm fairly sure the react portion is still not even on the very
| latest version of react because some other dependencies are
| stuck on older versions and they themselves have breaking "API
| changes" (i.e. complete rewrites with no semblance to the
| original ).
|
| As someone here also said, maintainers in the JS/TS ecosystem
| appear to have no respect for their users.
|
| It might sound entitled, but sometimes not completely rewriting
| your framework's API to a completely incompatible one is a
| better choice. Even if that means putting up with a slightly
| worse API than you'd like.
|
| I guess everyone moves so fast that there's a fear that
| sticking on the old API would just lead to dying off at the
| hands of a new upstart with a smoother API.
|
| But the alternative is a constant abandonment of projects. If a
| major version change requires a complete re-write then really
| the new version is a new project entirely that's re-using the
| namespace and maintainership.
|
| But perhaps emberJS fell away precisely because it didn't
| rewrite itself to stay "modern". Maybe this is a "worse is
| better" situation where the world optimises for the wrong
| things.
|
| "Has had a mostly stable API for a decade" just isn't something
| people select for. If it were, then things like ASP.NET would
| be far more popular.
| voat wrote:
| React has had a mostly stable API for over a decade
| eterm wrote:
| How so? Hooks are only ~5 years old.
|
| Meanwhile they've deprecated parts of the class components.
| nullvoxpopuli wrote:
| I have a number of ember projects on vite if anyone wants to
| take a look:
|
| - https://github.com/krausest/js-framework-
| benchmark/pull/1835... -
| https://github.com/NullVoxPopuli/markdown-table-viewer -
| https://github.com/NullVoxPopuli/package-majors (older, needs
| update, which i can do pretty quickly if i remember to do it)
| maeil wrote:
| > My personal problem with JavaScript is that things keep
| changing too much.
|
| JavaScript itself barely changes - it's the flavor-of-the-month
| frontend frameworks that do. What language feature is commonly
| used now that wasn't 5 years ago? Some nicer builtin Array
| methods I guess?
|
| There's a lot of dislike on here for Typescript as a backend
| language. But the difference with the frontend world with its
| dozen everchanging frameworks is striking. On the backend side,
| most projects don't even use a framework, and for those that do
| basically all of them use the same one (NestJS). And the rate
| of breaking changes on that has been much lower than something
| like React.
|
| Of course, many will say that this lack of industry-wide
| adopted framework in itself is what they dislike about it. But
| it's hard to settle on that golden mean inbetween both extremes
| when it's the most popular language in the world (in terms of
| "Yearly new LOC going into production"). Python makes for a
| good contrast, with a dozen popularish backend frameworks. Not
| sure if that's really a better situation to be in, there's pros
| and cons.
| 91bananas wrote:
| And to expand on this further, I think the real driver of the
| "javascript always changes" is React. Depending on when your
| React project was built, it can be incompatible in so many
| different ways with a React project from a different vintage.
| Sure, a lot of other frameworks and tools that pop up here
| and there, but none of them are ever widely adopted. When
| compared to Vue and Angular which I think we can all agree
| are the other two frameworks of note, React has been very
| unstable, Vue and Angular appear quite stable.
|
| The javascript language itself hasn't really had a breaking
| change of note that I can remember in the last 15 years? It's
| just expanded its API from years and years of browser
| implementations trying stuff and trying to get to an actual
| standard. HTML5/ES6/CSS3 brought a new kind of baseline
| sanity to the whole thing. That's not to say it's a perfect
| language without quirks, but to say it keeps changing is just
| not even accurate at all.
|
| python has version evolution, C++ has version evolution, they
| kinda all do...
| tracerbulletx wrote:
| A React class component from 10 years ago will still work
| in React today perfectly well, and is doing so in large
| codebases around the world.
| LegionMammal978 wrote:
| Then again, React _projects_ tend to use fast-moving
| things on top of React, like Redux or NextJS or CRA or
| whatever. Personally, I enjoy writing stuff in bare React
| since I like its model, but people tend to steer well
| clear of that, especially these days with compilers and
| bundlers and whatnot attached to the frameworks.
| tracerbulletx wrote:
| I agree, bundlers and bundler plugins have probably been
| the main thing people see with JS ecosystem and think is
| overly complicated.
| eterm wrote:
| > A React class component from 10 years ago will still
| work in React today perfectly well,
|
| This isn't true.
|
| ComponentWillMount and related methods were deprecated
| and then removed.
|
| Yes, they allowed an escape hatch of
| UNSAFE_ComponentWillMount etc, but that still requires
| work to make it compatible, so it definitely doesn't
| "[work] perfectly well".
| rbower wrote:
| Have you worked with Angular much? I've built extensive
| component libraries (internal) for my org and maintaining
| the Angular one has been a nightmare. The frequency of
| breaking changes and conventions has been awful,
| particularly in the last few years. React, by contrast, has
| been a breeze ever since they introduced Context and Hooks.
|
| On the app development side, we dealt with 3 major
| overhauls of PrimeNG's style system before we decided to
| invest in a custom library just to eliminate the risk of
| future upgrades. It took us 6 months to migrate our Angular
| 9 app to 18 because of the PrimeNG dependency. Granted,
| it's a massive application and they didn't maintain it
| properly, but I'd hardly call Angular stable regardless.
|
| And then you have the Vue composition API, which was a
| major shift from Vue 2.
|
| This isn't to say that React has been perfect. Depending on
| your stack, there are certainly a fair degree of breaking
| changes (looking at you, Next.js and react router). But
| that is far from abnormal in the JS world.
| holler wrote:
| Agree, overall ember has felt stable and only improved with
| age, unfortunately becoming increasingly niche.
|
| At my company I mentioned using it in passing to our cto as we
| were discussing a project to move our core web app from angular
| to react, and he laughed saying "maybe if this was 10 years
| ago!".
| sagolikasoppor wrote:
| I used Ember and it sucked. It was too complicated and the
| community was elitist and hostile. Then it got extremely woke
| and political and even shut down the docs which made me lol and
| really dislike the project and its authors.
| pier25 wrote:
| > _My personal problem with JavaScript is that things keep
| changing too much._
|
| Yeah.
|
| Last year I realized in my 10 or so years using Node I've
| changed my stack so many times (Express, Hapi, Fastify, Hono,
| Sequelize, Objection, Prisma, Drizzle, Mongo, Fauna, Postgres,
| Firebase, etc etc). So much time wasted.
|
| Surprisingly, on the frontend I've found stability with Svelte.
| I've been using for 4-5 years now and still very happy with. I
| also love runes.
| beders wrote:
| And here I am flinging hiccup and Reagent for years now without
| any major changes. Reagent has been around since 2013. They even
| survived the transition to functional React components without
| major changes. The hiccup I wrote 5 years ago is still perfectly
| fine.
|
| The _only_ issue we have is JS UI libraries we depend on who have
| a funny understanding of backwards compatibility.
| jonstaab wrote:
| I wish I had stuck with clojurescript. I found clojure in 2013
| or so but could never justify putting it in production. But
| that would have been a good 12 years of frontend development
| bliss. The clojure team has the right mindset.
| locallost wrote:
| It's a really really well written article, I wish more people
| wrote like this, instead of lazy, tired discourses on frontend
| hell. I did not dive too deep in his examples on Svelte as I
| don't use it, but I understood the gist of it. And I agree with
| the conclusion: "...there is a tradeoff between doing things for
| the user, and giving the user agency". There was always something
| about a lot of developers where they treat the users of their
| code as incompetent and unable to get anything done. So they do
| all sorts of things to make it idiot proof, but this ends up
| making everything more complex.
|
| The take about AI is also interesting, I didn't think about that
| before. If AI is now able to generate a lot of code, maybe being
| able to quickly understand that code is more important than that
| code being clever.
| dimgl wrote:
| Stores really turned me off in Svelte 4 so I was eager to start
| using Svelte 5. I've been using Sveltekit and Svelte 5 for a new
| project and I have to say... React's productivity is still
| unmatched, even if the Sveltekit and Svelte tech is technically
| better.
|
| A couple of things that I found really annoying: all pages being
| named `+page.server.ts` or `+page.svelte` or a variation of that
| makes it hard to easily search for code. The tooling for Svelte
| is also separate from `tsc` and ESLint, making it tricker to both
| integrate into CI and use in dev.
|
| And then there's just weird incompatibility stuff with the
| previous version. For instance, most Svelte packages still use
| stores, like SuperForms, so you have to contend with two versions
| of the world, making writing code really confusing at times.
| Plus, Svelte HMR is still kinda early AFAICT, so it will clobber
| your state when a Svelte module reloads.
|
| I _really_ want to like Svelte. It's significantly faster to
| render and I like the ideas behind it. But React's productivity
| is unmatched.
| jonstaab wrote:
| Funny, because I love svelte stores and use them as much as I
| can over the compiler magic. But that's probably because I've
| never taken the time to learn observables properly.
| brulard wrote:
| > React's productivity is still unmatched
|
| I'm React developer since 2015 and working on side with
| svelte+sveltekit for the last 3 years. For me it's exactly the
| opposite. React was huge upgrade from Angular 1 and jQuery
| development before, but everything goes so much more quickly
| together with Svelte. I understand that there is no one-size-
| fits-all for UI frameworks, and we have different thought-
| processes for lack of a better word, but saying React's
| productivity is unmatched, is very much untrue.
| Fergusonb wrote:
| I've been actively developing a commercially deployed SvelteKit
| application, and I'd like to share some thoughts on my
| experience.
|
| What initially drew me to SvelteKit was its simplicity. After
| setting up the project, I could work on one HTML/JS/CSS file at a
| time, leveraging the benefits of a modern framework without the
| accompanying complexity. This approach reminded me of the early
| days of web development, where dropping HTML files into an Apache
| server was all it took to get things running.
|
| However, it's disheartening to see Svelte shifting away from that
| straightforward paradigm. From the outset, Rich Harris positioned
| Svelte's ease of use and simplicity as its key selling points.
| The current version of SvelteKit isn't bad per se, but I found
| myself preferring the earlier iterations. Back then, I didn't
| have to deal with constructs like `+page` for routing. I could
| place Svelte files wherever I wanted, and they would render
| seamlessly, all while enjoying the advantages of a modern
| framework.
|
| This change adds layers of complexity that weren't necessary
| before, potentially moving away from what made Svelte appealing
| in the first place. I picked it up because I already knew what I
| needed to know.
| barnabee wrote:
| I also can't get along with SvelteKit.
|
| Astro + Svelte seems nice enough if you need it but for most of
| what I do, plain Svelte 5 is great.
| barnabee wrote:
| Svelte 5 is not JavaScript is _why I like Svelte 5_.
|
| There are two major ways I think it's reasonable to do
| frontend/web:
|
| 1. Static HTML or server rednered templates with maybe HTMX .
|
| 2. Compile-to-JavaScript languages/platforms. At a minimum
| TypeScript but given that I think HTML and CSS are actually
| pretty good (for many things), JSX, React, Tailwind, etc, are
| _right out_ , and Svelte 5 along with a few other frameworks
| actually improve things over vanilla TypeScript in my opinion.
|
| So much so that Svelte 5 is the clear winner in category 2 for
| me.
|
| It has nice HTML templating, easy and sane state propagation, and
| features that make it easy to write modular code. It works great
| with CSS and you can often build simple throwaway apps and tools
| in one or two files, as well as bigger, more serious
| applications. It's less magical and surprising that Svelte 4, and
| honestly a joy to use. Luckily I don't care about IndexedDB.
|
| I have no clue why anyone would choose to write a single line of
| JavaScript in this day and age, but each to their own.
| prophesi wrote:
| You'll still be writing Javascript/Typescript with Svelte. What
| the article means by "Svelte 5 is not Javascript" is that all
| of your code outside things like Stores will be compiled in a
| manner that makes it harder to debug, since it's not normal
| Javascript but a Svelte-compiled JS that won't make sense in
| the debugger.
|
| I would opt for better debugger tooling specifically for Svelte
| than strip away the abstractions. Its the lack of a runtime
| managing a virtual DOM that makes it unique and performant, and
| frameworks like React also essentially have their own
| compilation step that obfuscates code. Source maps won't help
| much by itself; the React debugger is where you have a better
| view on your components and how things are wired up.
| barnabee wrote:
| Debugging seems fine to me, theres even the {@debug ...} tag.
|
| TypeScript is a better scripting language than JavaScript,
| Svelte is a better language/model/platform than
| HTML+TypeScript.
|
| React may be your cup of tea but I'd rather write Svelte
| templates every day! Not to mention per-component styles.
|
| Sure, a component inspector devtool would be neat, though.
| Nobody's going to complain about better tooling :)
| nonchalantsui wrote:
| > I have no clue why anyone would choose to write a single line
| of JavaScript in this day and age, but each to their own.
|
| You should already have a clue, you have to write a lot of
| JavaScript in order to get Svelte doing what you'd expect
| outside of very simple components. See these actions as an
| example, and check out the JS file!
| https://svelte.dev/tutorial/svelte/actions
|
| Svelte makes more sense if you enjoy the JavaScriptisms. In
| which it provides enough "magic" for most things, but still
| lets you enjoy JavaScript.
| barnabee wrote:
| No, I write a fair bit of _TypeScript_ when I need to make a
| frontend in Svelte.
| dondraper36 wrote:
| Those who say that they just use htmx instead of frameworks, how
| does it work for you? Do you use libraries like alpine for client
| side interactivity or just write vanilla JS?
| rasso wrote:
| Using Alpine.js is not preventing you from also using vanilla
| JavaScript in the same project. Combined with alpine-ajax it's
| absolutely enough for progressively enhanced semi-dynamic web
| experiences. An example: https://filter-munich.com
| GrumpyCat42 wrote:
| It was very disappointing to see Svelte 5 go the way of React.
| Yes, yes, I understand that it theoretically simplifies things
| and yadda yadda yadda, but after trying to actually use it, it
| felt like I was just using React with a much smaller ecosystem.
|
| Svelte 4 felt awesome because it felt like I was just writing an
| HTML file, sure there was some magic ($:) but for the most part
| things were simple, easy to understand, and it all just worked.
| Runes totally changed that, maybe for the better because of all
| of the things previously cited, but not for my personal
| experience. I'll stop there because I'm 100% covering already-
| treaded ground.
|
| I'm "joining the dark side" by trying the HTMX & Golang combo,
| just to see if I can hack together an on-par DX (which is going
| to be a herculean task, I know).
| stuckinhell wrote:
| htmx has a whole world of major issues too. No silver bullet.
| I'm simply switching back to React, it just seems the dominant
| standard right now.
| sonicgear1 wrote:
| SolidJS is what Svelte5 should have been
| evbogue wrote:
| I wonder how much of these issues are because the author is
| developing a Nostr app with Svelte 5? As a fellow developer of a
| distributed social networking application and protocol I find
| myself making a lot of decisions about where to store and
| validate data that is simply not an issue if you're making a
| traditional SPA working with one server that has
| username/password authentication.
| jonstaab wrote:
| It definitely has bearing on the indexeddb complaint. If I was
| sending proxies over fetch, I would never have noticed. But I
| would expect the callbacks/props thing to be pretty annoying
| for any app that uses portals.
| NetOpWibby wrote:
| The two Github links the author lists at the top of his post
| point to the same issue and in that issue is a solution to his
| problem (use $state.raw).
|
| I've been a fan of Svelte since version 2 or 3 because it was the
| closest I could get to writing vanilla HTML/CSS/JS, whilst also
| enjoying the benefits of a framework (and then using Sass and
| TypeScript). Fantastic.
|
| Svelte 5 made me feel uneasy because runes are weird. After
| upgrading a project with it and working on another project, it's
| not so bad. I like that Svelte 5 disallows you from mixing the
| old and new ways of handling state and the error messages are
| mostly informative.
|
| I see people in these comments talking about htmx and vanilla JS
| being objectively better and...no? For what YOU do, sure.
| Personally, Svelte is still a lot simpler to grok than React and
| for the people that care about benchmarks, Svelte is just as fast
| as SolidJS (I feel like the React crowd could pretty easily
| switch to Solid, the syntax feels similar).
| jonstaab wrote:
| Oops, you're right, here's the other issue:
| https://github.com/sveltejs/svelte/issues/15325
|
| That should shed more light on my problem, which is not just
| due to proxies, but is also a result of props being getters
| under the hood.
| p0w3n3d wrote:
| The article mentions
| https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...
| which is an opening article for me. TBH I was always sure I was
| supposed to go into details, but with more and more people around
| me starting to operate only in high-level abstractions, I started
| to doubt this.
|
| Meanwhile, the abstractions ARE leaky, and I NEED to and SHOULD
| understand the underlying UNIX filesystem because it IS different
| from the Windows filesystem. Should know the inner workings of my
| PostgreSQL RDBMS rather than relying only on hibernate. And so
| on.
|
| Last but not least, I just realised that it is impossible to
| write code in an unknown-to-me framework using LLM, because
| sooner or later I will need to fix the problems that arise
| exactly by going deeper into the inner workings.
| Ameo wrote:
| The part of Svelte 5 which bothers me the most isn't the syntax
| changes for Runes, but rather the significant increase in
| complexity that the new API brings.
|
| The `Proxy`-based state management API is a perfect example of
| this. The intention was to make working with mutable state like
| arrays feel better, but it creates this layer of added complexity
| under the hood with non-trivial performance and functionality
| implications (like the IndexedDB sync issue the author ran into).
|
| Compared to the `let x = 1` paradigm from before, we now have
| three different Runes for state (`$state`, `$state.raw`, and
| `$state.snapshot`) which you need to choose and understand the
| differences between. The added nuance to the way `$effect` works
| which is detailed in the post is in the same vein.
|
| Another issue is that stores are pretty much deprecated. I love
| stores because of their simplicity all the way through; you could
| click "go to source definition" on a `writable()` call in your
| text editor and read through the simple implementation in the
| Svelte source code. [1] You could confidently create custom
| stores that integrated seamlessly into Svelte's reactivity system
| all using plain JS; you just had to match the expected API.
|
| With hooks, that transparency is greatly reduced and all of the
| magic happens invisibly under the hood in the compiler. In
| `.svelte` files this was totally fine since it was operating
| within the Svelte model. But now, any random assignment to
| `self.foo` in a class might actually be to a reactive `$state`
| rune which could cause UI components to re-render elsewhere.
|
| Besides that, there are bugs when using both stores and Runes
| (some of which I've reported on Github [2]). Stores and Runes
| have slightly different reactivity models which aren't quite
| compatible. The response was basically a wontfix, so the
| expectation is that if you upgrade you go all the way.
|
| ----
|
| I will say that I'm still a fan of Svelte and will probably keep
| using it as my favored UI framework despite my feelings about
| Svelte 5. And from other discussions I've seen on places like the
| Svelte subreddit, it seems that there are big parts of the
| community which are very happy about these changes.
|
| Maybe what some people are saying is true and that this added
| complexity is needed as a framework like Svelte matures in order
| for it to find adoption with larger teams and organizations.
|
| [1]
| https://github.com/sveltejs/svelte/blob/98734433376e99909fb6...
|
| [2] https://github.com/sveltejs/svelte/issues/11626
| kristiandupont wrote:
| I wish that the Crank library (https://crank.js.org/) would get
| more attention. It takes everything in the exact opposite
| direction, which in my opinion is much more promising. But alas,
| it just doesn't seem to be catching on so I don't see an
| ecosystem ever really evolving there.
| herpdyderp wrote:
| This looks interesting but a headline of "Just JavaScript" fell
| flat when all but one example are code that won't even run in
| any browser (JSX) and the example that will is only "roughly
| the same thing".
| skrebbel wrote:
| Mostly offtopic, but I just want to drive-by namedrop Legend
| State, which provides a deep reactivity state system similar to
| the one in SolidJS or Svelte 5, but with substantially fewer
| gotchas because its design makes it abundantly clear when you're
| working with a proxy (which tracks dependencies) and when you're
| working with plain data.
|
| The key trick is that its "observables" (similar to Solid Stores
| or Svelte runes) aren't mixed with the actual data, and instead
| are sort of pointers _to_ the data. This makes it very clear when
| you 're passing reactive observables around, and when you just
| have vanilla data. There's never confusion about whether a
| particular property access is properly tracked or not. There's
| never that feeling that it "is not JavaScript".
|
| It works well with React but is fundamentally framework-
| independent. We moved to it after trying SolidJS (which Svelte 5
| is strongly influenced by) and we haven't looked back. IMO it
| deserves a lot more mindshare than it currently has.
|
| https://legendapp.com/open-source/state/v3/
| jzig wrote:
| They've turned React into Angular 19 with signals. Heh.
| jonstaab wrote:
| This seems promising. I agree observables are probably the
| right way forward, although I haven't used them much beyond
| svelte stores. Observables via hooks might be a good way to
| eliminate the bad parts of hooks too.
| brap wrote:
| Svelte never sat right with me, from the very beginning, but I
| could never exactly put my finger on it and articulate why.
|
| "Svelte is not JavaScript" is spot on.
| spankalee wrote:
| If you're looking for a library to build components and apps with
| that does let you use plain JavaScript - to the degree that you
| can write working components in your devtools console - check out
| Lit: https://lit.dev/
|
| For deep reactivity, we have add-on packages for signals, and
| we're aiming towards integration with the upcoming Signals TC39
| proposal: https://lit.dev/blog/2024-10-08-signals/
|
| Lit's used by pretty major apps like Photoshop, Reddit, Home
| Assistant, and The Internet Archive.
| replete wrote:
| What are the best resources for approaching complex enterprise
| apps with Lit?
| teekoiv wrote:
| Runes annoy me because they ruined the use of Svelte components
| as rendered widgets outside a Svelte site. I like using them in
| rich-text as rendered views but when Svelte 5 came out, the old
| way of simply setting the component props directly was thrown out
| and you implicitly are now expected to use runes for the props
| you pass to the components.
|
| Which means, that anywhere I render those components I have to
| suffix the file as .svelte.ts Or switch to svelte/store but it's
| quite dumb to wrap everything as a Writable<T>
|
| I still like Svelte regardless, but I just thought "why" as over-
| abstraction wasn't the original tenets of Svelte
| jonstaab wrote:
| Yeah, I opted not to talk about that in my post, but runes do
| tend to infect all of your code if you use them as intended.
| ericyd wrote:
| Feels weird to say Svelte is not JavaScript because of an
| unexpected behavior when passing a closure as a callback. I think
| a better title would be "I dislike Svelte 5 because it surprised
| me."
| favorited wrote:
| As someone who transitioned from JS to native apps before Node
| hit 1.0, unexpected behavior with closure callbacks make it
| sound _more_ like JavaScript to me.
| ForHackernews wrote:
| Svelte compiles to Javascript. I don't think it's ever claimed to
| _be_ Javascript. It 's less weird and magical than React, IMHO.
| k__ wrote:
| For me it was the other way around.
|
| Was a huge React enthusiast, even wrote a book on it.
|
| But with version 5, Svelte got really interesting. Runes really
| feel like a breath of fresh air.
| machiaweliczny wrote:
| Have you used MobX? It was there 10 years ago and still
| working. Svelte runes are basically the same with some perf
| wins but require compilation
| rezmason wrote:
| I thought this was especially well said:
|
| > Don't choose tools that alienate you from your work. Choose
| tools that leverage the wisdom you've already accumulated, and
| which help you to cultivate a deeper understanding of the
| discipline.
| daft_pink wrote:
| My only complaint about Svelte 5 is that its so new that the LLMs
| aren't good at it yet.
| jcuenod wrote:
| The problem is that Svelte 5 is not Javascript in the _worst_
| way. It doesn 't solve the problems of js, it provides leaky
| abstractions around some frontend issues. I think Solid is a
| better direction than Svelte because Solid doesn't depend on a
| new language. But the reason there's an instinct to create
| something that's not quite js is that js is not ideal. Elm is the
| precursor to svelte. But I think we can do better...[0]
|
| [0] https://jcuenod.github.io/bibletech/2025/02/16/beyond-
| typesc...
| jgilias wrote:
| I for one am just excited that a Nostr post has organically made
| it to HN front page!
| pier25 wrote:
| I love Svelte and runes but because of its compiled nature and
| custom language it does require a serious dev tools effort.
| You're also basically coupled to VSCode. Unfortunately the Svelte
| team doesn't have the resources to support other editors. And now
| with TS these dev tools need to be more sophisticated than ever.
|
| As much as I love Svelte this worries me. Vercel is pretty
| invested into React and Next and who knows how long they'll be
| funding the project.
| jmull wrote:
| I liked svelte quite a bit, but I wouldn't recommend it for most
| projects.
|
| Whatever version of svelte you use will be dead and abandoned
| soon, so if you have any hope for a long-lived project, you're
| jumping on the update treadmill, where the value proposition is
| 100% backwards...
|
| If your project fails, then great, no problem!
|
| If it succeeds you'll have to spend a proportion of your time
| upgrading.
|
| Worst case scenario is your project succeeds and grows. The time
| you spend upgrading grows in proportion with how much you use it.
| And in complex projects you tend to get these spikes of
| exponential upgrade work, which outright blocks your progress.
|
| No thanks.
|
| (Of course, this isn't restricted to svelte. React and all the
| crap you have to use with it are even worse.)
___________________________________________________________________
(page generated 2025-02-18 23:01 UTC)