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.

here's a pastebin of my wrapper around requests

https://pastebin.com/V33F1f2F

it is already highly configured and abstracted.

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.

Does that sound logical to you?

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?

yeah, making it into a custom hook lol.

When did something that was originally worth 5 LOCs turn into 20 LOCs

I don't agree that they will match React's community and environment in the near future, if at all.

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.

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.

almost with many things in software development to be honest.

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.

my day to day to do list varies in the number of tasks, but the completion will always be in boolean

    [
        {
         "task": "do Foo", 
         "completed": False, 
        }, 
        {
         "task": "do Bar", 
         "completed": False, 
        }, 
        {
         "task": "do Baz", 
         "completed": False, 
        }, 
        ...
    ]

The schema on that end is pretty intricate but to prevent hitting two services for certain types of data, we just dump it to a json column.

Furthermore, for a personal project of mine to help me with productiving / daily schedules, i'm using a json column for a to-do list in the schema of

{[some_todo_item]: boolean,}

which can't traditionally be represented in pg columns as the to do items are variable.

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.

some apps need native functionality, for example, instagram needs access to your camera.

- learn docker / docker-compose - tie a websocket server, a task queue, and 2-3 http microservices together - you don't have to have many resources, maybe 4-5 endpoints that go through all services - have a client javascript front like react - (bonus for grpc communication for intermediary connections between microservices) - try to break it/ fix it as much as you can. - along the way you'll introduce yourself to timeouts, retries, rate limiting, and other secure practices.

watch guarav sen or hussein nasser on youtube - they are extraordinary resources for aspiring and even competent backend architects

That being said, prop drilling was made more of an issue than it really is, especially considering the boilerplate needed for state management libraries like Redux.

But if there does need to be a global store, I usually reach for zustand as the API is probably the easiest out of the ones mentioned.

Sometimes you have to be practical and give up certain areas for the sake of the whole.

I don't even think React is even that bad as you claim it to be, judging from your past posts.

React Native is one of the best things to ever happen to native development, removing the atrocity that is the separation of development of apple and android - one of the most productivity inhibiting factors to a startup out there.

This is why react is so strong.