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.
566 karma · joined October 9, 2018
JS developer, maker of Museeks. Stupid and arrogant french in my spare time.
It seems they just drafted a new release to communicate the groups of change from the previous releases.
I am not 100% sure to understand the hostility towards such a feature, that seems accessible only via a user-action.
It makes UI changes much much easier to deal with.
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.
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).
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)
- 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
cheers, and happy coding!
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).
> updates, telemetry, certificate management, crash reporting and other similar functionality
We can discuss about the importance of telemetry, but the others seem quite important to me.
The key is just to gracefully fail when something goes wrong (and there it didn't).
It is for sure easier to do things wrong, but if you check at most of the major libraries for front-end (drag-and-drop, routing, dropdowns...), accessibility is built-in, and a critical selling point (e.g react-router, downshift...).
I think the proportion of front-end developers knowing about accessibility is just low, and the result is more visible for JS-heavy websites/webapps, but this is imho an education problem, not an ecosystem issue.
Having worked in agencies, accessibility was always treated as a second-class citizen (by clients or managers, not by developers, trying to push for it), and clients would often say "let's go live without it", then would come back to us asking to finish the job once they saw their competitors got sued for having an inaccessible website.
So JS may be a catalyst, but not the root of the problem. It's our job to push for the importance of it, as we pushed for responsive websites a while ago.
Let's compare apples to apples.
So you get:
- not much friction (+ the app is great)
- you use transports more -> you pay more (and not everyone)
- fraud is low because the fines are big enough to dissuade people, and increase every time you get caught
- A/B testing capabilities
- Different features per country/region
- Different payment methods per country
- ...
I mean it's like e-commerce, when you stay in a single country, things are easy. When you go international, wild sh*t happens to cover all the spectrum of scenarios and respect the laws in place, while keeping it simple enough to maintain for devs.
I don't have access to the Next.js telemetry data, but I could definitely need to ask the Next.js team from time to time: "so, are your users more using Yarn workspaces? Or npm link? Or something else?", etc.
For the same reasons some people complains about Ubuntu removing some features because they say "people don't use it", while people using those features tend to disable the telemetry. Sometimes, telemetry is useful.
It is not to spy on users, it is about making the best technical choices to ensure the best Developer Experience.
_edit: typos_