[HN Gopher] Comparing Svelte and React
___________________________________________________________________
Comparing Svelte and React
Author : feross
Score : 102 points
Date : 2021-03-24 18:47 UTC (4 hours ago)
(HTM) web link (www.jackfranklin.co.uk)
(TXT) w3m dump (www.jackfranklin.co.uk)
| IshKebab wrote:
| No mention of Typescript. You'd be mad to consider writing a
| significant app without it, and React has really great Typescript
| support - even templates are type checked properly thanks to
| JSX/TSX, and basically all tools support JSX these days.
|
| Vue doesn't come close to that, but it does look like Svelte is
| at least a bit better: https://svelte.dev/blog/svelte-and-
| typescript
|
| I'd still be wary that there are big caveats though. React was
| designed for Typescript. Javascript projects that bolt it on
| later tend to have issues.
| deckard1 wrote:
| I'm a big fan of Svelte. I've raved about their documentation
| before, but it bears repeating: this should be the gold standard.
| You can read it all in a day. There are examples to follow right
| next to the documentation.
|
| Svelte is both succinct and powerful. I find this in contrast to
| React which is often baffling and incoherent. I say this as
| someone that has used React professionally for 6 years. They've
| changed their mind at least 3 times on the API and none of it
| fits together today. Hooks and classes don't mix, lifecycle
| methods are still out there and just as confusing today as they
| were years ago. Mixing state and functions. It's just a horrible
| bag of half-baked bad ideas. And it's not even batteries
| included.
|
| Svelte has it all built-in. It has the equivalent of CSS modules.
| It has global reactive state and an incredibly simple state
| protocol that seems almost stupid if you're coming from Redux.
| You step out of your daze and realize you don't need all the
| rituals and boilerplate. The things I've seen built on top of
| that simple protocol can be incredible. It's not magic. It's just
| JavaScript.
|
| I dare say that Svelte is a joy. But I hesitate to even leave
| this comment here. Because I know the architecture astronauts are
| listening, eager to sink their claws into this simple elegant new
| thing and fill up their Github profiles with soon-to-be
| abandonware cruft which they will use to pad out article after
| Medium article which will all pour down upon Hacker News like a
| shit typhoon. Prodding us to join their cult of Svelte+RxJS. Or
| Svelte Sagas. Or their random dogma they toss into a giant bucket
| labeled "Svelte best practices." And, of course, "Ten ways you
| are doing Svelte wrong."
|
| I might be a little bit cynical.
| alfonsodev wrote:
| I think many people adopted React because Facebook was behind
| it, and using it in production, the ecosystem is huge, there is
| a react- package for everything you can image, there is also
| react-native, I don't like it, but there it is, you can reuse
| the knowledge to build native mobile apps.
|
| Now Svelte, I haven't been following, but I think the creators
| are working in what's going to be next and even better
| framework[1], to your point of things in Svelte not changing as
| much as in React, maybe it just a matter of time. Here is the
| video I had in my bookmarks for a while, I still couldn't make
| the time to watch, so I hope my comment is not too far from
| reality.
|
| [1]https://www.youtube.com/watch?v=qSfdtmcZ4d0&t=875s
| robertoandred wrote:
| How is Svelte "just JavaScript" when it uses custom templates
| and file types?
| lhorie wrote:
| I feel like this "just javascript" trope really needs to die.
| JSX is not "Just Javascript", and magically reactive `foo =
| bar` assigments are not "Just Javascript". But frankly, that
| doesn't really matter one bit anyways; it's fairly nitpicky
| to object to different control flow syntaxes, when at the end
| of the day you're just rendering data from a request to
| screen. I'm sure not many people would be willing to argue
| that throwing promises (as react suspense supposedly does) is
| a holy grail of frontend development, even though it _is_
| "just javascript".
| cstrat wrote:
| This comment makes me want to seriously give Svelte a try. I've
| browsed the docs and it looks really cool, I've always just
| held back because I feel like I am juggling enough JavaScript
| libraries in my head already and React has been great.
| Aeolun wrote:
| Have you ever worked on very large React applications without
| Redux or Saga? I just cannot imagine any other way of keeping
| my application sort of understandable.
| buzzerbetrayed wrote:
| You should look at svelte stores if you haven't already. They
| are amazing, and make redux seem so needlessly complex and
| ineloquent
| Glench wrote:
| Great concrete comparisons in this article.
|
| I no longer use React in my projects and only use Svelte and it
| feels great. I'm very happy with it.
| zem wrote:
| i'm just getting into front-end programming, and my (perhaps
| unfair) impression of react was that it was "bloated", so i
| stayed away from it. i've played a tiny bit with svelte and loved
| it though, i'm hoping to get a PWA up and running with it and
| invest a lot more heavily into learning the ecosystem if that's a
| good experience.
| Vinnl wrote:
| How's unit testing in Svelte today? That's the main worry I have
| with template-based systems (well, that and TypeScript support,
| but I hear that that's quite OK now).
| dceddia wrote:
| There's svelte-testing-library [0] which follows the same
| approach as the React flavor. It emphasizes testing the app "as
| the user would use it", which boils down to rendering
| components and inspecting the DOM. They intentionally don't
| give you visibility into the internal state of the component,
| which can be weird to get used to if you're used to doing
| things like "click the button; assert that state isClicked
| became true", but it tends to result in less brittle tests.
|
| 0: https://testing-library.com/docs/svelte-testing-
| library/intr...
| dfrsol wrote:
| It's still the glaring hole in the ecosystem.
| tubbyjr wrote:
| There needs to be a 'fun' in 'svelte' somewhere, because it
| actually makes front-end devving... dare I say, fun and
| enjoyable.
| trafnar wrote:
| Is it necessary to use a worker for the timer? If you just record
| the start time, then inconsistent setTimeout calls aren't a
| problem because each call calculates the duration from start time
| to current time. Or am I missing something?
| dceddia wrote:
| Yeah, but I think putting it in the worker was about making the
| timer able to "go off" at a specific time, while the page is
| backgrounded.
| akdor1154 wrote:
| You can work out that your 25 minute timer actually took 30
| minutes this way, but you can't fix it to make it actually take
| 25 minutes.
| k__ wrote:
| Half-OT:
|
| Svelte seems to be the pinnacle of the "bundling era" of frontend
| frameworks.
|
| What do you think comes next?
|
| XYZ-to-WASM?
|
| Back the roots with (non-)bundlers like Skypack?
|
| Anyone heard of next-gen experiments in that directions?
| hypermachine wrote:
| We are actually going the other direction. Currently I am
| experimenting with making a Blazor/Liveview (HTML over wire)
| runtime that can support many programming languages. And a GUI
| builder.
| pitaj wrote:
| I recently rewrote a small UI from Preact to Svelte and while it
| was certainly a learning experience, I have to say working with
| Svelte is fantastic.
|
| My only complaint is that the Typescript support isn't quite
| perfect yet, but it's already very functional.
| Palmik wrote:
| I use Svelte + TypeScript in my personal projects, what issues
| did you run into?
| dhucerbin wrote:
| Last I checked it was impossible to parametrize component
| type. In React you can write `<MenuSelect<User> users={...}
| />`.
| patwoz wrote:
| Please don't. It looks awful. And I think it's not
| necessary. Typescript should inherit it's type depending on
| what you are passing into "users".
| efrafa wrote:
| There are valid reason to do that. Like a component that
| takes render function and item that is passed into it
| that can be anything.
| dhucerbin wrote:
| I assume you don't like invocation? That's not the point
| here. In svelte you can't* define type variable that's
| bound to the same type in whole component. I can't
| enforce that properties `items` is `T[]` and
| `selectedItem` is `T`.
|
| * Last time I checked. I could be wrong now.
| pitaj wrote:
| Lack of support for generics and explicitly typing
| Events/Props/Slots. There is an RFC but it's still a WIP:
| https://github.com/sveltejs/rfcs/pull/38
| alfonsodev wrote:
| > writing complex React components feels more like admin; a
| constant worry that I'll miss a dependency in my useEffect call
| and end up crashing my browser session.
|
| I don't understand this worry, but I guess that happens when you
| try to do everything with hooks, the way I settled in my approach
| is to use React components just for the view without hooks, nor
| lifecycle logic, just dumb components with ocasional local state
| (useState)
|
| Then using Controller pattern, within the controller I use 4
| types of hooks, 1 navigation (useHistory), 2 read global state
| (useSelector), 3 dispatch an action (useDispatch), 4 useEffect()
| to execute on props change or component mount.
|
| That's it, that's where the realm of React and UI ends for me,
| everything else is in Ducks, Ducks are single file or folder per
| module that contains Actions, Epics (Obervables) or Sagas
| (generators), Reducers, initial state of store and Typescript
| types.
|
| I really like this separation of concerns:
|
| - dumb components: to worry just about the looks and local state.
|
| - controllers: to worry about data in, actions out, life cycle
| and navigation.
|
| - Ducks: Management of data fetching and global state.
|
| I wrote this from the top of my head, but if anyone is interested
| I'm thinking about writing a demo repository and document this
| approach, maybe others have done it already this is not new, but
| practices that I've been collecting along the way.
| [deleted]
| protonimitate wrote:
| > a constant worry that I'll miss a dependency in my useEffect
| call and end up crashing my browser session.
|
| As an fyi for anyone not aware, there are eslint/tslint plugins
| for this to help avoid it.
| buzzerbetrayed wrote:
| I'm glad you've found something that works for you, but the
| fact that each react dev has their own complicated way to build
| a web app is exactly what made me leave react.
| duxup wrote:
| Yeah I've moved to this and it is working so far. Hooks manage
| the data and etc, UI components are almost exclusively just UI
| that get some props.
|
| The UI components all have an else render if for some reason
| they're missing something / it avoids a crash (along with other
| easy to see / figure out protections)
| elyobo wrote:
| I use an HoC to wrap components in an error boundary around
| key points to avoid total crashes.
| duxup wrote:
| Yeah I really should adopt that.
| ljm wrote:
| This sounds really interesting, don't get me wrong, but it also
| shows just how insanely novel and complicated modern frontend
| dev is.
|
| Let's break down the terminology:
|
| - hooks
|
| - useEffect
|
| - useHistory
|
| - useSelector
|
| - dispatch
|
| - action
|
| - useDispatch
|
| - ducks
|
| - Actions
|
| - Epics (Observables)
|
| - Sagas (generators)
|
| - Reducers
|
| Most of those terminologies don't come from a general
| programming paradigm, but are the domain language of specific
| libraries. And I've seen more, with some places establishing
| patterns like Compound/Molecule/Atom and such. There's no
| consistent, underlying principle with them, though. If you're
| invested in Sagas then you're stuck with a bizarre threading
| model implemented with generator functions and it's pretty much
| all-or-nothing. If you're invested in Redux then there's no
| breaking out of that either, you're always going to be
| contending with shared global state.
| ZephyrBlu wrote:
| I think this is an unfair characterization.
|
| Once you understand hooks in general, any specific hook
| should be quite straightforward so they can collapse into
| one. Hooks are quite novel, but I don't find them to be
| overly complicated unless you're dealing with an already
| complex situation.
|
| Dispatch, actions and reducers can be collapsed into one
| since they rely on each other. I think this paradigm is not
| too dissimilar to message passing with something like
| RabbitMQ. Reducers are a common concept.
|
| Ducks and Actions, Epics and Sagas are just a convention.
| It's not required to use React or Redux.
|
| If you try to learn everything at once, of course you're
| going to get overwhelmed. But the same is true for almost any
| area of Software Engineering.
| nwienert wrote:
| I think it's totally fair. I discourage redux and all
| related patterns for this very reason. Well that, and I
| think local state is actually a good thing (and moving
| state out into separate files a bad thing).
|
| To me the proxy object (or proxy class) is really the best
| abstraction - much like valtio. Or a compiler like svelte.
|
| There's no reason for ducks, epics, sagas, etc etc. We have
| a programming language already, we should use it.
| ZephyrBlu wrote:
| It sounds like you're agreeing with me. You don't need
| everything up front, so listing everything is a bit
| disingenuous.
|
| It's the same explaining a fully kitted out backend
| (Routing, caching, authentication, etc) and then going
| "see, it's so complicated!". Well duh, it's a big and
| complex system.
|
| I think the issue with valtio is that there's no central
| store. As far as I can see, you'll end up having these
| proxies scattered around your codebase or you'll end up
| re-creating Redux and centralizing them.
|
| Also, I have ironically never heard of valtio.
| avodonosov wrote:
| Novel - not, in my opinion. How to do GUI is known from
| 1970-ties. Today's single page apolication frameworks slowly
| re-discover the wheel. It is funny to observe.
| BadInformatics wrote:
| > Most of those terminologies don't come from a general
| programming paradigm, but are the domain language of specific
| libraries.
|
| Not really? Most of these concepts can be linked back
| directly to earlier from CS theory and/or other languages.
| For example, Redux taking inspiration from FRP and functional
| lenses, or (most pertinent for this thread) hooks being a
| facsimile of algebraic effects in JS. As much as I like these
| concepts in general, I feel some go too far against the grain
| of what is idiomatic in the language and incur unnecessary
| friction/spooky action at a distance because of it. For
| example, here [1] are some well thought-out critiques of
| hooks and why people struggle with them from experienced JS
| framework authors.
|
| [1] https://news.ycombinator.com/item?id=22903967
| michaelpb wrote:
| Not to mention terms that do come from a general programming
| paradigm, but have a very narrow practical / framework-
| specific use within frontend dev that makes it even harder
| for beginners (e.g. "thunk" might be a general term, but I
| bet most people googling it are just trying to get some Redux
| tutorial to work, and will end up going down dozens of rabbit
| holes trying to understand the general concept)
|
| I really hate to think how many collective hours have been
| wasted on new coders who learn JavaScript as their first
| language --- especially when starting with React and Redux,
| as it's often taught --- and end up spending most of their
| time spinning their wheels on these domain-specific
| complexities, when they haven't even gotten to "while loops"
| yet. This may even be harder for beginners than
| understanding, say, one of the classic CS sorting algorithms.
| New coders don't realize though that whatever degree this
| stuff is harder, it's a sign of bad tooling or documentation,
| not that it's somehow intrinsically a harder problem in math
| / CS, since if you're new you don't know what to expect
| ljm wrote:
| React's hooks (and some JSX style things in general) are
| quite pernicious there because they essentially break JS:
| you can't use them inside an `if` or a `for` or a `while`,
| or even within another function. You're no longer writing
| Javascript, you're writing a restricted subset to avoid
| undefined behaviour.
|
| That alone is a concern, because any junior programmer
| getting an introduction through React is going to get a
| twisted understanding of the language itself.
| michaelpb wrote:
| Very true, while I appreciated React Hooks for making
| React easier for beginners by avoiding the giant can of
| worms that is OOP mechanics in JavaScript, they are also
| very magical and even more framework-specific.
|
| That said, vanilla JS can be hard like this as well,
| especially as "solved" legacy issues still regularly crop
| up in tutorials and code-bases. Many times I remember
| helping newer folks with challenges they found online
| that seemed to them like they were testing hard computer
| science problems, but were more just trivia to navigate
| some bad design decisions of JS (eg gotcha problems on
| "this" / binding, IFFE, hoisting,
| async/promises/callbacks, to name a few)
| brundolf wrote:
| In some ways JS is an excellent first language- beyond
| its broad applicability, it has an extremely "average of
| all the others" set of features and primary syntaxes. An
| experienced JS programmer will be conceptually
| comfortable with Python and Ruby, syntactically
| comfortable with Java and C, etc.
|
| But in terms of the industry-standard
| practices/ecosystem, it is a _terrible_ first language if
| you want to gain a generalized understanding. What you
| describe here is extremely true; I 've seen it in
| practice:
|
| > any junior programmer getting an introduction through
| React is going to get a twisted understanding of the
| language itself
|
| I've talked with otherwise very capable JS devs who have
| built impressive things with multiple frameworks, but
| don't have a good handle on fundamental concepts like the
| difference between the two kinds of function syntax (they
| may have only ever used one), how Promises behave outside
| of a narrow subset of situations, what NodeJS actually is
| (despite having used it), or even the difference between
| passing by reference vs value.
|
| Many of these frameworks create such a narrow lens into
| the language itself, add what are effectively (sometimes
| literally) their own DSLs on top, sprinkle in some
| magical behavior, and when all is said and done you
| hardly end up using JS at all.
|
| Obviously there's a benefit from doing things this way or
| it wouldn't have happened. But I can't help but think the
| technologies that work well for industry are having a
| detrimental effect on a generation of new programmers.
| searchableguy wrote:
| > even the difference between passing by reference vs
| value
|
| You can only pass by value in JS so maybe that's why. It
| is a bit confusing because of how objects work that it
| feels like you are passing by reference. You are passing
| reference as the value.
| brundolf wrote:
| When it comes to primitives you can only pass by value,
| but with objects and arrays you can only pass by
| _reference_. And this applies to comparisons too: when
| comparing objects or arrays you are comparing by
| _reference_ , not deeply by their inner values. If you
| want to compare them deeply you have to take some
| additional steps to make that possible, and all of the
| different strategies for doing so have different trade-
| offs.
|
| I once talked to someone with >5 years front-end
| experience, including some team-lead experience, who
| thought the difference between == and === was that ===
| compares objects deeply. That is very, dangerously wrong.
| The only way I can imagine he got by for so long with
| that misconception is that he'd always used ImmutableJS.
| searchableguy wrote:
| > When it comes to primitives you can only pass by value,
| but with objects and arrays you can only pass by
| reference.
|
| A variable stores reference to the original object and
| when you pass it to a function, it passes the actual
| reference as the value.
|
| I think the last part you mentioned is actually confusing
| in js because lack of clear guidance.
|
| isXyz, Xyz.isXyz, Object.is, and other ways are used in
| practice to do the same thing but they all have different
| behavior which trips people.
| Scarbutt wrote:
| _but with objects and arrays you can only pass by
| reference._
|
| It's still pass by value, you are passing _the_ reference
| of the object as a value.
| brundolf wrote:
| I'm not sure I agree with your framing of the precise
| terminology ("passing a reference to an object, by value"
| vs "passing an object by reference"), but it also isn't
| important. What's important is this: let
| a = { foo: "bar" } let b = { foo: "bar" }
| console.log(a === b) // false
|
| and this: let a = { foo: "bar" }
| let b = a b.foo = "blah"
| console.log(a.foo) // "blah"
|
| This is the kind of misunderstanding that causes
| insidious bugs.
| ithrow wrote:
| _This is the kind of misunderstanding that causes
| insidious bugs._
|
| That's how all mainstream languages with a GC work, Java,
| C#, Ruby and Python, it's not particular to JS. And this
| why why languages like Clojure are nice to work with.
|
| _but it also isn 't important_
|
| It's important if you really want to know why your
| examples work they way they do.
| searchableguy wrote:
| I have been very curious about clojure. What do you feel
| is the most attractive part about it?
| slibhb wrote:
| > I'm not sure I agree with your framing of the precise
| terminology ("passing a reference to an object by value"
| vs "passing an object by reference")
|
| The distinction is that, if JS truly was pass-by-
| reference for objects, you could change what the
| reference was pointing to. But you can't.
|
| I agree with you that objects/references are a stumbling
| block for new programmers in JS. You have to understand
| how these things work but there's no explicit concept of
| a reference, which means it can be tricky to learn.
| [deleted]
| revskill wrote:
| What ? So you put navigation state, query state for each route
| in redux ?
| [deleted]
| mistersys wrote:
| Yeah this is the problem with the React ecosystem. I'm
| intimately familiar with this stack and used to use redux with
| "duck" modules professionally, complete with sagas and epics,
| and rxjs and the whole kitten, so it's not that I don't
| understand all the terms and am just overwhelmed. It's just
| that once you stop using Redux, it becomes so much easier to
| build and manage your app, and you don't even realize how much
| you're complicating everything by using sagas and actions
| creators and reducers and selectors and.. and.. and.
|
| You don't even realize how bad the boilerplate is until it's
| all gone. With svelte and some writable and readable stores, I
| can build apps in a fraction of the time because every time I
| want to make a change I don't have to start with an action
| creator, than integrate that into the reducer, then write a
| selector, then pull it into my component. Oh I guess I need to
| write an epic with rxjs to fetch the data.
|
| Svelte has 2 primitives that replace all of this: readable and
| writable. You can create a writable store and you call
| `.update` or `.set` like react setState. Want to separate your
| update logic from your component logic like in redux? Easy,
| just export functions to update the store instead of calling
| `.update` in your components.
|
| Then, there's readable. Now, readable can be used like a
| reselect selector, but it's also far more powerful. You can
| subscribe to changes from a writable, or even other readable
| stores. You can create a readable that fetches your data. You
| can create a readable that subscribes to firestore collection
| or document. You can make a readable that combines data from
| multiple sources. It's all clear and composable. And I didn't
| have to write an action creator with an action constant called
| `LOADING_PRODUCTS`, and one called `LOADED_PRODUCTS`, and then
| one called `UPDATED_PRODUCTS`, and for good measure we should
| also create an action "PRODUCTS_REQUEST_FAILED" that we'll emit
| from the epic.
| alfonsodev wrote:
| I also don't like having all those constants like
| LOADING_PRODUCTS ...
|
| And I don't have them, instead this is how you create a type
| safes actions with typesafe-actions package.
| export const signIn = { request:
| createAction("auth/signin/request")(), success:
| createAction("auth/signin/success")<{ user: User }>(),
| error: createAction("auth/signin/error")<Error>(), };
|
| getType is a function from typesafe-actions as well.
|
| Not trying to sell you on Redux, just to address your point
| about the constants.
|
| About having to write many Epics, well, end of the day, all
| the Epics have this shape. export const
| signInEpic = (action$: Observable<Action>) =>
| action$.pipe( filter(isActionOf(signIn.request)),
| switchMap(() => from(signInLogic()).pipe(
| map((user: User) => { return signIn.success({
| user }); }), catchError((error)
| => of(signIn.error(error))) ) )
| );
|
| isActionOf is another typesafe-actions function...
|
| I'm not claiming it's superior approach or faster, it's an
| approach that worked for me for medium/large apps, to
| collaborate with other developers.
|
| I'm pretty sure you are right about the Svelte cool things
| you saying I wish I had more time to look into it.
| acemarke wrote:
| We specifically recommend using our official Redux Toolkit
| package, rather than `typesafe-actions`. RTK is already
| written in TS and designed for a solid TS usage experience:
|
| https://redux-toolkit.js.org
| acemarke wrote:
| I do get the arguments that you're making here about Svelte,
| and don't disagree. That said, "Modern Redux" code is very
| different than what you've probably seen even just a couple
| years ago. We've introduced newer APIs like Redux Toolkit,
| which is a set of utilities that provide a light abstraction
| to simplify the most common Redux tasks, and the React-Redux
| hooks API, which is generally easier to use than the
| traditional connect API.
|
| If you get a chance, I strongly recommend reading through the
| newly rewritten official tutorials in the Redux docs, which
| have been specifically designed to show both how Redux works
| and show our recommended practices:
|
| - "Redux Essentials" tutorial [0]: teaches "how to use Redux,
| the right way", by building a real-world app using Redux
| Toolkit
|
| - "Redux Fundamentals" tutorial [1]: teaches "how Redux
| works, from the bottom up", by showing how to write Redux
| code by hand and why standard usage patterns exist, and how
| Redux Toolkit simplifies those patterns
|
| The older patterns shown in almost all other tutorials on the
| internet are still valid, but not how we recommend writing
| Redux code today.
|
| You should also read through the Redux "Style Guide" docs
| page [2], which explains our recommended patterns and best
| practices. Following those will result in better and more
| maintainable Redux apps.
|
| Finally, we've got an upcoming "RTK Query" API that we're
| finalizing and adding to Redux Toolkit (inspired by tools
| like React Query and Apollo) , which should drastically
| simplify the data fetching story for Redux apps.
|
| [0]
| https://redux.js.org/tutorials/essentials/part-1-overview-
| co...
|
| [1]
| https://redux.js.org/tutorials/fundamentals/part-1-overview
|
| [2] https://redux.js.org/style-guide/style-guide
|
| [3] https://rtk-query-docs.netlify.app
| Aeolun wrote:
| You should try redux toolkit
| brundolf wrote:
| > Svelte has 2 primitives that replace all of this: readable
| and writable. You can create a writable store and you call
| `.update` or `.set` like react setState. Want to separate
| your update logic from your component logic like in redux?
| Easy, just export functions to update the store instead of
| calling `.update` in your components.
|
| This sounds very similar to the experience of using MobX. I
| evangelize it as an alternative to Redux every chance I get;
| it's incredible how practical and pleasant it is to work
| with.
| gkaemmer wrote:
| I actually came to this thread expecting more people to
| call out MobX. When I use MobX with react, I find it to be
| as simple and _fun_ as the author finds svelte. Most of the
| problems people tend to raise with React are problems that
| are solved by observable state objects.
|
| I also evangelize it whenever I can -- I don't want MobX to
| be forever doomed to its status as a cult hit!
| brundolf wrote:
| It's baffling to me how distant of a second it is in
| terms of popularity. Instead of forcing you to contort
| your program into a special paradigm in order to deal
| with reactivity in a sane way, it simply makes reactivity
| a non-concern (while remaining pretty simple and
| predictable when you do actually care to dig beneath the
| magic). You can write code in a way that's natural and
| simply not think about reactivity most of the time, and
| you'll even get better performance in many cases because
| of the highly-granular pub/sub that it sets up
| automatically. I cannot praise this paradigm enough.
| Aeolun wrote:
| It is also fucking magic. I love it when it works, but I
| have no idea why it doesn't when it breaks. The same is not
| true for Redux, which is so simple I can build a house with
| it.
| williamdclt wrote:
| To be fair, you're criticizing Redux more than React. And
| even then, you're criticizing a specific pattern of using
| Redux: redux-toolkit melts away all the boilerplate you're
| talking about, and you could use something else than Redux if
| you wanted.
|
| I agree that React folks (me included) tend to reach out to
| Redux much too soon, though.
| pier25 wrote:
| > _I love Firebase Authentication, it 's such an easy way to add
| auth to side projects._
|
| It's easy to use but it adds 55kB gzip to your project.
|
| https://bundlephobia.com/result?p=@firebase/auth@0.16.4
|
| A couple of comments on the Svelte code.
|
| 1) It doesn't makes much sense to use onMount() with
| listenForAuthChanges(). Just modify the currentUser writable
| whenever onAuthStateChanged() has an update. Now simply import
| and use $currentUser in your components.
|
| 2) You don't need to use currentUser.subscribe() from your
| .svelte files as you can use the reactive $: notation for this.
| You can, if it makes more sense to you, but I wouldn't say it's
| idiomatic.
| ampdepolymerase wrote:
| Re 1) Where should you put the code to initialize the SDK? Code
| that ideally should only be ran once in the entire lifecycle of
| the page.
|
| For Firebase, will ES modules help with code splitting? The new
| Svelte kit framework is built by Vite (runs on ES build
| underneath).
| pier25 wrote:
| If you have code in say _store.js_ it will triggered whenever
| the file is imported the first time.
|
| I also trigger init code from my entry point (eg: _main.js_
| ).
| akiselev wrote:
| I use a dynamic `import()` in the login form submit handler
| with an initialization flag. Code splitting is handled by the
| bundler
| [deleted]
| Greek0 wrote:
| The author praises Firebase Auth for its ease-of-integration, but
| I'm leery of depending on Google products due to its support
| horror stories.
|
| Can anyone recommend good, easy-to-integrate alternatives?
| dimgl wrote:
| I've always wanted to try Auth0 and I've heard great things! I
| would love to hear if anyone has had a positive experience with
| Auth0 as well.
| maxrev17 wrote:
| Positive exp with auth0, though if you can afford to control
| this stuff yourself maybe I'd lean that way.
| tehbeard wrote:
| Another positive experience with Auth0, if a little finicky
| in my usecase (using it as a SAML IDP for testing).
|
| They have recently been bought out by Okta... Which by some
| accounts might not be a good move.
| _puk wrote:
| I came across Appwrite[0], when looking for open source
| Firebase alternatives.
|
| It has a long list of supported OAuth2 providers [1].
|
| It worked for me out out the box (DO docker image), and seems
| to be progressing well. They have some beta Svelte libraries,
| and it was simple enough to integrate for my uses.
|
| No affiliation, just happy to have found it.
|
| 0: appwrite.io 1:
| https://appwrite.io/docs/client/account?sdk=web#accountCreat...
| nwsm wrote:
| Auth0. I use it on all side projects and in production at work.
|
| We actually started with Firebase Auth (branded as Google
| Identity) and moved to Auth0 later for some small differences.
|
| Also though, Auth0 was just acquired by Okta, if that matters
| to you.
| nicoburns wrote:
| Do you need social logins? If not (and you just want
| email/password login) then implement it yourself. Auth isn't
| hard, and Firebase Auth doesn't provide you much in terms of
| managing roles/permissions or anything like that.
| movedx wrote:
| > Auth isn't hard
|
| ... :-|
|
| Authentication/Authorisation (AuthZ) is hard, brother.
| Implementing what you think looks like AuthZ is easy, but
| making sure you've got all possible avenues covered is hard.
|
| Getting AuthZ correct and having everything covered is hard.
|
| Security is hard.
|
| Source: see the entire field of security and all the
| companies, products and services that have been invented to
| try and solve this problem.
| framecowbird wrote:
| Javascript n00b question... is there any difference between
|
| onMount(() => { return listenForAuthChanges() })
|
| and
|
| onMount(() => listenForAuthChanges())
|
| ?
| rahulpadalkar wrote:
| no
| hazzahzah wrote:
| same
| jfengel wrote:
| They are the same. It's a matter of style.
|
| For that matter, you could also write:
|
| onMount(listenForAuthChanges)
|
| which is technically simpler -- you're not constructing a new
| anonymous function. But if you wanted to extend the code (to
| say, add a console.log), you'd need to do the top version,
| which already has the braces.
|
| It's up to your judgment of what's clearer and likely to be
| more maintainable.
| M2Ys4U wrote:
| That may be visually simpler, but if onMount were to start
| passing a parameter to its callback in a future version (for
| whatever reason) then that will be passed to
| listenForAuthChanges. Using the anonymous function means that
| wouldn't happen.
| filoleg wrote:
| >For that matter, you could also write:
|
| >onMount(listenForAuthChanges)
|
| >which is technically simpler -- you're not constructing a
| new anonymous function.
|
| Not just technically simpler, it is a perf improvement over
| initializing an anonymous function every time onMount is
| called (which you have already mentioned, I just wanted to
| emphasize). A minor performance improvement at that, but
| still, small things add up. I agree with the entirety of your
| post, however, well-written.
| hoten wrote:
| That should work in the provided example, but in general
| `fn(cb)` is different: you lose the implied `this` binding
| unless you do `cb.bind(something)` beforehand.
|
| There's also some unexpected trouble due to potential extra
| parameters. Consider the output of ['1', '2',
| '3'].map(parseInt)
|
| gives: [1, NaN, NaN]
|
| So yea, fn(() => cb()) is the same as fn(() => {return cb()})
| - just syntactic sugar when the anonymous function has just
| one statement. but fn(cb) is semantically different.
| brundolf wrote:
| This is a utility function I carry around between projects
| for the "logging within a pure expression" case:
| function log(expr) { console.log(expr);
| return expr; } onMount(() =>
| log(listenForAuthChanges()))
| KitDuncan wrote:
| no it's the same
| oplav wrote:
| No, they are functionally the same.
| beaconstudios wrote:
| The svelte approach of implementing better paradigms using
| compilation rather than using abstractions just seems infinitely
| better, and a better way to scale up a program in general. I do
| wonder why this idea never caught on; I think Alan Kay was
| investigating building a programming platform based on this idea
| but that's just academic.
| amelius wrote:
| It's kind of funny that a NYT graphic designer (Rich Harris)
| outsmarted so many CS academics in finding the right software
| engineering tools.
| beaconstudios wrote:
| Experts seem to suffer so often from myopia. Sometimes all it
| takes is a fresh perspective to glean a new idea.
___________________________________________________________________
(page generated 2021-03-24 23:01 UTC)