shroompasta

Capacitor uses WebView which is less performant than RN

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.

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?

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

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.

performance.

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

me with escargot

there are many answers to this, but i'll try to give a, although biased, straightforward example.

- 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

Zustand is a lot more popular than the comments or the article implies. I see it quite heavily used amongst Netflix engineers.

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.

I take absolutely nothing noteworthy of your comment at all other than that you have a bias that you need to put in check.

While I agree that React (for the web) isn't the best SPA out there (I would use Solid or Svelte), It's the most practical simply because of the hiring pool and because of React Native.

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.

No you're missing the point.

What's easily the better decision for a startup that has to deal with mobile and native platforms?

I seriously don't know what you people are building that you think low/no js is viable.

Collab tools like Trello Asana need high js

Chat applications need high js

Drafting applications like FanDuel, DraftKings, Sleeper need high js

Music apps like Spotify or Soundcloud need high js

Financial apps like Coinbase or Robinhood need high js

Seriously, what are you people building that you think low/no js is okay.

Choosing any front end choice is a big decision.

But you're not going to get anywhere near the hiring pool nor are you going to have an ease of choice in native platforms.

React is easily the best decision a startup could make right now.

If your app is a simple website with a few interactive elements.

lol

While I agree that Front End "engineering" isn't as complex as other fields, calling it "shameful" is a bit much.

There is a huge requirement out of web apps today that SPAs are more and more required than your simple html + css blog posts.

Posts like these is where I feel the age of HN, that are becoming bitter about fields that were once very simple, ending up complex to suit the needs of the times.

Everywhere I look around, people on HN feel like we're still in the age of blog posts and form submissions, when in reality, there are people trying to port applications like Photoshop towards the web.

If Photoshop was available on the web, wouldn't you think that the Front End required an honest amount of "engineering"

And it doesn't even have to be a front-end heavy application like photoshop - it could just be a simple chat application that needs to be on the forefront of the site while you can still browse.

You can use whatever framework you'd like to solve your "bloat" issue, but the problem is, especially for startups, you're not going to get anywhere near the hiring pool, nor or you going to have an ease of choice for your native platform.

This is what makes React so strong right now.

I wished you had addressed this, instead of just deriding the entire front end community.

Angular -> React -> Vue -> Svelte -> Solid -> Marko -> Hotwire

Please stop.

The reason why React is so powerful is because of the maturity of React Native.

If you're a startup deciding your FE framework and you have mobile to consider, then chances are that React is best fit.

Unless you have capital to blow on a separate native team, lest it even be more separated to kotlin / swift, then sure you can possibly afford all these niche FE frameworks.

Lets not even talk about hiring pools.

React is good enough, and it's a shame that many of you think the answer is a new framework with better philosophy.

Trust me, I love reactivity > virtual dom, but React is good enough.

It doesn't need to be the best, it just needs to do its job.

The only thing I'll ever consider switching to is when WASM comes out with a framework - till then I'm betting on React.

React is here to stay and will have jquery like longevity.

Sure, performance wise, it isn't the best, but performance isn't an end all be all.

What separates react from the rest of the group is the maturity of React Native.

If Discord is betting on React Native, so too can it be used for a lion's share of applications out there.

When you're a startup deciding between technologies, usually you're a 1-5 man shop.

If you have the capital to blow, you can build separate teams for native + web, and separating native even further with Kotlin/Java and Swift with your choice for the web platform.

(I'm not trying to the Dart ecosystem just to only use Flutter, in which, Flutter-Web isn't SEO friendly)

Or you can just use React + RN and essentially have one team and save you anywhere from 500k-2m in hiring.

This is why React is so strong.

It's not because it's "performant", it's because it's practical, and even for performance it's good enough.

i think you missed his point to be honest.

Regardless of where place your tailwindcss or where you split / sort classes, reading iteratively from left to right, especially if the css rules are numerous, is not legible.

just looking at the two examples above, and already I can tell how much it would be easier to maintain verbose css.

i'm not sure what you mean by 'seamlessly'

but a media query in styled components would just be

    @media (max-width: 700px) {
        css here
    }

Also, the lack of address of real problems of tailwindcss of OPs comment in terms of mantainability is something you consider.

reading iteratively from left to right especially if it has 10+ css rules, in terms of legibility, is not really all too great.

I would absolutely hate to adjust something in tailwindcss, after not seeing the codebase in a month's time.

Whereas regular css properties, i can easily find by eye.

Yeah, I've tried tailwindcss, but having many rules of css on one line isn't even at all legible, nor do I want to use horizontal scrolling.

Ubuntu the best looking one. no bias.

User Retention is a trillion+ dollar industry.

At what point can we stop placing the blame on ourselves and towards those who make these products?