[HN Gopher] Svelte is surprisingly easy to learn
___________________________________________________________________
Svelte is surprisingly easy to learn
Author : thunderbong
Score : 152 points
Date : 2023-09-04 14:47 UTC (8 hours ago)
(HTM) web link (kaviisuri.com)
(TXT) w3m dump (kaviisuri.com)
| markyc wrote:
| Remix with react (just for the Jsx) seems like the sweet spot for
| me. 90% html and Js apis, with minimal magic to keep things
| component based and dynamic. Feels like the good ol days of PHP
| and ajax forms
| fullstackchris wrote:
| i'd argue to an extent that _any_ programming language is not
| simple
| [deleted]
| pil0u wrote:
| As a hobbyist web dev using Rails, I am watching the JavaScript
| ecosystem from some distance - the mere JS experience I have is
| very vanilla or through StimulusJS/Hotwire.
|
| For the 3 years I have played with the web, I have been seduced
| to dive into a framework that is "fullstack" JavaScript to learn
| the language that is seemingly everywhere and "here to stay".
|
| I have seen dozens of articles like this one for all the major
| frameworks around - some not really maintained over time. I
| cannot find, in the JS ecosystem, the stability I know in the
| Rails ecosystem. I fall in a state where I search for objective
| arguments, hesitate, and end up not taking any decision.
|
| For those who know better, what is your current bet for a
| JavaScript (or TypeScript for that matter) framework that will
| last* the next 15 years? Is Svelte on the list?
|
| * maintained, with a rich and alive ecosystem
| HatchedLake721 wrote:
| In the next 15 years?
|
| Ember.js and Angular.
|
| And I wouldn't call React a framework, it's a view library.
|
| Let me explain.
|
| While there was a new React router coming out every week in
| early 2010s, some teams picked a batteries included framework
| such as Ember.js and focused on productivity and shipping
| rather than bikeshedding which router to use or what folder
| structure to have.
|
| And those teams have been upgrading their apps for over a
| decade since the early Ember.js versions (some even upgraded
| from before Ember was forked from Apple's SproutCore).
|
| Intercom swears by it https://www.intercom.com/blog/evolution-
| of-ember-at-intercom...
|
| So do some Ember apps at Apple, LinkedIn, Microsoft and Heroku
| that have been going through this journey for years.
|
| And they will carry on.
|
| There's a new and faster rendering library out on the block?
|
| That's easy. We'll just replace the rendering engine.
|
| That's what Ember.js did in mid-late 2010s with Glimmer.js,
| where they dropped-in a complete replacement of Ember.js
| rendering engine with full backwards compatibility which was
| beating React in some benchmarks.
|
| https://auth0.com/blog/face-off-virtual-dom-vs-incremental-d...
|
| So frameworks such as Ember.js, Ruby on Rails and others will
| still be there in 15 years, alive, with people interested in
| productivity rather than tinkering keeping them fresh and
| alive.
|
| View libraries? Yes, but in the same sense jQuery is today.
| It's there, it's being patched, thousands of sites use it, but
| there'll be better ways to do it.
| evilduck wrote:
| There's been more effort in the Ember community poured into
| telling us it's not dead yet than into doing anything
| relevant outside the Ember community in the last decade.
|
| Might as well have said Dojo and Knockout, it would have
| meant the same thing.
| alternatex wrote:
| As someone who loved Knockout when the only alternative was
| jQuery, I can't wait for it to die. Same for jQuery and any
| other library that we've found better alternatives for.
|
| I'm surprised by the number of people swearing by React as
| if it's some holy grail of UI technology that will never
| die. Popularity is meaningful, but only for a while.
| evilduck wrote:
| I don't think React is the final way to do web
| development but there are tangible benefits to a large
| community of users that aging competitors want to pretend
| don't exist.
|
| Just like there used to be a jQuery plugin for anything
| you wanted, there's probably a similar React solution for
| anything you want. Outside of React or Vue you're often
| reinventing a wheel. It's doable but not productive.
| wetpaws wrote:
| [dead]
| Tainnor wrote:
| Rails is a niche that went through a hype phase 10-15 years
| ago. It's not going to die any time soon, but it's also one of
| these languages that hasn't as many job opportunities
| (especially outside of major tech hubs) as other stacks.
|
| The amount of frontend JS developers is many times larger than
| the amount of Ruby on Rails developers so the fact that there
| is less "stability" is hardly surprising.
| CharlesW wrote:
| > _For those who know better, what is your current bet for a
| JavaScript (or TypeScript for that matter) framework that will
| last_ the next 15 years? Is Svelte on the list?*
|
| I don't know "better", but FWIW I just went through this same
| exercise and landed on TypeScript and Vue, with Vite as my
| build system. Vue is 9 years old (vs. React's 10), and I'm
| reasonably sure that I'm not going to need to learn a new
| front-end framework before 2040 unless I want to.
|
| I think the jury's still out on whether Svelte will be around
| that long, although I'm rooting for it. IMHO, the key will be
| the ecosystem that grows (or doesn't) around it.
| thunky wrote:
| > I'm reasonably sure that I'm not going to need to learn a
| new front-end framework before 2040 unless I want to
|
| Maybe not, but there is a good chance that Vue in 2040 is
| nothing like Vue today.
| 9dev wrote:
| Cars 20 years ago weren't what they are today. Browsers
| weren't, politics weren't, heck, light bulbs weren't.
|
| Things change all the time. It's okay.
| thunky wrote:
| Agree, but my point was that choosing Vue today because
| it will still be around in 10 years doesn't mean much if
| it's no longer recognizable and you had to rewrite your
| code three times to get there.
| bufferoverflow wrote:
| TS + Vue + Vite is just so good.
|
| I switched to it from React + Webpack, and it's so much
| better.
| kamikaz1k wrote:
| Comparing to Rails/Ruby is not really fair because Ruby's
| popularity exploded due to Rails, especially in web context. As
| such both the primitive and the framework are closely tied (in
| web dev context).
|
| Whereas JavaScript is a primitive, and frameworks have gone and
| come based on the needs of the time.
|
| Depending on your web stack, you probably have a very different
| view of JavaScript. And actually I'd rather view it as that;
| JavaScript in the context of a web stack is just an extension
| of the serving framework.
|
| If you say the backend is just a simple REST API, then you fall
| into the SSR or not camp. If you're not in SSR, I guess it
| doesn't matter. But these days, things aren't trending towards
| SSR.
|
| So your question actually boils down to, which set of
| JavaScript libraries will be maintained for a given stack. So
| the answer is: the most popular JS framework for any
| established full stack web framework.
|
| If not SSR though, I'd say react. Because it's cheap and
| ubiquitous.
| rk06 wrote:
| In 15yrs, None of the current js frameworks will exist as they
| do now.
|
| If I had to make a project, I would bet on vue because it is
| community funded
| bufferoverflow wrote:
| I am pretty sure in 15 years React and Vue and Svelte will
| still be used frequently. Unless everything gets replaced by
| AI.
|
| We're approaching the diminishing returns when it comes to
| front end frameworks. All the big ones are decent. I don't
| feel a need to have a better framework.
|
| My bottleneck is how fast I can write logic and CSS. With
| complex components a lot of time is spent on managing state
| correctly, implementing all the minute details that the
| designers came up with.
| fullstackchris wrote:
| > everything gets replaced by AI
|
| oh god, what would that mean for the web? an unreadable
| mangle of JS, HTML, and CSS, even when it's in source code
| format? count me out!
| bobthepanda wrote:
| I mean, you don't have to wait for AIs to make that
| garbage.
|
| See: creative software like Adobe CC that technically
| saves to common formats
| JoeyJoJoJr wrote:
| I think we are reaching diminishing returns in the current
| paradigm that was sparked by React, but the iterative
| nature of the web means that a new paradigm is bound to
| appear. I think there are a number ways this can go.
|
| - Some older language or tech is upgraded and crosses over
| via WASM
|
| - Immediate mode GUIs rendered with Canvas
|
| - Heavier reliance on the base web standards without as
| much build processes. Either SSR like HTMX or an event
| driven rehash of MVC for SPAs.
| earthboundkid wrote:
| Rails itself is only 19 years old. 15 years is too long to talk
| about what will or won't exist with anything like a concrete
| prediction. At best you can say that legacy systems will still
| be around. If you're a hobbyist and you tinker with your
| personal site or app once every couple of years and you want it
| to last indefinitely, just make it vanilla JS. For everyone
| else, it's not a big deal to do a rewrite every five years as
| part of the normal maintenance cycle.
| berkes wrote:
| > not a big deal to do a rewrite every five years as part of
| the normal maintenance cycle.
|
| I see that mind often and it makes me very sad. 40+ years of
| computer science, bookshelves, many now must-read classics,
| written on software maintenance, and this is what we end up
| with: just throw it out.
|
| I despise this mindset in other industries (electronics,
| phones, toys, furniture) where, instead of designing stuff to
| both last, and be repairable, we just buy a new couch, phone,
| or blender once anything breaks. And I dislike it even more
| in software.
|
| I honestly cannot, an will not accept the common statement by
| random web agency that rebuilding this bakeries WordPress
| site from scratch, is cheaper than salvaging and repairing
| it. Nor that rebuilding some Rails backend in Go, or Nest.js
| the easiest. I mean: I know it often is the cheapest or
| easiest. But only because those in charge of the previous
| version never bothered about maintainability.
| earthboundkid wrote:
| Read Programming as if People Mattered from 1991. Even back
| then frontend was a mess of spaghetti code that needed to
| be periodically tossed out. That's just how frontend works.
| UI is ephemeral. The backend can be pure, crystal logic
| that lasts for decades or maybe centuries. The frontend is
| a rat's nest of conditions that will get junked as soon as
| fashions change.
|
| It's the difference between manufacturing denim and selling
| jeans. The denim business is forever. The jeans business is
| constantly changing.
| thunky wrote:
| > I see that mind often and it makes me very sad
|
| It's not always a bad thing. It gives you the chance to do
| it better.
|
| When is the last time you looked at your work from 10 years
| ago and thought you'd do it exactly the same way today?
|
| And the cost to destroy and rebuild software is so much
| smaller than other industries that produce things that
| exist in the physical world. Why not take advantage of
| that?
|
| Also: job creation.
| meiraleal wrote:
| I'm using Lit for the past 2 months after Svelte/SvelteKit for
| another 2 and although I liked sveltekit a lot coming from
| React, Lit tooling or lack of it is the greatest advantage in
| comparison.
|
| Lit is a great tool to create your own framework while keeping
| it integrated with other lit-based frameworks and any other
| framework as it is based on custom Elements so it is an
| excellent way to write components that can be used together
| with React, vue, svelte. Another great advantage is that Lit
| already have top class UI libraries like shoelace, ui5, Lion
| and many more.
| Tade0 wrote:
| Svelte itself might not survive, but the idea of adding
| reactivity at compile time will remain, because it's just too
| attractive to abandon it.
|
| For one, in Svelte you're getting a legible stack trace -
| something that JS frameworks stopped delivering over a decade
| ago.
|
| To finally know which change triggered the rendering that
| errored out just by looking at the stack trace is a game
| changer.
| dorianmariefr wrote:
| Stack trace from React is pretty clear
| [deleted]
| MrJohz wrote:
| I think React is always going to be a big hitter. Someone else
| mentioned jQuery - I don't think that's the perfect comparison,
| because part of what made jQuery kind of obsolete is that the
| browser APIs improved to the point where it just wasn't needed
| any more - that's just not happening with React because
| browsers aren't looking to ship a whole framework. But the long
| tail of jQuery projects is a big thing, and I think that's
| going to be true of React as well, at some point in the future.
|
| That said, I think it's becoming increasingly hard to see what
| value React specifically (as opposed to any other framework) is
| bringing to new projects. It's slow and heavy, but without the
| pre-made structure that you get from, say, Angular. It has a
| great ecosystem, but it's typically harder to integrate with
| non-React projects libraries.
|
| I know Vercel/NextJS are pushing really hard to make the big
| advantage of React be server-side rendering, islands, suspense,
| etc - the idea that you can build your entire app in React, but
| shipping only the code needed to change the few pieces that
| actually get updated in the UI. There's some merit to this in
| that all your templating/rendering lives in one place (and you
| get to use frontend templating tools, which at this point are
| pretty good), but I think React is the worst framework to take
| advantage of this idea. Partly that's because it's just very
| big and slow, and shipping smaller bundles is going to have
| diminishing returns when React is already half your bundle
| size, but mainly that's because React doesn't really have the
| architecture for these sorts of situations. There is a big
| assumption in React that it controls the world, which makes
| things like nested island very hard, and means that you need to
| ship lots of rendering code even if the only thing changing on
| screen is a CSS class.
|
| I'm talking a lot about why React isn't a good candidate for
| the future, which isn't really answering your question, but
| that's because it truly is the elephant in the room in these
| discussions. No-one ever got fired for choosing React, and
| probably won't for the foreseeable future, even if it isn't
| perfect.
|
| My answer, though, is Vue. Personally, it doesn't do a lot for
| me, I just like JSX too much and find the excessive Proxy stuff
| too complicated. But they've got one big advantage over React
| right now, and that's that they have the right architecture:
| signals. Signals, when done right, are a great way of skipping
| a lot of work and VDOM-based updates by directly updating the
| changes attributes. For example, if you have a class name that
| depends on some data, and that data changes, you don't rerender
| the entire component, you just update the class name directly.
|
| Currently Vue doesn't do that, but they're working on a new
| renderer that takes a lot of the idea from SolidJS, and that
| will drastically improve performance and decrease bundle size
| (they've released performance benchmarks that have Vue beating
| Svelte, although obviously take that with a grain of salt!).
| This is great for client-side rendering, but the best big
| improvement would obviously be to do less rendering overall.
| This comes back to Vercel and their big push for islands. One
| of the things you can do with Signals is, rather than do the
| whole SSR/hydration dance that Vercel are doing, is to ship
| only the signals (i.e. the application state and instructions
| needed to update the page). At that point, you don't even need
| a client-side renderer - everything just gets updated in the
| DOM directly. This is the direction that projects like QwikJS
| are going in.
|
| Of the three big frameworks, the only one that's really in a
| state to take advantage of these advanced is Vue. The React
| team aren't interested in exploring signals right now, and
| while the Angular team are moving in the direction, there's a
| lot of legacy stuff there that's going to make large changes
| hard.
|
| The other alternatives are smaller frameworks like SolidJS,
| Svelte, etc, but I think they're just too small to really get a
| huge amount of market share. They make great testbeds for new
| ideas, but are too nice overall.
|
| That said, if you're interested in the craft of frontend
| development, give SolidJS a go. It's pretty much pure signals,
| but with a React-like interface. You can explore the compiled
| output and get an idea of what the compiler is actually doing,
| and the whole thing is amazingly lightweight and fast - only
| marginal overheads compared to vanilla code, but with a
| declarative structure.
| codeptualize wrote:
| The problem is the part where you think about the framework
| instead of what you are building!
|
| For 15 years: My bet is on React, see the amount of apps
| currently build on React, see multiple large companies backing
| it, see the #huge ecosystem, all the jobs. Even if it goes out
| of fashion we'll see another 15 years of it.
|
| Other mentioning React will be like jQuery supports my point:
| Out of fashion, but well maintained and still used a lot. (Side
| note: Rails is also like that imo).
|
| Svelte does an interesting thing with the compiler, but
| otherwise not that revolutionary, and in some parts
| questionable. In terms of longevity they have a ways to go.
|
| But 15 year longevity seems like a strange criteria to me. Is
| the app you are building really that important that it will
| need to survive 15 years, but not important enough to update it
| to newer tech?
|
| I think it's also good to realize that all the options are
| largely similar and only differ on details. It's a different
| flavor of the same thing. Learn one and you will be able to
| pick up the others very easily.
| jfengel wrote:
| _Is the app you are building really that important that it
| will need to survive 15 years, but not important enough to
| update it to newer tech?_
|
| I find that's not uncommon in large corporations. The app
| does what it does, and nobody particularly wants to rewrite
| it. It gradually both petrifies and rots, and yet a ton of
| workflows go through it.
|
| For that scenario you want it in a framework that lasts, even
| if it's not the best one. Some poor schmuck has to keep it
| limping along, and then pass it off to some other poor
| schmuck.
|
| Eventually the whole thing comes crashing down and you have
| to deal with Conway's Law -- the whole corporate structure
| has been built to reflect the scope of that elderly piece of
| software and everything cobbled to deal with it. You get to
| re-do it in the latest-and-greatest -- but hopefully one that
| will last another 15 years.
| iamsaitam wrote:
| I'd say React (NextJS for fullstack) is that framework, it's
| already 10 years old.
| continuational wrote:
| React Hooks might as well be another framework than React
| Components, even if it's backwards compatible. If anything,
| it's proven unstable.
|
| My advice is - if you want something that will be stable for
| 15 years, look for something that has already been stable for
| 15 years.
| fullstackchris wrote:
| > proven unstable
|
| care to share a link, blog post, or study? i've built at
| this point dozens of apps on react, no "instabilities" to
| call home about
| continuational wrote:
| I believe you're thinking unstable as in "it breaks all
| the time". That's not it; it's that anything written
| before React Hooks were introduced is now squarely in the
| category of legacy code
| (https://react.dev/reference/react/legacy).
| qudat wrote:
| It's still typescript + react. You won't be able to avoid it
| for a decade if you are in the FE ecosystem.
| PufPufPuf wrote:
| Lindy effect (https://en.m.wikipedia.org/wiki/Lindy_effect)
| says that the best predictor for software longevity is how long
| has it been relevant already. So, React seems like what you
| want. It's considered "old" technology by the hype people, but
| I don't think you care since you said you're using Rails.
| hliyan wrote:
| Highly unpopular opinion: by 2030, React will probably go the
| way of jQuery (i.e. a highly popular library that was once
| considered almost an "industry standard", but later ended up in
| a graveyard of projects, tutorials and articles).
|
| Difficult to say what the replacement will be, but I suspect it
| will be some form of plain JS + MVVM architecture, with a VM
| (view model) with two-way bindings, possibly natively part of
| the DOM, or even the DOM itself being optimised and async-ed to
| a point where virtual DOM diffing and similar approaches are
| obsolete, and an M (model) basically providing a client-side
| interface for the server API with some level of local caching,
| and providing an event listener interface for the VM to update
| itself. You may recognise some of these features from much
| older libraries, but I think a lot of them will be available
| natively in browsers (hopefully standardised, or in a darker
| timeline, fragmented between major browser vendors).
|
| Another possibility is HTMX-like partial updates getting more
| native browser support, essentially blurring the line between
| multi-page applications and SPAs.
| codeptualize wrote:
| The last release of jQuery was last week. It's no longer
| popular, but still maintained and used.
|
| Even if this happens to React, it means it will still be
| maintained and stable for at least another 15 year.
|
| I also think React will evolve and adapt (see RSC which is
| kinda what you describe). The beauty of React in this aspect
| is that the scope is quite narrow so it can evolve, as it has
| done in the past.
| vlovich123 wrote:
| COBOL had a release this year. Just because something is
| maintained for legacy applications, tells us nothing about
| is health/popularity for greenfield code.
| threatofrain wrote:
| 2030 is an extremely long time horizon in tech years, so who
| knows what will happen by then.
|
| By 2030 I think a more interesting possibility is WASM
| everywhere. Now all language ecosystems ask whether they want
| to provide some frameworks or DSL for their users to deploy
| to web.
| satvikpendem wrote:
| Here's a good article about WASM based web apps by the
| author of the HTML5 spec:
| https://news.ycombinator.com/item?id=34612696
|
| Basically he says that we should use WASM for stuff like
| Figma (which already does use it) or other types of web
| _apps_ while keeping the DOM for content based web _sites_.
| [deleted]
| franciscop wrote:
| Very clickbaity title, this is definitely not "just Javascript
| you already know": <script> import
| counts from './store.ts'; import {onMount} from
| 'svelte'; </script> <button on:click={() =>
| $counts.a += 1}> Increment A ({$counts.a})
| </button>
|
| In that tiny snippet there's so many non-js things, like "where
| did that onMount go?", "why does $counts come from? is it from
| 'count'?", "how do events work?", "does the onclick update the
| value later on?", "can I do $counts.a++ instead? once? twice?"
| etc.
| eyelidlessness wrote:
| That's not even all.
|
| - Why are these ESM imports allowed in a non-module script?
|
| - Even if $counts somehow references counts, how is either in
| scope in any part of button?
| tail_exchange wrote:
| Posts like these tend to disappoint me. Seems like the author is
| really excited about it and wants me to have some kind of
| revelation about how simple Svelte is, but the first example with
| the "$:" raised so many questions... What is that $? It's a
| label? How does it know that the variable changed value? Can I
| have more than one $ if I import another file that uses it?
|
| It also gave me a bunch of tiny snippets as examples, but that's
| never representative of a real codebase. How do you reuse these
| components? How do you deal with component lifecycle?
|
| It peaks my interest, but kills it with a bunch of magic and
| unanswered questions.
| porridgeraisin wrote:
| Recently I've really liked Vue's composition API. The whole
| business of refs, emits being the only thing you need is really
| nice. Not too much to learn. JSX is there too - the old Vue API
| was simply a non starter for me.
| [deleted]
| daft_pink wrote:
| Honestly, is javascript actually simple? I find it to be a really
| wacky language that I now understand but would never say it has
| simplicity.
| pavel_lishin wrote:
| React is "simple", too, in introductory tutorials where you build
| a todo-list app. Does Svelte _stay_ simple as your constraints
| and needs become complex?
| internetter wrote:
| In my anecdotal experience -- no. We started with Svelte and
| quickly migrated to solid (which has it's own handful of
| headaches but is much more manageable). Svelte was originally
| designed for little pieces of interactive content (in the
| nytimes), and it scaled like that for us back in 2021
| SkyMarshal wrote:
| Interesting, Svelte and Solid seem to be the only two new
| compiler-based js frameworks. Everything else is virtual-DOM
| based.
|
| Solid is newer than Svelte with less of an ecosystem, so it's
| interesting to hear that you found it more manageable. What
| made it more manageable?
| earthboundkid wrote:
| Vue has a compiler and a VDOM.
| internetter wrote:
| So I guess it's worth first discussing ecosystem. Ecosystem
| is something I _understand_ that people want, but we 've
| generally avoided. Especially in react, there's a large
| worry about quality. Building something quickly that's
| taylor made for our business needs is much easier than
| parsing documentation, reading source code for QA, and then
| inevitably hitting an edge case. There are a couple
| instances where we _did_ find ourselves missing an
| ecosystem (the first example that comes to mind is WYSIWYG
| editors), but for the most part we build it ourselves, and
| that 's been fine. From what I recall of the Svelte
| ecosystem, it had a much more monolithic "this is how you
| do it" with the packages. By contrast, solid has a much
| larger focus on primitives -- composing something you need
| from a set of modular tools. This also extends to our
| grievances with Svelte itself. I wish I could recall exact
| examples, but we transitioned 3 years ago and unfortunately
| I never recorded the exact issues. I _do_ remember it
| distilled to a very similar problem. Things go great with
| the magic, until you hit some sort of problem that the
| framework authors did not anticipate, and you basically
| learn "you cannot do this". By contrast, solid gives you
| tons [0] of primitives. Almost every issue relating to
| state can be addressed with these primitives, and if not,
| you can easily compose your own (in fact, very few of the
| provided primitives are entangled with the core library.
| They themselves are built upon lower and lower level
| primitives).
|
| Also, with Svelte there were a considerable amount of
| design decisions I disagreed with. For instance, the
| context API uses strings instead of imports as identifiers,
| which breaks intelisense. I guess they want it to feel
| monolithic and integrated, but it's just frustrating. How
| do I extend this context system in Svelte?
|
| Everything really comes down to this fundamental decision
| between a "framework" and a "toolbox". Even the file
| structure reflects this. Solid, in some way, encourages
| small components -- you can have multiple functions in a
| file, vs svelte where you can only have one. Each component
| in Svelte has significantly higher size overhead than
| solid, I suppose because you aren't supposed to have as
| many. In my opinion, the toolbox philosophy is much better
| equipped to handle the complexities of a large application.
|
| Sorry for such a long ramble without concrete examples. As
| I said, I really wish I wrote this out 3 years ago when we
| made the switch.
|
| As for Solid vs. React, there's plenty of discussions of
| this already. Aside from the much better performance, the
| solid model fixes almost all the footguns relating to state
| and rendering performance that react introduces, basically
| because it's closer to vanilla JavaScript (each function
| only runs "once")
|
| [0] https://www.solidjs.com/docs/latest/api
|
| e: I've checked back on this thread and I find myself
| agreeing with other people like gushogg-blake and spuz.
| Worth checking their comments out as well.
| SkyMarshal wrote:
| That is extremely helpful, even without many specific
| examples, thanks! It's definitely something to be aware
| of at the start of a new project. If you anticipate the
| project will not get too large or complex, then Svelte is
| probably a good choice for the productivity and
| performance. But if it could grow over the years into
| something large and complex, then Solid's primitives-
| focus and toolbox approach may be better.
|
| I wonder if Svelte5 will retain the framework philosophy
| or move toward the toolbox approach.
| internetter wrote:
| > If you anticipate the project will not get too large or
| complex, then Svelte is probably a good choice for the
| productivity and performance.
|
| Yup. If I found myself trying to hack together something
| a weekend I'd be willing to use Svelte again! It's really
| quite productive at the beginning. Plenty of times when
| you just want simple reactivity without any other mental
| overhead.
| pier25 wrote:
| Could you elaborate on the pros and cons?
|
| I've been using Svelte for about 3 years now and haven't
| found any big scaling headaches.
| DoesntMatter22 wrote:
| Not OP but I'll give my 2 cents. I much prefer Solid
| because it's explicit as far as which variables will be
| manipulated. However. I ended up usually using Svelte
| because it's so much less boilerplate than anything else.
| tiborsaas wrote:
| Of course not. The closer you get to JavaScript, the bigger
| mess you are going to make.
|
| React's limitations is its greatest asset, it forces a team of
| engineers to stick to a common ground the must agree on: JSX,
| hooks, component life-cycle, etc.
| alternatex wrote:
| React is one of the few popular libraries well known for it's
| lack of opinion. Every React project is different and it's
| hard to consolidate developers on how things should be done.
| If you want common ground you'd go for Angular. React is the
| exact opposite of common ground.
| tiborsaas wrote:
| It does allow different ways of writing code and I agree
| that projects can be quite different architecture wise, but
| if I look at a component, I can be fairly certain that:
|
| - Its return value is a some kind of UI (I know about
| contexts)
|
| - Not using hooks, the variables in the JSX are side effect
| free
|
| - Using hooks will trigger a state update or you can
| prevent one
|
| - A re-rendered component re-renders the whole subtree
|
| I meant that these few assumptions are shared in a project
| by every developer touching the project and they must work
| with these in mind. Abusing these will result in a rejected
| PR.
|
| Can you still write bad react code? Absolutely, but at
| least I don't have to go back Adam and Eve to find what the
| hell is going on.
| meiraleal wrote:
| There is one thing that Svelte isn't is simple javascript. It is
| not even javascript, the files are named .svelte for a reason.
| Svelte is great but I won't be changing React for something so
| similar but without vdom. Lit.dev is where the real simplicity of
| JavaScript shines imo.
| dbrueck wrote:
| The files are named '.svelte' because each one encapsulates the
| relevant Javascript, HTML, and styles.
|
| But why do you want the vdom exactly? Like, what does it give
| you? Seems like its presence is more an implementation detail
| of a framework than something a user of the framework would
| want, no?
| alternatex wrote:
| Virtual DOM offers nothing but slowness. If I can get the same
| things without it why would I need it. It's a solution to a
| problem compilers like Solid and Svelte don't have so it's so
| odd to see someone argue for it. Like complaining a about
| missing dependency injection in a functional language.
| fullstackchris wrote:
| the alternative is a global query / state management /
| whatever against the entire DOM tree - much less performant
| and exactly WHY the virtual dom was invented
| tcfhgj wrote:
| Isn't DI a core principle in functional programming?
| anamexis wrote:
| I have used Svelte, and I don't understand this take at all. The
| post is full of Svelte-specific constructs that you need to
| learn.
| kavii_suri wrote:
| Hey, totally agree with that, the article was an exaggeration
| to grab peoples attention and pull it towards the awesome
| framework that Svelte is.
|
| I don't think there's ever going to be an abstraction that's
| both useful and has nothing to learn. The point is that the
| amount of stuff in Svelte you need to know before you start
| building real stuff is very minimal.
| jmull wrote:
| I don't think the article is a good intro to svelte or gives you
| much sense of using it. The title is positively incoherent.
|
| You'd be better off going through the main site's tutorial. And
| since you'd presumably be interested in building full web apps as
| well, take a look at the sveltekit site and docs as well.
|
| The idea that there's nothing to learn is nonsense. It's not
| large and I think it's straightforward, but there are various
| things to learn.
|
| IMO, the strength is that you write your HTML in HTML albeit with
| a simple templating extension, the reactive JS/TS is in the same
| context, and the reactivity model is simple/predictable and
| performs well (at least in my experience).
| kavii_suri wrote:
| Hey the author here, I totally agree with going through the
| official tutorial. That's what the article recommended tbh. The
| goal was to convince more people to give Svelte a try, as IMO,
| it's getting way less attention than it deserves.
|
| Anyway, thanks for the feedback, I'm quite new to blogging and
| writing in general. Will definately incorporate your
| suggestions in future work.
| sethammons wrote:
| TL;DR: It feels like React interacts the reverse of how I think,
| but Svelte feels like it promises some of the straight-
| forwardness I used to know 25 years ago.
|
| As a backend person who last touched the frontend when jQuery was
| all the rage, I spent the last two weekends starting to get
| familiar with React and then Svelte. I really, really like what
| I've seen in Svelte so far. It makes sense. I can reason about
| what components talk to which other components and how, more
| easily than in React. After 8 hours of a React tutorial (which
| had several incompatibilities from the version in which the
| tutorial was written that I had to reason through), and after
| going through the Svelte tutorial for maybe half that at
| learn.svelte.dev, I came away feeling confident I can build a
| site in Svelte and not entirely sure what that would look like in
| React. I had to start looking at other projects in React to
| understand how I should organize my secure part of my site vs my
| public parts. It is clear in Svelte, for instance, where I can
| enable server side rendering on my more marketing / landing
| focused pages and how to group pages via the directory structure
| that require authentication.
| gushogg-blake wrote:
| Having used Svelte on a large project, I found that it did scale
| reasonably well but that the usual problems did require effort
| and trade-offs. The two big ones for me were:
|
| - Managing file size and complexity in the component-per-file
| paradigm. Having all logic for a complex component in one file
| makes it big, e.g. 1,000 lines, but splitting into multiple files
| introduces a component boundary and consequent state
| passing/event handling boilerplate.
|
| - With tight coupling between a complex UI and complex domain
| objects/data structures, it becomes difficult to reason about
| data flow. There are multiple ways of binding the data to the UI
| -- props, stores, standard JS variables, and reactive statements
| -- but all come with trade-offs and none let you develop domain
| objects that are completely framework-agnostic without
| introducing repetitive boilerplate.
|
| For certain types of app I actually really like the DX of writing
| a UI-agnostic app and then layering Svelte on top of it with
| event handlers. It's repetitive -- you have to manually listen to
| events from the domain objects and update local variables with
| assignments -- but it's easy to reason about and seems to scale
| well. A good middle-ground might be making the app aware of the
| Svelte store contract, which is also very simple, but I haven't
| tried this and the store syntax comes with its own idiosyncrasies
| (you can't do $obj.store, for example, because only the $obj bit
| is interpreted as a reference to a store).
| woah wrote:
| Maybe somebody will write a pre processor to let you break a
| component into several files lol
| jeremyjh wrote:
| I really like the look of the composition API in Vue 3 though I
| have not used it yet, it gives me hope for addressing some of
| the issues you mention. I wonder does Svelte have anything
| comparable?
| gushogg-blake wrote:
| From a quick look at the "What is Composition API?" question
| in the FAQ[1], I would say:
|
| - Reactivity API - yes, with $: labels
|
| - Lifecycle hooks - yes, similar to the ones mentioned
|
| - Dependency injection - not sure what it is exactly as I'm
| not familiar with Vue, but I don't think Svelte has a concept
| like this
|
| [1]: https://vuejs.org/guide/extras/composition-api-
| faq.html#what...
| preommr wrote:
| > - Dependency injection - not sure what it is exactly as
| I'm not familiar with Vue, but I don't think Svelte has a
| concept like this
|
| It's poorly named (holdover from earlier version of vue
| when svelte didnt exist and react didn't have contexts),
| but it's basically React/Svelte context API for passing
| data to children further down the tree instead of passing
| them through props or through a separate state management
| solution (e.g. vuex/redux).
|
| There's some nuance, but roughly:
|
| - getContext = provide
|
| - setContext = inject
| spuz wrote:
| I am a big fan of Svelte - as a backend dev who is also
| responsible for writing frontend code, I saw a massive
| productivity jump when we moved our website from React to Svelte.
| But the premise of the article is just not true - you do need to
| fundamentally understand how Svelte manages the state of your
| pages. You need to understand how and when an update to the state
| in one location gets reflected elsewhere. Most of my time is
| spent trying to work out why state is or is not updating as I
| expect.
|
| Not helping this, it's not particularly well documented. For
| example, recently I had to learn about the onDestroy function
| which accepts as an argument a lambda. The docs [1] state that
| the lambda is run when the component is "unmounted", but offers
| no further information about exactly how or when this occurs.
| There is no official documentation on all the various lifecycle
| stages of a component and how or when each transition occurs. I
| find myself simply relying on a lot of trial and error or asking
| in the Discord forum.
|
| [1] https://svelte.dev/docs/svelte#ondestroy
| ilrwbwrkhv wrote:
| You should check out Imba. It is the sanest of the lot. The
| only issue is they have very few updates and the development is
| not transparent so it didn't spark much of a community.
| azeirah wrote:
| I wrote some Imba code for fun a while ago. Nothing special,
| just an HTML clock or something.
|
| It was quite nice to work with, really simple. Though I was
| just not convinced by its ecosystem, who's gonna use this?
| fullstackchris wrote:
| I kinda find this a weird comment... you say productivity is
| way better than React but then go on to say you still sometimes
| need to resort to the Discord forum to figure out what is going
| on (!)
|
| To be fair, React used to have a documentation problem as well,
| but at this point I think anything and everything under the sun
| is documented excruciatingly well.
|
| Of course people will comment I'm shilling React, but, reading
| the top comment, its kind of like trying to shill Svelte but
| immediately coming up short.
| spuz wrote:
| My comment is mainly to criticise the article and
| specifically the original title (You Don't Need to "Learn"
| Svelte), not to advocate for either Svelte or React. Yes
| there is a state model that you need to get your head around
| to work in Svelte just as there is in React and
| unfortunately, that task isn't made easy by the official
| documentation. But like I said, I still much prefer Svelte
| and would choose it over react 99 times out of 100.
| dimmke wrote:
| >But the premise of the article is just not true - you do need
| to fundamentally understand how Svelte manages the state of
| your pages.
|
| I agree with this. Like the example in the linked article about
| reactive blocks: "Svelte automatically tracks dependencies, and
| you only need to label a code block as reactive ($:). It'll run
| the code any time those dependencies change."
|
| There's a huge caveat to that, it only does that with
| primitives. Which might seem obvious if you've been a developer
| for a while, but not at all obvious if you are a new developer.
| React has always taken the approach of asking you to explicitly
| declare state and use special methods to update it (either with
| setState or useState when hooks became popular) for exactly
| this reason, whereas in Svelte sometimes you need to actually
| reassign a mutated piece of state to itself so it gets picked
| up by this system like `foo = foo`
|
| I think it's a reasonable tradeoff, because most state can be
| stored in simple primitives like strings and booleans.
|
| Regarding lifecycle methods and Svelte, it's literally based on
| the DOM. Is the component leaving the DOM for whatever reason?
| Then onDestroy will fire. The same as you can treat onMount as
| a callback that fires as soon as the component is added to the
| DOM.
|
| https://svelte.dev/repl/b946424a56d84a63a09856bc3df5803e?ver...
|
| I think part of where things get tricky is that Svelte and
| SvelteKit are so melded together, unless you're 1. only using
| Svelte and not SvelteKit or 2. Are doing something really
| advanced and complex, you probably don't need lifecycle
| methods. And even then, you probably only need onMount.
|
| A custom onDestroy can be used to manually remove something
| from memory, but it's mostly not needed. I agree though the
| docs should be better.
| sesm wrote:
| I'm curious now, what disadvantages of React could outweight
| the entanglement of reactive state management and undocumented
| lifecycle. I could understand that you could have the same
| issues with state management if you were using MobX with React,
| but undocumented component lifecycle sounds crazy.
| spuz wrote:
| I said there was a reactive state model that you have to get
| your head around in Svelte, but this is still much easier and
| simpler to do than it is in React in my experience. I'm not
| trying to pursuade anyone either way but I do want to dispell
| the notion that the mental model of Svelte is so
| straightforward that there is nothing to "learn" as the
| article claims because that will eventually lead to
| disappointment. Like I said, I think Svelte as a technology
| is great, so I'd rather people had the right expectations if
| they are going to give it a go.
| adamnemecek wrote:
| Out of the box, React provides much less than Svelte. Also
| the mental model of Svelte is one tenth of React. I was able
| to start building stuff after like 3 hours of reading Svelte
| tutorial. I have done the same with React several time and
| every time I left with "I kind of see how to do things but
| I'm unsure how to build larger things with this".
| fullstackchris wrote:
| but there are literally libraries on top of libraries to
| immediately provide in react what svelte might provide "out
| of the box". the best thing too is that these hooks are all
| open source - so you can either install a package directly,
| or pick and choose and install whatever hook you need.
|
| idk, i'm dying on the hill that react is unopinionated for
| a reason, i think it can be morphed and molded to so many
| use cases
| adamnemecek wrote:
| That's the point. I don't want libraries on libraries. I
| want an integrated approach.
|
| How are the use cases for these libraries different?
| satvikpendem wrote:
| Then why not Angular?
| adamnemecek wrote:
| Because it's terrible.
| satvikpendem wrote:
| But it's the integrated approach you're talking about,
| what is terrible about Angular?
| adamnemecek wrote:
| I just checked it's so much worse than I remember
|
| <div *ngFor="let product of products">
| <h3> {{ product.name }} </h3>
|
| </div>
| satvikpendem wrote:
| And that is why I use React instead.
| adamnemecek wrote:
| Not integrated enough for me.
| rabindranat wrote:
| [dead]
| mschild wrote:
| I agree, but what that freedom in reality often means, at
| least from what I've seen, is a patchwork of dozen
| libraries and dependencies that make large scale projects
| more complex than they need to be. That's not the fault
| of React, but it is a consequence of it.
| fullstackchris wrote:
| and when you run into something svelte simply cannot do?
| adamnemecek wrote:
| Like what?
| nightski wrote:
| It's just "JavaScript" in that it needs a translation layer and
| has a bunch of special syntax/semantics around reactive
| variables. Lol.
|
| I don't understand the cult following around Svelte. There's a
| lot of magic and complexity hiding in there.
|
| At the end of the day state management is not trivial and
| something has to handle it. React doesn't impose a specific state
| solution which is what I like about it. But while React isn't
| perfect, Svelte is not the next step imho.
| capableweb wrote:
| > I don't understand the cult following around Svelte. There's
| a lot of magic and complexity hiding in there.
|
| What's new is old again :) People started doing React because
| they got tired of mixing languages for logic, structure and
| styles, why not do it all in JS? They got tired of that, so why
| not separate them? They got tired of manually doing bindings,
| so now that's hidden behind abstractions ("Hello 2000s
| templating magic"). I wonder what they'll get tired of next.
| jbman223 wrote:
| Next is writing code entirely. Whatever has the most robust
| documentation will be the next big thing, since AI agents
| will be writing the code for the programmers.
| teraflop wrote:
| I'm concerned about the opposite possibility. All the
| effort will go into tweaking models and adjusting their
| training data until they generate acceptable output, and
| documentation for human consumption will be an
| afterthought.
| codaphiliac wrote:
| Wait till you fight a prompt to update the project in
| minor ways...
| jes5199 wrote:
| honestly if this is what makes literate programming happen,
| I think it's a win
| aleksandrm wrote:
| You're still mixing HTML and CSS with JS, which is way worse
| if you ask me.
| capableweb wrote:
| My point being: If I ask you today, I'm very likely to get
| a difference answer compared to in 2-3 years, and if I wait
| yet again 2-3 years, another answer :)
| alternatex wrote:
| Most front-end devs already use a translation layer -
| Typescript. So I don't understand the need to draw an arbitrary
| line between what can and cannot be used to make a good web
| application.
| spankalee wrote:
| There's a big difference between adding types - which is
| essentially a linter - and semantic changes to the language.
| alternatex wrote:
| Alright but the types are a wholly different language and
| cannot be parsed by JavaScript linters. Same as Svelte.
| People need to learn Typescript in order to use it, it does
| not come naturally. I don't understand how the same
| argument cannot be applied for Typescript. I do remember
| people complaining about Typescript before it became
| popular. Eventually people understood it made their
| projects more maintainable and dropped the purist arguments
| that provide no value to the product.
| gochi wrote:
| >There's a lot of magic and complexity hiding in there.
|
| That's kind of the point. It's for people who _want_ that
| magic, not for people who are likely just going to start using
| Rust instead of continuing to force such rigidity and verbosity
| into JS /TS.
| Timon3 wrote:
| >> There's a lot of magic and complexity hiding in there.
|
| > That's kind of the point.
|
| But it goes against the title of this post: "You Don't Need
| to "Learn" Svelte: Embracing the Simplicity of JavaScript".
| If the point of Svelte is the magic, why tell people they
| don't need to learn anything? The magic isn't part of
| JavaScript, so they'll have to learn it.
| gochi wrote:
| I'm not a fan of the article either, I'm specifically
| referencing the comment that doesn't understand why people
| like Svelte.
| [deleted]
| imadj wrote:
| > There's a lot of magic and complexity hiding in there
|
| I mean there's a lot of magic and complexity hidden in
| frameworks, interpreters, compilers, all the way down, not to
| mention browser engines. Or did I miss something?
| meiraleal wrote:
| when you code in svelte you name the files .svelte, it can't
| be parsed as javascript. This is more than framework magic,
| it is a new language. You can't create a preact like
| framework based on svelte.
| gabereiser wrote:
| Magic is only magic to the ignorant. Complexity is only
| complex because of humans (mostly). My issue with all of this
| is that vanilla is better than any framework. It's fast, it's
| has dependency trees, module loading, components, it works
| well with npm, and it doesn't force me to learn yet another
| flavor of the same broken concept.
|
| >did I miss something?
|
| Yes, that all of this is just code...
| imadj wrote:
| > My issue with all of this is that vanilla is better than
| any framework.
|
| Vanilla JS is an abstraction over something else which in
| turn an abstraction over another and so on...
|
| So your problem here isn't really with
| abstraction/magic/complexity in itself.
|
| You like a 5 layers cake, you think it's just perfect, a
| group copied the recipe and added a layer because they want
| to add another flavor.
|
| They didn't ruin your cake, they just have different taste.
| gabereiser wrote:
| My point is it's all cake. Everything's an abstraction on
| something.
| LapsangGuzzler wrote:
| I've been using Svelte for a about 3 years on smaller
| visualization projects and it works really well in that
| context. Being able to declaratively define your UI behavior is
| massive for tools like D3js compared to the more traditional
| imperative JS style. This unlocks the ability to abstract your
| UI in really nice ways for defining complex visualization
| behavior.
|
| The other thing that I really like about Svelte is that's a
| compiler and not a runtime framework. This keeps builds
| performant and makes it easy to import vanilla JS packages
| without needing framework-specific bindings
|
| I also find Svelte's syntax to be very intuitive and easy to
| pick up. The Svelte REPL tutorial docs are some of the best
| I've seen as far as getting up to speed with the tooling.
|
| > React doesn't impose a specific state solution which is what
| I like about it. But while React isn't perfect, Svelte is not
| the next step imho.
|
| This one area where we're going to disagree. Svelte feels more
| like Rails in that it ships with most of your basic utilities
| to build a UI, which allows the community to agree on a
| preferred solution to a given problem. I prefer this because it
| makes it easier to find solutions to problems that aren't
| dependent on some package that I don't have. Solution
| discoverability is a massive pain point in react compared to
| Rails, where there's pretty uniform agreement on how to solve
| problems.
|
| All that said, I've never worked on a large commercial Svelte
| codebase so I can't speak to the ways it which it becomes
| painful. For smaller projects, I find the DX to be far superior
| than react.
| fullstackchris wrote:
| > smaller visualization projects ... works great in that
| context
|
| therein lies the entire drama
|
| too many people probably get into svelte and realize only too
| late that its not intended / useful for larger projects
| LapsangGuzzler wrote:
| Perhaps, but given the issues I've seen with the larger
| react codebases I've worked with around performance and
| shifting best practices, I wouldn't necessarily write
| Svelte off without giving it a fair shot. It's not like
| large React apps are much fun to work on either.
|
| Ultimately, big codebases are hard to manage, regardless of
| the language or framework. I don't see a particular
| dealbreaker with Svelte compared to React in this regard.
| pier25 wrote:
| > _At the end of the day state management is not trivial and
| something has to handle it_
|
| There are many critiques that can be argued about Svelte, but
| state management is certainly not one of them.
|
| Component reactivity seems magic but it's very predictable once
| you get the hang of it. And the productivity gains are immense
| compared to React.
|
| For application reactive state (outside components) you get
| reactive primitives for free without any dependency like MobX.
| tescocles wrote:
| >I don't understand the cult following around Svelte.
|
| What I don't get is how I never (at least on HN) see any
| criticism of it. Like... never ever. And sure I've probably
| missed the odd negative post about it, but as someone who has
| never used it and whose entire knowledge of it is based on what
| I've read on here, I couldn't tell you a single supposed
| downside of using Svelte. And sure, it could just be That Good,
| but... I dunno? There's something off about that.
| thomascgalvin wrote:
| My team switched from React to Svelte a couple of years ago.
| We were working on new app, not refactoring or rewriting an
| old one, so we had the opportunity to choose whatever tooling
| we wanted.
|
| The whole team loved Svelte. It did the stuff React did,
| without a lot of the ceremony or boilerplate. It was easy for
| the junior devs to pick up, and powerful enough for the
| senior devs to what needed doing.
|
| We weren't pushing it very hard; the app was basically data
| entry and data display, and I assume that if you got deep
| enough into corner cases, it would break down like any other
| framework. But for our purposes, Svelte felt like someone had
| taken the time to understand React's issues, and fixed them.
| shynrou wrote:
| I tried using it 2 years ago on a mid complexity webapp and
| it blew up in my face as soon as things got a little more
| complex. The hidden mechanics of everything made it
| absolutely horrible to debug. Including some serverside
| rendering issues in the svelte code base at the time. The
| pain wasn't worth it in the end. I'm probably never gonna
| touch svelte again without having to. Similar experience with
| preact. It works till it doesn't.
| dminik wrote:
| If you want to see some criticism of svelte, one of the core
| maintainers recently asked about some things that could be
| improved about svelte in the next major version:
| https://twitter.com/trueadm/status/1676694161188159490
|
| That should give you some rough ideas about the things that
| the community itself thinks need improvements.
| dbrueck wrote:
| In many cases, compared to what people were using before, it
| really is that good.
|
| That's not to say it doesn't have its flaws, but when people
| talk about how it's cleaner, they can dev and debug faster,
| it takes less of a cognitive load, etc. - they are being
| genuine.
|
| Some of it is subjective probably, but I'd die if I had to go
| back to e.g. React. :)
| codelikeawolf wrote:
| I've been using Svelte exclusively for my projects (and at my
| day job) for the last 3 years. I've converted several large
| projects over from React to Svelte. I also do some part time
| work as contractor on a very large React app. I can provide
| you with some downsides for Svelte:
|
| 1. The developer experience with Svelte just isn't that
| great. Unfortunately, the Svelte team has (understandably)
| optimized for VS Code. I've been a WebStorm user for about 8
| years and have no plans of switching over to VS Code. They
| just introduced Svelte LSP integration in WebStorm, but it's
| buggy. For the longest time you didn't get autocomplete on
| props with the Svelte plugin. With the Svelte LSP, you do,
| but I'm getting a bunch of errors from the LSP saying "x is
| not a module". This may be a configuration issue (I'm using
| pnpm workspaces and TS path aliasing). But I don't really
| want to go down that rabbit hole, so I just turn the LSP
| stuff off. It _has_ gotten better, but it comes nowhere near
| the DX you get with React.
|
| 2. You _technically_ can spread props down the component tree
| using $$props and $$restProps, but the documentation
| recommends you don 't because there's a performance hit. So
| for stuff like "aria-" attributes, you either need to define
| them explicitly as props (e.g. "export let ariaLabel"), which
| is sort of gross, or you bite the bullet and use $$props or
| $$restProps.
|
| 3. Unless I'm doing something totally wrong here, using CSS
| nesting doesn't work the way I expect it to for _scoped_
| styles. I get that they are scoped, which is good. But if I
| have a button element with a child Icon component, and I want
| to change some CSS property in the Icon component 's inner
| svg element using CSS nesting, it won't work:
| <script> // Icon has an inner svg element:
| import Icon from "./Icon.svelte"; </script>
| <style> button { & svg { width:
| 1rem; height: 1rem; } }
| </style> <button><Icon name="close" /></button>
|
| The Icon's svg won't pick up that 1rem x 1rem sizing. I guess
| this makes sense because that is essentially just button >
| svg, which also doesn't work. But I end up having to fall
| back to CSS modules (or Emotion, which I stopped using
| because it needs a runtime).
|
| 4. I feel like the whole "$" reactivity gets overused, which
| leads to confusing and, in some cases, difficult to debug
| code. Maybe this is the ol' React dev in me (one way data
| flow), but 9 times out of 10, instead of binding a value to
| an input component, and listening for changes in a "$" block,
| I'm going to use the "on:input" or "on:change" event listener
| to capture that and just reassign the value variable.
| <script> let value = ""; // Instead
| of this: $: { // Do something with value.
| } // I do this: function
| handleValueChange(event) { value =
| event.currentTarget.value; // Do something with
| value. } </script> <input id="use-
| binding" bind:value /> <input id="use-event"
| {value} on:change={handleValueChange} />
|
| 5. This isn't a Svelte-specific issue, but I'm not crazy
| about single file components. I really like how components
| === functions in React, so you can put multiple components in
| the same file. In lieu of a function that returns a bunch of
| JSX based on some args, you can switch that over to a
| component with props. I think that's a really clean design
| that encourages good separation of concerns. In Svelte, you
| either end up with a bunch of extra files that need to use
| context + store or prop passing for state, or a giant
| component file.
|
| 6. Unless there have been major improvements in the testing
| space that I haven't taken advantage of recently, you can
| pretty much throw any hopes of reliable test coverage out of
| the window. At some point I just stopped testing my Svelte
| components and moved as much logic as I could outside of of
| the component so I could write unit/integration tests against
| that to get reliable branch coverage. This sort of ties into
| point #1, but I feel pretty strongly about having a
| comprehensive test suite to avoid regressions (enough to make
| this it's own bullet point). I don't put a _lot_ of emphasis
| on the coverage percentage because that way lies madness, but
| it is nice to see at a glance if I 'm missing a test case for
| a branch in the coverage report.
|
| There's probably a few more minor gripes that I can't think
| of right now, but those are the heavy hitters. That all being
| said, two of the biggest advantages Svelte offers over React:
|
| 1. No virtual DOM. This allows you to do things like change
| the style of something based solely on an HTML attribute
| using CSS, no state variable needed. Also mentioned in the
| original post: you can use plain ol' JS libraries and
| everything just works. This is a big deal for stuff like D3,
| because you don't need to add any wrappers. I've had problems
| with React + D3 in the past, and it drove me bananas.
|
| 2. Much fewer footguns. I know this is a controversial take,
| but I don't like React Hooks. They're a pretty big footgun.
| They often require you to break up a component needlessly so
| you adhere to the "Rules of Hooks". Stale closures are a
| thing. I never had a problem with class components. I never
| understood the confusion around "this", which was a common
| defense for using hooks whenever the topic of the weirdness
| of hooks came up. If writing class components was still
| acceptable, I would be more amenable to using React in my
| projects. But whenever anyone I work with at the contractor
| gig encounters a class component, they immediately want to
| refactor it to a functional component with hooks. It's never
| even up for debate, class components bad, functional
| components good. Svelte doesn't have anything analogous to a
| hook, which makes me happy.
| ravenstine wrote:
| There's complexity in there, but magic? I'm not sure what you
| mean. Metaprogramming? The reactivity layer? Otherwise, it's
| hardly more complex than competing "frameworks". The internals
| of the rendering engine are a bit cryptic but are otherwise
| very straight forward to figure out if you want to add custom
| behavior.
| eyelidlessness wrote:
| Reactive declarations using label syntax definitely qualify
| as magic. It's clever, maybe even the good kind of clever,
| but it's definitely magic. And it's definitely not "just
| JavaScript".
| meiraleal wrote:
| $ and $:{} are magic and not a great one.
| scelerat wrote:
| This weekend I went through the svelte/sveltekit tutorial, and I
| can't wait to use it in a project (several in mind in fact). I
| haven't felt this stoked about a front end library, its
| simplicity and apparent minimal painfulness, since Rails
| mehphp wrote:
| I suspect that, like rails, it is simple at first but then
| becomes quite complex as the project grows or you want to do
| something that goes against the grain of the framework.
|
| Getting excited and then jumping all in on new frameworks has
| bitten me more than once.
| DoesntMatter22 wrote:
| Rails is an order of magnitude more complicated then
| Svelte/SvelteKit. There are so many conventions you have to
| know. Svelte/Kit isn't anything like that. It doesn't even
| come with an ORM.
| scelerat wrote:
| I mean, that's true of just about every non-trivial framework
| ever
| _steady wrote:
| I hate the title of this. the quotes do so much heavy lifting. I
| was hoping for a post about removing Svelte and embracing the
| simplicity of vanilla javascript. Nothing against svelte.
| prabhu-yu wrote:
| yes, I thought the same, expecting how the author giving
| reasons. At the end, I felt fooled by the author!
| cutler wrote:
| Until Svelte or any other JS framework can compete with React
| Native React will continue to reign.
| makingstuffs wrote:
| > it's all JavaScript
|
| I don't get this narrative and Svelte isn't the only community
| guilty of pushing it.
|
| Granted, the bulk of the logic you will write using the framework
| is 'just JS' but that is true of most frameworks.
|
| Most of the code you write in ReactJS is 'just JS' as I am sure
| is true for VueJS and god knows what else.
|
| However, Svelte, as with all frameworks, has a learning curve.
|
| Even the example pretty high up on the page is not 'just JS' nor
| is the JS used very standard, who on earth labels a scope with
| `$` in vanilla JS land?
|
| If I saw that while doing code review (in a vanilla codebase) I'd
| be instantly asking what the purpose is and for a more self
| explanatory label than a dollar sign, if a label was even
| required.
|
| Further down the page you get an example with a redux comparison
| using a hook called `writeable` which exposes a `subscribe` and
| `update` method. Neither of the three are standard JS.
|
| I realise this sounds like I'm bagging on Svelte, I'm not. I'm
| actually quite intrigued and want to try it out. I just cannot
| deal with all the false claims of 'it's just JS', 'you know it
| already', 'there is no learning curve' etc. when there clearly is
| a learning curve and it clearly is not 'just JS'.
|
| The framework is doing solid work and should be celebrated for
| what it is and not what it isn't.
| kylec wrote:
| "You don't learn Svelte! It's just JavaScript!"
|
| _proceeds to show examples with a very magic $ syntax_
| vvpan wrote:
| Yeah, comparatively `useEffect` is much more "Javascript".
| internetter wrote:
| I disagree with the notion of TFA, and perhaps useEffect is
| closer, but I'd like to note that the entire
| function/component rerunning every time a dependency changes
| is as far removed from original JavaScript as a framework
| could be.
| [deleted]
| capableweb wrote:
| > proceeds to show examples with a very magic $ syntax
|
| To be fair, that's valid JS, the syntax itself is not magic but
| what happens afterwards/how Svelte picks it up.
|
| The templating though, that's some non-valid HTML/JS magic.
| Timon3 wrote:
| The syntax is vanilla, but not the semantics. Kinda makes it
| seem like malicious compliance.
| shiomiru wrote:
| I would guess they just wanted to make it work with
| existing tooling, so that e.g. standard JS syntax
| highlighters wouldn't break on code written in this
| framework.
| internetter wrote:
| But all your code is written in .svelte, a very much non-
| standard file format which undergoes compilation anyway..
| [deleted]
| uallo wrote:
| It may be unusual and has special semantics in Svelte, but it
| is JavaScript syntax after all.
|
| https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
| Zanfa wrote:
| Aren't Svelte templates written in a completely custom
| template language that doesn't even look like HTML/JS?
| dbrueck wrote:
| No, and that's one of the things that's really nice, at
| least for our team: we really want our web designers to own
| the HTML/CSS from start to finish. If you use something
| like React (i.e. where there is code that emits chunks of
| HTML elements), you sometimes either force the designer to
| learn React or the designer no longer owns the markup once
| it gets handed off to a dev. For us at least, that was a
| maintenance nightmare and hindered our ability to add new
| features or freshen up the layout.
|
| Svelte combines a component's HTML, Javascript, and styles
| into a .svelte file, so it all lives in one place, but each
| of those 3 things lives in their own section. The HTML
| looks very close to what it looks like when it was
| originally created by the designer, with a few key changes
| such as markers conditional blocks or loops and additional
| element attributes to set up data and event bindings.
| Explaining these to a web designer takes about 10 minutes
| and they are fine with it, especially if they've ever seen
| a templating language before.
|
| This setup also leads to one of two really good workflows
| between dev and design; we end up using both of them and
| choose one based on the specific scenario. In the first,
| the designer goes from visual design all the way to valid
| HTML/CSS, and then hands it off to a dev to "wire it up"
| (make it functional). In the second, a dev will rough in
| the HTML and make it functional but hideous looking, and
| then hand it off to the designer to de-uglify it. In both
| cases, the dev owns the behavior and the designer owns
| styling/layout/etc. from then on, and it's rare for there
| to be any conflicts. YMMV of course, but it's been
| fantastic for us. :)
| Zanfa wrote:
| I haven't really used Svelte, but according to their
| website, they definitely seem to have a custom language
| that I don't think I've seen before (eg. not mustache,
| liquid, handlebars, erb). From their own examples [1]:
| <ul> {#each cats as { id, name }, i} <li>
| <a target="_blank" rel="noreferrer"
| href="https://www.youtube.com/watch?v={id}"> {i
| + 1}: {name} </a> </li> {/each}
| </ul>
|
| [1] https://svelte.dev/examples/each-blocks
| dbrueck wrote:
| Hmm... apologies, but it seems like we're talking past
| each other. You thought that Svelte used a " _completely_
| custom template language that _doesn't even look like
| HTML_ ", and I replied that no, compared to something
| like React, it looks very much like ordinary HTML, with a
| few exceptions around things like loops and hooks for
| data bindings, and you replied with a chunk of HTML
| annotated the way I described. :)
|
| Point being that if you take the HTML from a web designer
| and put it into your svelte app, it looks very similar to
| the original. For example, our web designers have no
| trouble continuing to "own" the HTML even after a dev has
| gone in and made it functional - the overall structure is
| the same, all of the elements they created are still
| there (with the exception that if they had e.g. a bunch
| of dummy rows in a table, those are replaced with one
| instance of the row and wrapped in a loop construct), the
| CSS doesn't break because new elements have been added,
| etc.
|
| Our experience with React was very different: once the
| devs took it, the result was so far removed from the
| original that the web designers couldn't effectively own
| it anymore. Maybe for some companies that's not a big
| deal, but for us it's hard to express just how much
| better the Svelte way is.
| schwartzworld wrote:
| The only $ in that post is in console.log strings.
| jjnoakes wrote:
| That post describes "something followed by a colon is a
| label in certain contexts", so you need to extrapolate a
| tiny bit to realize that "$:" is a label, even if the post
| doesn't explicitly enumerate all possible labels.
| spicebox wrote:
| It's not JavaScript, it looks like JavaScript but it works
| differently
| log101 wrote:
| That simplicity, and we could say the same thing for React, makes
| it the worse candidate for developing apps. The building blocks
| are so small that it is almost impossible for juniors/mids to
| write well-written/well-structured code.
| dahwolf wrote:
| My bold prediction is that reactive frameworks will eventually be
| considered a mistake, as will its functional programming
| paradigms.
|
| It's all very computer-sciency and academic but it's simply not
| intuitive enough when used by a mediocre developer with no strong
| computer science background. They are leaky abstractions with
| lots of magic involved that get in your way. There's too many
| ways to do the same thing and it's way too easy to make a mess of
| things.
| graypegg wrote:
| I honestly find functional programming paradigms to be simpler;
| coming from someone without any sort of comp sci background.
| Data goes in, UI comes out, seems pretty reasonable to me.
|
| But I will say, I do get being weirded out by magic. Hooks in
| React specifically, where they're being memoized so you get
| persistent values out of them, just feels to hacky to me still.
| Data _and the old data from the last time this method was
| called_ goes in... and the UI is the combination of that? Class
| components were at least pretty straight forward, if a little
| verbose.
| ahipple wrote:
| > It doesn't throw a bunch of alien syntax at you, expecting you
| to decipher it like an ancient scroll
|
| Sounds promising, but the first examples contrasts a React
| `useEffect` hook (a simple function call, into which you pass a
| callback and a dependency array) with <script>
| $: { console.log("Count Changed!", count)
| } </script> <!-- html -->
|
| Which prompted in me roughly these questions:
|
| - Is this actually just JavaScript?
|
| - Oh, is `$` a label? [I googled this to confirm it is]
|
| - I thought JavaScript didn't have a `goto` statement? [I googled
| this to confirm it doesn't]
|
| - How does this ever get invoked? [I still don't know the answer
| to this question -- MDN says that labels can only be used with
| `break` and `continue` statements]
|
| - Does it get invoked only when `count` changes?
|
| - If so, how?
|
| - If not, how do I specify the dependencies?
|
| It might 'just work', but it's also not 'just JavaScript'.
| DoesntMatter22 wrote:
| > - I thought JavaScript didn't have a `goto` statement? [I
| googled this to confirm it doesn't]
|
| Goto is not a statement. It's a function. Frameworks can have
| functions...
| chrismorgan wrote:
| Goto is control flow. You can't do control flow with function
| calls in the sorts of languages we're talking about, so goto
| has to be built into the language, typically as a statement.
|
| (In _some_ of these languages you can do awful hacks like
| using hooks intended for debuggers
| <https://entrian.com/goto/> or rewriting bytecode
| <https://github.com/snoack/python-goto>, and frankly what
| Svelte does is quite similar, just implemented as a
| compilation step rather than at runtime.)
| DoesntMatter22 wrote:
| I assumed this was talking about the goto statement in
| Svelte which is navigation method. If not that's fine
| Tade0 wrote:
| > How does this ever get invoked?
|
| Initially the same way it would without the $: { ... } wrapper
| - that is true both for Svelte and vanilla JavaScript.
|
| > Does it get invoked only when `count` changes?
|
| It's invoked whenever a named variable that is mentioned in the
| block is explicitly assigned to.
|
| That's the whole "magic" here really. It's "just" JS in the
| sense that there's no additional syntax introduced that would
| make it incompatible with any of the available JS parsers, so
| by extension TS parsers as well.
| ahipple wrote:
| Sure -- I did run that code in a JS REPL and saw that it
| invoked the block immediately, but that isn't necessarily
| what I want if I'm writing reactive code. I then tried typing
| `break $` and `continue $` and got SyntaxErrors for my
| trouble, confirming my hypothesis that this couldn't be plain
| JavaScript of the sort I was familiar with.
|
| > It's invoked whenever a named variable that is mentioned in
| the block is explicitly assigned to.
|
| This makes sense in the sense that it's a contract that I can
| accept and use, but it does imply the existence of a parsing
| pipeline & runtime of unknown (to me) complexity &
| capabilities -- exactly the sort of thing a prospective user
| of the framework would need to learn about sooner or later.
| Tade0 wrote:
| Well, yeah - there's a reason why it's called a framework-
| compiler.
|
| In any case you can always just look into the unminified
| output where you'll see how your code is instrumented - it
| even includes comments detailing which variables are being
| dirty-checked.
| [deleted]
| chrismorgan wrote:
| > _Is this actually just JavaScript?_
|
| JavaScript _syntax_ , yes, but with Svelte semantics rather
| than JavaScript semantics. Everything else follows from that
| point. It gets invoked by the Svelte compiler transforming it.
| In order to work, `count` must have been defined as a property
| (`let count` or `export let count`), so that the compiler can
| run that code again when `count` changes. Reactive dependencies
| are specified purely by mention of their names. (Well, there's
| stores too, via the $ prefix on variable names.)
|
| > _It might 'just work', but it's also not 'just JavaScript'._
|
| You are completely correct.
| js2 wrote:
| > How does this ever get invoked?
|
| Via magic: _Reactive blocks are ordered via simple static
| analysis at compile time, and all the compiler looks at are the
| variables that are assigned to and used within the block
| itself, not in any functions called by them._
|
| https://svelte.dev/docs/svelte-components#script-3-$-marks-a...
| pier25 wrote:
| It's Almost Just JavaScript(tm) :)
| lemper wrote:
| what would happen if I use svelte and jquery in the same page?
| who would win? the latest entry in the script declaration?
| jraph wrote:
| There's no clash: the "$" of Svelte is not a variable
| identifier like the one for jQuery. So it's all fine.
| robbywashere_ wrote:
| Why is it that front end frameworks have so many fans, teams,
| logos, lifestyles and haircuts?
|
| Like for instance golang doesn't give much for abstraction, so it
| doesn't create rockstars out of its build system / dsl / etc ?
| azangru wrote:
| "It's just plain JavaScript," says the article, and goes on to
| describe the special syntax -- the dollar sign, the bindings, the
| templating language, something called writeable...
| thunderbong wrote:
| https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
| pwdisswordfishc wrote:
| "It's just plain JavaScript," say React advocates, and go on to
| describe the special rules -- never invoke a hook under a
| conditional, assign keys to list items, remember to list all
| dependencies next to hook callbacks...
| qudat wrote:
| Who says that? JSX alone would render that argument
| ridiculous.
| earthboundkid wrote:
| It is a traditional way of selling JSX/React.
| consoomer wrote:
| I sorta get it-- Svelte is simpler than React (at least at face
| value).
|
| What I don't get is why as an industry we are hung up on this
| need to do so much with JavaScript. In the end, Svelte is an
| incremental improvement over the thing that came before it. It
| will remain so until Svelte++ or whatever comes next.
|
| Great... but who cares? I wish we would spend more time thinking
| through new (or old) solutions to the problem we are solving.
| It's why HTMX gained some hype... but it's just the beginning.
| gochi wrote:
| Shifting the focus from JavaScript to HTML doesn't eradicate
| the problems. I enjoy HTMX, but I can't stand the current hype
| cycle regarding it being a revolutionary different take unlike
| those JS frameworks. You're just winding up doing the exact
| same thing that caused the React dilemma!
| recursivedoubts wrote:
| htmx is a different take in that it moves the state into the
| hypermedia itself:
|
| https://htmx.org/essays/hateoas/
|
| that isn't without it's own problems, but it is very
| different than most JS libs today
|
| i expect the hype will die down soon, as the reality of there
| being no silver bullet sinks in
| consoomer wrote:
| I'm not a fan of the htmx take, but it's refreshing to at
| least hear about other methods than "yet another
| react/angular/etc".
| DoesntMatter22 wrote:
| It's a great solution when you don't need a full crazy
| SPA
| consoomer wrote:
| I don't think the answer is shifting focus to HTML. The
| answer seems to be in relinquishing some control back to the
| browser, but finding a way to make the experience smoother
| and add interactivity as needed without handicapping the
| browser's control in the process.
| imadj wrote:
| > Svelte is an incremental improvement over the thing that came
| before it
|
| > who cares? I wish we would spend more time thinking through
| new (or old) solutions to the problem we are solving
|
| - What's "the problem"?
|
| - How do you classify improvement vs solution?
|
| Personally, I think people, in essence, have different problems
| that's why they create different solutions.
| consoomer wrote:
| The problem seems to stem from interactivity on the web. Of
| course, there's a spectrum here... static content pages on
| one side and games on the other.
|
| The problem as it stands today is most web pages are on the
| static/low interactivity side but use solutions from the
| other end of the spectrum.
|
| People keep reaching for the high interactivity solutions...
| why? Is it the education systems today pushing people to
| reach for the hammer they know? Is it the tooling/experience
| on the other side is so bad people avoid it?
| tayo42 wrote:
| Is the claim about simplicity true? What I want is Javascript
| helper library that's easy to jump back into. Every time I do it
| something in react, I feel like I need to go through the trouble
| of relearning it again(along with the build system) . I don't
| spend enough time writing js that whatever I learn really sticks
| after a while.
|
| Javascript on its own is just a language so I can just get going
| on a code base.
| dbrueck wrote:
| > What I want is Javascript helper library that's easy to jump
| back into
|
| YMMV, but this is precisely why I've standardized on svelte
| both for work and hobby projects. There are times when I've
| come back to project that I haven't touched in over a year and
| it was really easy to get my bearings quickly because there
| wasn't all kinds of code noise to sift through.
| fullstackchris wrote:
| if anyone is wondering why i am perma supporting react and
| combating seemingly random react haters all throughout this
| thread, i have to say that i'm exhausted from sneaky anti-react
| posts popping up approximately every 2 weeks at this point
|
| theyre always exciting and fresh at first glance, but if you dig
| into any real engineering or large scale use cases, 99% of the
| arguments fall apart. reply to this comment if you have doubts,
| i'll share my decade+ experience with counter arguments
|
| if you stop and think for just a moment, a single moment, why
| react is the most popular frontend framework...
___________________________________________________________________
(page generated 2023-09-04 23:02 UTC)