As someone who had to work around the bugs and limitations of IE6 for years in the enterprise, popularity is not a measurement of how good a technology is.
The reason React is "embraced" by the industry is that it is widely used, not because it's the best choice. This lowers the risk for companies that can replace its developers with another easily. I'm not saying it's as bad as beeing stuck with a stale IE (yet), but there are surely good alternatives out there.
"Nobody has been fired for choosing IBM", was a saying that applies to React today
It has reached the "IBM" point where it's so widely used, that it has become the most rational choice for enterprise.
We have to wait for a few years while smaller businesses who don't have (or care about) the same risks uses better alternatives until they reach the point where you are not blamed for choosing something outside the box
> The reason React is "embraced" by the industry is that it is widely used
That looks like tautology to me. What point are you trying to make with this?
Comparing IE6 and React is _hardly_ a fair comparison. One was a Trojan horse injected by corporate policies and ACLs, while React gets explicitly chosen by teams. And... Yes, there _is_ a reason why nobody gets fired for choosing React: it's not a bad choice! Is Svelte a better choice? Not universally. Unfortunately—like with many things in our field—it comes with trade offs and the answer boils down to "it depends" again.
React has its quirks, but "hating" on a library because it was part of a dumpster fire project doesn't mean the library is bad, just that people using it weren't competent with it (not necessarily incompetent in general).
Vue, Svelte, Leptos, Solid, Elm. I've seen all of them used as dumpster fire fuel, and it was hardly the library's fault.
I do not hate React and am not the person who made the dumpster fire argument. The original person complained about React, and another person used popularity as a counter argument. That was what I replied to.
> That looks like tautology to me. What point are you trying to make with this?
React is in a place now, where it is the "safe" default choice for Enterprises. It's not necessarily a bad choice, but I argue that risk management is often an important part of deciding which tech to use.
It got to this point by being backed by Meta and was a genuinely good alternative to other frameworks at the time. But it is my view that enterprises prefer React not because it is the best, but because it is good enough and easy to find workers with experience. This is a self reinforcing feedback loop.
I worked in a sales driven startup some years ago and got to shape the technology as the first hire and only developer for a few months. I chose React because it was easier to recruit for and time to market was important. If I had already a team of developers with experience with another framework, I would have chosen that one even if it had been a less popular framework due. Time to market was our main focus.
More established companies don't have the same time constraints and are often more concerned about scaling up with multiple teams. A less popular framework is a bigger risk. It is "easy" to hire 10 people for any framework, but what about 100?
Vue? Lol. I've been using Vue full-time in multiple large corporate code bases for the past 3½ years and I'd exchange it for React in a heartbeat. Its type checker and build toolchain are so abysmally bad and bug-riddled that I run into new bugs and limitations on the daily. …which is no surprise really if you introduce a new custom file format and make type checking an afterthought.
Meanwhile, React is basically pure TS and the only bugs I run into are the occasional limitations of TSC.
>Its type checker and build toolchain are so abysmally bad and bug-riddled that I run into new bugs and limitations on the daily.
This seems like a setup issue.
Mine catches everything just fine. Both in-editor (I use neovim) and with a make step (just calls vue-tsc) + a precommit hook as a sanity check.
>React is basically pure TS and the only bugs I run into are the occasional limitations of TSC.
React is obscene. It always seemed to me the Java of the FE world, made worse in recent years. By that I mean grotesquely verbose and full of ceremonious value passing through multiple functions just for the tiniest of things. I've had to work with React codebases and these days I outright refuse to do that/turn down jobs with that requirement. I'd rather use angular.
Svelte and Vue are ergonomic and straightforward and they sanely default to SFCs instead of that woeful chimera of languages called JSX/TSX - you can still use it if you so desire though.
The cost of providing free ice-cream to WPengine is $218,685 or 7.9% of wordpress.org total income! ($2,768,057). But if the people eating up all the ice-cream you give them for free take you to court.... then you gotta cut off that ice-cream. WPengine should apologise and starting slinging cash to Automattic.
WordCamp expenditures: $2,159,747 (82.81% of total expenses)
Meetup expenditures: $229,571 (8.80% of total expenses)
Total Meetup.com dues: $224,249
Total Meetup Venue rental & exp: $5,322
Operations: $218,685 (8.39% of total expenses) <------ HOSTING PLUGINS/THEMES ETC
To me, the best feature is Relay Fragments (I think Apollo has fragments too?), as each component describes the data they need: no need to do a big top-level request then pass down the data to the responsible components, everything is in one file.
It makes UI changes much much easier to deal with.
I'm a huge fan of this. Apollo doesn't have it baked in as a pattern like Relay does afaik, but I do something similar manually in Apollo, inspired by Relay.
Deleting code automatically removes its data dependencies from the root query, it's ideal.
I mean technically in relay you need a parent component to make the query for the child components, and pass a reference to those children. There's still a parent/child relationship that needs to be maintained.
Lots of valid points about the increase in complexity for React over the years, and that one should pick another more modern tech stack (Svelte, Solid, html, whatever), and I used to be thinking like that
But since maybe 1-2 years, I am back and betting on React for most of my serious projects (for the ecosystem, the ease of hiring, etc), but the most important point is the following:
React backwards compatibility is really good, and will stay so for a good reason: a LOT of Meta’s UI code is using old features (classes syntax etc), and Meta cannot afford to break those. If there are breaking changes, they must be “codemodable” (so, usable by everyone).
Meaning in terms of stability, I know my codebase today will still work fine in years ( or upgrade-able with minimal efforts). Of course there will be new shiny features, but I or my team will not have to rewrite old code all the time following tedious migration guides.
disclaimer: I am kind of biased as I work at Meta, but far from React.
The person you're replying to did not say that, you're arguing against a straw man. Looking at the manual, upgrading to 18 seems straightforward, matching the "minimal efforts" they mentioned: https://react.dev/blog/2022/03/08/react-18-upgrade-guide
Arguing isn't the correct word for that. I did express incredulity when asking for clarification.
The person I was replying to did minimize the effort involved in upgrades by enclosing it in parentheses.
The incredulity is based on experience. Sure you can follow the upgrade guide, and if you work at Meta there are many people that know about weird edge cases. If you don't work at Meta, then you may be spending time chasing down bugs in production on your own. That gets expensive.
I am currently working on porting Museeks [0] from Electron to Tauri 2.0, mainly to reduce the memory and app size footprints, which are the main things everybody complains about with Electron.
What I really like:
- the dev experience is stellar and comes out of the box. No need to setup binary compilation, webpack, vite, hot-reload, TS compilation for back-end, etc yourself. You can pick your favorite JS framework with Vite, during setup, or use a Rust frontend (kind of what electron-forge is doing, but it is buggy, and landed yeaaaars after Electron was released).
- the architecture makes sense (commands, security, plugins, all very well-designed)
- they provide official plugins for common-usecases (SQL, config, etc)
- Rust is fun and interesting to learn for folks like me used to high-level languages like JS or Python
What I don't like as much:
- facing webview-specific UI issues (feature X does not work on Safari, Y not on gtk-webview etc), with Electron, you know if X works on Windows, it will work on Linux or MacOS
- some rough edges with the framework or the ecosystem (not as mature or dev-friendly as npm's or Electron), but the crates (and Tauri's) maintainers are very friendly and reactive.
- the focus on mobile apps, It seems like a very different space, and it feels weird to try to build with big mashup framework. I would rather have them work on more integrations, but whatever.
- changes in the Rust backend can take minutes to compile, and rust-analyzer is damn slow.
Overall I'm really happy and having a lot of fun. I will keep working on this port and release it when I can. Kudos to the Tauri team, what you are building is awesome :)
Been using it in production for over 2y, expect a lot of complaint from Linux user. Webkitgtk is really behind in terms of performance, standard support, etc. And it is not on MDN compatibility list so good luck finding what is available. It is to the point where we marked it as experimental for our users and considered switching to electron (we didnt yet).
Also you can expect hard to reproduce bugs on X version of Y OS that are not reproducable anywhere else. It's a PITA to maintain even for people used to the pain of cross browser problems. Just yesterday I got a user on macos 12 reporting not being able to write in some input fields, no error in the console. Now I need to figure out how to have a VM of that macos version with the specific patch for the webview version to match to reproduce, nightmares I tell you.
Otherwise it is decent and we are a rust shop so it makes sense for us. But IMO it is impossible they will gain any market traction in bigger businesses until we have standard webview packaged into the binaries like electron.
Thank you very much for sharing your experience. I am developing on macOS so I have yet to face the Linux issues, but I have already faced a few issues on macOS, that require editing some plists file (switching media outputs for example), which made me "sigh" a couple of times.
In Electron, I got my fair share of Linux issues, but nothing critical (tray appearing twice, this kind of things).
This is the Electron paradox: this is the best platform to develop cross-platform apps, because it just works. Yet people hate it (for valid reasons).
I feel like I've seen mention of them looking at Servo long term - but don't quote me and please someone correct me if I'm wrong.
WebkitGTK being so lackluster is indeed a problem - I ran into this of all things in a wxWidgets project. Eventually wound up ripping it out and replacing it with custom screens since it was more work to maintain and work around issues than to just sit down and write the UI.
> changes in the Rust backend can take minutes to compile, and rust-analyzer is damn slow.
Do you find that if you run cargo build, then trigger RA - without even making any changes - then run cargo build again, it recompiles a bunch of dependencies?
If so, you might find that pinning anyhow to =1.0.77 fixes this! There's a bug somewhere in the interaction between RA, cargo and some crates including afaict mostly dtolnay's which leads to RA runs causing the crate build script to think that RUSTC_BOOTSTRAP is set and they should invalidate the fingerprint and recompile.
Perhaps totally unrelated :) but I ask because I just spent days chasing this down only to find, once in the possession of the important keywords, that some helpful fellow had already filed a PR with rust-analyzer that purports to fix it and so my efforts were probably pointless. But if I can save some random guy a few minutes of compile time before the fix is released then it's worth it, right?
> mainly to reduce the memory and app size footprints, which are the main things everybody complains about with Electron
Those are annoyances. But the way an app feels and behaves is the main culprit IMHO. I'd rather have a heavy app that looks and feels native than the other way around.
I don't know about museeks tho. Never tried it. But best of luck with the port in any case!
