shroompasta

Capacitor uses WebView which is less performant than RN

>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?

>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

I agree that Svelte/SolidJS has overall better architecture.

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

>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.

i agree, but not a critical issue.

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.

Svelte is a solution to a problem that doesn't need to be solved.

almost with many things in software development to be honest.

svelte native is nowhere near react native in maturity. Discord uses React Native. What larger companies uses Svelte Native?

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.

This is a questionable comment

>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.

How does this validate data with a variable amount of keys with the same value type for example a to-do list

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, 
        }, 
        ...
    ]

Also, what is the issue of schema validation before inserting into the json column, as this is what I'm doing with a small microservice with Redis.

I'm using a pg json column to store data as a second source of truth for data that is primarily held on a separate microservice.

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.

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.