Live data from Hacker News

React is holding me hostage

emnudge.dev

411–420 of 553 posts

Re: React is holding me hostage

#411

I'm still a React guy. I've also worked with Angular and Vue and toyed with Svelte. People tend to compare these frameworks on things that don't matter - often it's performance. We used to compare React performance to AngularJs performance too, which was meaningless. VDom is nice. Reactivity in signals is nice. Limiting rerenders is nice. But I choose frameworks because of developer ergonomics. The killer feature for…

There's 2 things that I hate about react. 1) JSX - It's terrible. Svelte, Vue, Riot... they all got it right. JSX, mixing a weird syntax of HTML and JS together is just inferior to HTML with additional markup. 2) I don't know why but every react project has crazy levels of abstraction. Everything is 15 layers deep and making any sort of change requires way too much effort to navigate 15 files and code reading to make…

> JSX - It's terrible. Svelte, Vue, Riot... they all got it right. JSX, mixing a weird syntax of HTML and JS together is just inferior to HTML with additional markup

Hard disagree. Every time I work with Svelte\Vue I wish it had JSX, which is way superior to templating because:

- Creating sub components in the same file is super important. Going to a separate file, copying all the imports, writing emits, then going back and importing that file is too much hassle for a simple case where you have a carousel with cards. Refactoring is slow, components end up bloated.

- Passing down functions is more convenient than emits. For all the talk about how svelte is boilerplate free, it's equivalent of passing down a function and calling it is at least 5 extra lines of code.

- Passing down JSX elements is more convenient than slots. Every time I need to remember how to do named slots in vue\svelte I have to read documentation, while in React the mental model is obvious.

Re: React is holding me hostage

#412

I'm still a React guy. I've also worked with Angular and Vue and toyed with Svelte. People tend to compare these frameworks on things that don't matter - often it's performance. We used to compare React performance to AngularJs performance too, which was meaningless. VDom is nice. Reactivity in signals is nice. Limiting rerenders is nice. But I choose frameworks because of developer ergonomics. The killer feature for…

How is performance not important in this context? React is very sluggish when updating many elements at once, for not very large values of "many". With some regularity, I've debugged React+MobX jank issues where a bigger update, such as switching from one panel to another, takes upwards of 200ms on a mid- or low-range machine. None of this is perceptible on our beefy dev boxes, which is why I think people disregard i…

"the modern webapp experience is so miserable for the average person."

Hyperbole. Web apps would not be so ubiquitous and popular for solving business problems if your claim was true.

Re: React is holding me hostage

#413
post #295

Earlier quoted context omitted.

Performance is obviously important, to suggest otherwise is just silly. Both Google and Amazon have researched this topic and the results are readily available. First link I found: https://www.thinkwithgoogle.com/marketing-strategies/app-and... Why do you think there some much time and effort going into improving performance of computing in general. Facebook Lite, android go, GPU's, cpu improvements, 5g, etc. The imp…

Arguing features vs performance is really about which features are more important. Performance is just another feature. I use Vim and I use VSCode. There is little debate about which has better performance and which has more features. It's also easy to see which has more users.

Is it vim in all 3 categories?

Re: React is holding me hostage

#414
post #216

Earlier quoted context omitted.

I have a beefy machine and fast internet. Yet, JIRA is annoyingly slow. Half the time, pages on my bank’s website take forever to load, or don’t load at all. I don’t have any numbers, just some anecdotal experience like the above. It is not just speed. The UI of many sites suck too. Amazon, GoDaddy, for example. Then there are ads. We don’t see ads in between content anymore. It is content within ads these days. I am…

The problem with Jira...is that it isn't for you. No really. It is a B2B company that sells an idea to large orgs. "Know what is happening for everything and where you will be in a month. It is not "Enable your workers to work more efficiently". Jira simply doesn't really care about the average dev or such. In fact, most orgs use such a wildly configured version that it is pretty absurd. Let me give you an example: M…

> The problem with Jira...is that it isn't for you.

It's more or less one of those enterprise software packages that will be depended upon in larger orgs, because "nobody ever got fired for choosing $VENDOR". That sort of software tries to do a bit of everything, provide lots of features and customizability, sometimes at the expense of being more complex, bloated and slow.

Most people working on their own projects, when fully in control of the decision of what software they want to pick to best suit their own direct needs, might settle on something like Trello or even Kanboard instead. Personally, I self-host OpenProject because its features are a nice fit for my needs, even if it's still a bit sluggish (Rails app, limited hardware resources). Honestly, the performance of Kanboard was blazing fast when compared to anything out there - which is in no small part thanks to how focused and minimalist it is, which in some cases will be exactly what you'll want.

As another good example, I'd also put something like the Oracle database in same category: there will be many projects out there developed around it, as well as lots of knowledge, training, as well as entire professions built around it. But most people won't necessarily reach for something like Oracle XE for their own personal projects, they'll instead pick something like PostgreSQL or MySQL/MariaDB, because both of those are a little bit simpler to get started with and keep running, while still provide sufficient functionality.

This is an anecdote, but recently I launched all of the mentioned database options one after another in containers, for some testing. Oracle took around 10-20 minutes to start up an de usable. MySQL took about 5-10 minutes to become available for connections. PostgreSQL needed just 2 minutes. That's even before I get into how much data Oracle created in a container volume meant for data persistence (an order of magnitude more than MySQL or PostgreSQL).

I experienced similar behavior when setting up my own trial/testing license of Jira because I needed to do some integration dev work - with the resources given to it, I found it to be pretty sluggish and creating new issues took multiple seconds, which does get annoying when you also want to edit some of the fields, or have to do it often as a part of your work. Though I don't have exact numbers for that, I'm afraid.

Re: React is holding me hostage

#415
post #382

Earlier quoted context omitted.

JSX forces you into small tiny components because anything of any decent size becomes unmanageable. There's way too much mixing of JS into the template. Vue you can do Submit In React I've seen people do: if (!props.isFormValid) { return Submit ; } return Submit ; This is just an example, obviously you can write this better in React. My point is there's /always/ so much conditional markup like this in every react pro…

> JSX forces you into small tiny components I'm surprised you see that as a disadvantage, for me that's always the biggest advantage of JSX-style syntax! I don't want huge components that do everything, I want components to do as little as necessary to be actually useful. It's the same as if I were writing functions: keep them fairly small, make sure they're doing a specific thing usefully, and then compose them toge…

> one of the things that I struggled the most with, that splitting one component into two components required a load of boilerplate and a whole new file.

Oh, I didn't know that about Vue. Eww!

Re: React is holding me hostage

#416

Earlier quoted context omitted.

> Performance is very very rarely a contributor to a product success. Users prefer more features over more performant app all the time (both directly when asked and indirectly by what products they choose). I close sites all the time when they fail to work quickly. I have aborted orders on sites midway through when the interaction became sluggish enough that I wasn't confident in the value of the product anymore. Thi…

React/competitor performance that people use to compare frameworks is about rendering performance. E.g. React takes 100ms longer to rerender 10,000 elements (random numbers for the example). In these situations the actual real world difference will be negligible. Site performance is much more API based, and that’s the same regardless of frontend. React has more library solutions to optimize the UX though, as it’s the…

> Site performance is much more API based

Exactly. And those API calls are going out over the network. The caller has to serialize the request into text, the API implementation has to deserialize the text into values that can be passed to a local implementation function and then the API implementation has to take the result and serialize it into the return. Finally the caller has to process the result.

That's the simple case. Things get even more involved when you start using HTTPS to secure the data in transit on the channel and using OAuth to secure the access to the API. What appears to be a simple API call turns into a lot of back-and-forths with multiple servers - with all the network latency that entails. Then developers complain their website is slow. Gee, I wonder why!

Re: React is holding me hostage

#417
post #402

Earlier quoted context omitted.

React/competitor performance that people use to compare frameworks is about rendering performance. E.g. React takes 100ms longer to rerender 10,000 elements (random numbers for the example). In these situations the actual real world difference will be negligible. Site performance is much more API based, and that’s the same regardless of frontend. React has more library solutions to optimize the UX though, as it’s the…

Not exactly true about "performance is more API based". Everything adds up. 400ms here, 700 there. Websites can be slow even before api calls are triggered or on the middle of them, or while the results from api responses are presented.

Rendering performance can definitely add up, but rarely do React websites render so many elements that you get to 700ms. Once you do, you can nearly always fix that with an performance optimizations iteration. I reckon that issue is just as likely in all frameworks, and less likely to be about React using 0.2ms (or something like that) longer per element to render before optimizations.

Re: React is holding me hostage

#418

Earlier quoted context omitted.

Vue is more akin to the old way of doing things with static templates (Jinja, Mustache, Erb, PHP), just with a dynamic twist. React is not perfect, it's bloated, but the reason it took off is that it brought something new to the table as a general and programmatic way to construct UIs. Being a child of Facebook helped it achieve dominance but considering that before React we had angular (shudder) and jquery, React's…

Everyone is going back to "past technologies" like SSR, being old tech does not mean obsolete, send html directly to the browser in most cases is better than render them in the client, I think the better approach in theory is the island architecture that I saw on Fresh/deno and Qwik, both feels more like how we used to work in the past, minimal JS send to the client and more HTML send from the server.

SSR never faded and has always been an important requirement. Especially if you wrote SEO sensitive SPA's. We are not going back to SSR but are able to combine both SSR and SPA's more easily, as is indeed the case with dynamic islands and for instance React Server Components.

Re: React is holding me hostage

#419
post #194

I'm still a React guy. I've also worked with Angular and Vue and toyed with Svelte. People tend to compare these frameworks on things that don't matter - often it's performance. We used to compare React performance to AngularJs performance too, which was meaningless. VDom is nice. Reactivity in signals is nice. Limiting rerenders is nice. But I choose frameworks because of developer ergonomics. The killer feature for…

TSX + MobX are the reason I'm happy to stay on the React train after a transition from AngularJs (1) to Vue 2 to React.

You might also be interested in checking out Vue 3 (with the Composition API) and Pinia, it's a pretty nice setup that feels similarly nice to how working with MobX is and even supports TypeScript.

Composition API: https://vuejs.org/guide/extras/composition-api-faq.html

Pinia (state management store): https://pinia.vuejs.org/

TypeScript support: https://vuejs.org/guide/typescript/composition-api.html

While I mostly stuck with JavaScript, personally I found the setup more convenient to use than working with hooks in React, and Pinia is also more like MobX than something like Redux, in that you don't have to work with too much accidental complexity for relatively simple setups. Sadly I don't have examples from that project, because it was proprietary, but the linked docs are nice.

Re: React is holding me hostage

#420
post #99
post #70

Earlier quoted context omitted.

None of that is true in React hooks. The negative sentiment towards hooks that you see here is because it is weird and complicated. Want to see how much simpler code can get when you code without React or any such fat frameworks? Take a look: https://github.com/wisercoder/eureka/tree/master/webapp/Clie... You just need to know JavaScript, HTML and CSS, not much else. The code is simple, and yet maintainable. No need…

How can you ever be sure that your state is valid when you’re putting it on the DOM? Worse yet, only parts of the state is stored there. I can’t really call this code simple since it had to resort to timing hacks to get its functionality in order. A random 250ms delay and bam, bugs you cannot reliably reproduce

Can you clarify what you mean here? What state is in DOM? Do you mean the state inherent in input elements? What timing hacks are you talking about?
Post reply on HN