I do not think it’s that straightforward actually. WebViews are JIT compiled which leads to big performance gains. React Native only can use a JIT with Hermes and Hermes is just plain worse than something like V8 with JIT enabled.
I don’t think RN can use a JIT at all on iOS. Only WKWebView processes can due to Apple’s security model. This makes Capacitor JS significantly faster for certain workloads
You should try to communicate more forthcomingly that CapacitorJS bundles the webapp with the native binaries, which means that you get better startup performance, but at the cost of not being able to serve the webapp fresh from the web (instead having to go through app store review process on every update like with native apps).
>The one talking about fetching data recommends a 3rd party library to make it simple but tells you how to avoid certain issues if you want to go the route of implementing your own fetching.
yeah, making it into a custom hook lol.
When did something that was originally worth 5 LOCs turn into 20 LOCs
> When did something that was originally worth 5 LOCs turn into 20 LOCs
When you want it to work properly in all the cases. That includes when new data is being fetched and you don't want to show the old data. Or when you want to not refetch data if the conditions for refetching are not met. Or when you want to cancel an in-progress data fetch if the data shall no longer be shown after fetching it because the user closed the component tasked with showing the data.
>That includes when new data is being fetched and you don't want to show the old data
This only really happens when you have race conditions
> Or when you want to not refetch data if the conditions for refetching are not met.
This only happens when you fetch based on state update on the same component
> Or when you want to cancel an in-progress data fetch if the data shall no longer be shown after fetching it because the user closed the component tasked with showing the data.
you can do this with certain conditionals and a cleanup function
over 3 quarters of my data fetching is just a simple fetch on onComponentDidMount
do you mean to tell me I have to bring in a library just for that?
> This only really happens when you have race conditions
Or when the network is unpredictable, you retry because it's taking too long, then the second request succeeds, then somehow the first request succeeds.
> This only happens when you fetch based on state update on the same component
Or on props update.
> you can do this with certain conditionals and a cleanup function
That's no longer 5 LOC.
> over 3 quarters of my data fetching is just a simple fetch on onComponentDidMount
Congratulations. Do you also do that for authenticated requests? If so, either you are using some kind of hardcoded global variable, or you are not using 5 lines of code.
> do you mean to tell me I have to bring in a library just for that?
Of course not. You can implement your own library for that. Or copy-paste it all over the place.
What I'm saying is that for things that are more advanced than basic data fetching, you may want to bring better tools than just fetch + 4 extra LOC.
>Or when the network is unpredictable, you retry because it's taking too long, then the second request succeeds, then somehow the first request succeeds.
This has an atomically low chance of ever happening, and never happening on single threaded monolithic servers.
>That's no longer 5 LOC.
Okay cool, 7-8 LOC, better than abstracting it into a whole new custom hook.
>Congratulations. Do you also do that for authenticated requests? If so, either you are using some kind of hardcoded global variable, or you are not using 5 lines of code.
You need to be more specific about authenticated requests, because cookies that are sent back as a response will have directions on how they should be sent back to the server on each request that requires no javascript at all.
If you're using token auth with localStorage, which probably isn't a wise idea because you're now susceptible to XSS attacks, then you should already be abstracting that away.
>What I'm saying is that for things that are more advanced than basic data fetching, you may want to bring better tools than just fetch + 4 extra LOC.
All i want to do in the useEffect is await api.getGamesByDate(), and this should be fine.
What you're suggesting is that you support the React team's decision in that I have to have an additional wrapper around my apiCalls just to avoid two fetch calls in Strict Mode.
>I imagine most folks who love React syntax have Stockholm Syndrome at this point.
And I'd imagine that most folks who are advocating for Svelte never had to build up a startup before.
If everything was done for performance, then python or ruby wouldn't be used as web server languages today, and yet python and ruby web servers comprise of a significant amount of webservers.
And besides, most performance improvements between React and Svelte are almost invisible to the naked eye, we're talking differences of milliseconds here.
So you've built your web client in Svelte, are you ready to traverse into new frontiers and build a production ready app in Svelte Native?
Or are you going to blow extra capital to hire ios and android developers?
Are you ready to deal with the fact that its not using its own implementation and is using Native Script under the hood?
What about the hiring pool?
Svelte is a great choice for personal projects, but extremely impractical for a startup.
Svelte Native will NEVER reach the maturity that React Native has, and that is what makes react such a practical choice for a startup.
If you had to consult a startup to choose a FE framework for both its web client and mobile client, and you suggested Svelte, I would bet that not only would they lose a lot of capital and time, they would run into so much technical debt.
Svelte for the web client is fine, but now you have to manage a different team for the mobile client.
This is what makes react so strong - the web and mobile clients can be handled by the same team.
React is Practical; it doesn't matter if the philosophy in how they render the dom isn't up to par, the community and the environment around it makes it practical.
And honestly, the performance is good enough.
If Discord can use React + RN, it's good enough for the lion's share of applications out there.
> And I'd imagine that most folks who are advocating for Svelte never had to build up a startup before.
>Svelte is a great choice for personal projects, but extremely impractical for a startup.
> What about the hiring pool?
> Svelte for the web client is fine, but now you have to manage a different team for the mobile client.
These are interesting assertions and run contrary to my experience. I work for a successful startup and our front-end team uses Svelte. We've had nothing but success. We run a production-grade mobile app (Cordova) on old low-powered client-provided devices including RF guns (Android 5 to 9) with multiple thousands of concurrent users in stores/logistics warehouses, and a web app running on desktop (Chrome/Firefox/Safari). And, every front-end developer we have (including myself) learned Svelte on-the-job within a few weeks.
Re-read my comment. I was not talking about app performance, though Svelte is indeed lighter and faster for various reasons.
I made the analogy to assembly vs C. It's not about raw speed. Many APIs and (frankly) hacks have been added to React that developers have learned over the course of years. APIs and hacks that simply aren't necessary for Svelte.
I totally agree that the community behind React is absolutely massive. If you want a component for something, chances are someone has made it already. That is a huge advantage. However while the odds are good, the goods are often odd.
When the dev environment is simpler, making the component isn't such a burden. When the code is simpler, maintenance and improvement are easier.
Today, React may be the better choice in many circumstances, and that's fine. However moving forward, expect to see more cases where there's a better option. Because let's face it, Svelte is simply better architecturally. React may be more popular, but you can't argue its foundation is somehow more sound.
In less than a decade, i'm already guessing less than 5 years, WASM will come out with a viable frontend solution that will actually be groundbreaking.
The battles between frontend philosophies in javascript will look like child's play then.
I'm not going to waste anymore time switching FE frameworks (Jquery->Angular->React), as I've found that it's been quite useless (Although I really liked Solid - shame their animation libraries suck and the overall environment isn't mature enough).
I'm happy with React.
Performance isn't an end all be all.
Svelte doesn't have a chance to match the hiring pool of React, nor will Svelte Native ever compete with React Native in maturity.
In 5-7 years, we will be talking about ending the use of Javascript on the Frontend, So i really don't care about reactivity.
> In 5-7 years, we will be talking about ending the use of Javascript on the Frontend
The same prediction has been made for the last 25 years. Having seen the rise and fall of VBScript, Flash, Silverlight, Java applets, and countless others, I would not be so blasé as you about the imminent demise of JavaScript. There is a profoundly strong possibility that you are dead wrong.
Svelte/Solid JS and reactivity are great; Reactivity definitely is a better philosophy than Virtual DOM diffing.
However, I'd like to add one more reason to the "arguments adopting svelte" and that is native development.
Svelte Native doesn't even come close to touching React Native in maturity, and I'm willing to bet it never will.
For a startup to consider a frontend technology, React is easily the better choice in terms of capital because there is no way you're going to build a production ready native app in Svelte Native.
If you were to build your web client in Svelte, then you would have to spend capital on another team to build Native (God forbid in React Native), in which you would split teams on ios and android.
Or you could you use just one team for React + RN altogether and save you possibly millions in capital.
Also I'd like to mention that the NYT article that was linked to showcase Svelete actually showcases more of D3 instead.
Mike Bostock also used to work for NYT and NYT absolutely loves using D3.
>If you don't use the same Docker Compose file for Production, don't use it for Development. Your two different systems will diverge in behavior, leading you to troubleshoot two separate sets of problems, and testing being unreliable, defeating the whole "it just runs everywhere" premise.
Anyone ever developing a react project on docker compose would never run a build step for development.
In fact for most setups, I probably wouldn't even run react on docker-compose for development, and just use the dev server straight up on my machine.
Furthermore, working with any python http servers is substantially easier when working with a dev server in development, rather than running your server through gunicorn or other wsgi servers - not to mention the ability to hot reload for development.
I'm sure that there are many other cases where it's necessary and convenient to separate production and development docker compose files.
I don't think it's fair to say that there is no point in having separate docker-compose files as the lion's share of dependencies that need to be consistent is inside each container, not on the docker-compose configuration level.
Do you need schema to be enforced? I guess my question was: "why use a JSON column with an enforced schema to save data, when perfectly good normal pg schema are available?"
Totally get why you would want to just save data in whatever format you send it in, that's how I prototype as well. But a regular column has the advantage of familiarity with other devs, not to mention better syntax for querying.
In my opinion, design tools like figma or adobe xd are abstractions away from the tech stack in which perpetuates more roles in which there doesn't need to be.
A UI/UX Designer should be competent in CSS in which the browser should be their whiteboard / canvas.
Abstracting the design portion away to other platforms only furthers that gap between design and development.
An optimal and streamlined design regiment is pen and paper straight to css.
Hire designers that are good with css in short.
To bridge the gap between design and development is not to find ways in which those teams communicate better, but rather a fundamental change in how we look at designers and their competency.
To further that point, if we take a look at motion design and animations, it should not be the case that a designer comes up with a wireframe and leave it to the developer to build that for building animations is out of scope for a dev task, but rather these tasks should be soley on the ui/ux designer themselves.
