Comparing Svelte and React
41–50 of 338 posts
Re: Comparing Svelte and React
#42The 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?
Re: Comparing Svelte and React
#43Is 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?
Re: Comparing Svelte and React
#44> 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 st…
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.
Re: Comparing Svelte and React
#45Earlier quoted context omitted.
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…
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 generaliz…
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.
Re: Comparing Svelte and React
#46Earlier quoted context omitted.
Last I checked it was impossible to parametrize component type. In React you can write ` users={...} />`.
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".
Re: Comparing Svelte and React
#47Earlier quoted context omitted.
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…
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…
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)
Re: Comparing Svelte and React
#48> 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 st…
What ? So you put navigation state, query state for each route in redux ?
Re: Comparing Svelte and React
#49Earlier quoted context omitted.
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…
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 generaliz…
Re: Comparing Svelte and React
#50Earlier quoted context omitted.
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 dissimila…
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, w…
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.