Look very nice, I may end up using for https://museeks.io, gapless playback has been on the roadmap for a while, but WebAudio APIs have always been super cryptic, a higher-level API is very much welcome.
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.
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.
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 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 :)
The world has embraced hooks, for better or worse. The fact is React still works well, and the React team has always been clear that performance is (somewhat) an implementation details. For example, they often advertise to use inlined functions and to use `useCallback` only if you're facing performance issues.
So `useCallback` invalidation is definitely not "fundamental" (imho)
Creator of Museeks here, a little late for the party. There are many comments in this thread, and the usual electron-bashing we're all used to at this point, so I'll just make a few points:
- I know all the cons of using Electron, thank you
- I started writing this piece of software 8 years ago, for me, to learn horizontal software development (ui, db, releases, binaries, cd, testing, etc), at a time I dropped out from university and I had to learn stuff in order to find a job and pay my rent
- Nowadays, I still use this project to experiment with technologies I want to learn or play with
- I truly don't care you don't like it (the app, or electron itself), my only purpose is to share something solving a real problem for me, for free
- If this app is useful to only one person other than me, and angers the HN crowd, I'll still be happy about it, and it will still be worth the hundreds or thousand hours I put on this
Because the Quest 3 is another product, this is the pro version. The consumer version will get released later I guess, and probably with a price closer to the current Quest 2.
TypeScript has always been very explicit it's trading soundness for productivity. And don't assume "typescript people" only do TypeScript.
I've introduce TypeScript to multiple teams already, and if the transitions were not frictionless, they were always extremely fruitful in the end.
And I can guarantee using a more sound (and more complex) type system like Elm or Rust would have never succeeded, because people using high-level languages don't want to know about low-level CPU/memory details, they just need to build things and have something that is "fast-enough" (and safe-enough, if possible).