HN user
Used to be @KeitIG.
JS developer, maker of Museeks. Stupid and arrogant french in my spare time.
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.
I mean, I hate business as much as any other engineer, but what’s the point of software without a business? (excl. the beauty of open source)
TBH, all of what’s in this release came from previous 1.1.x patches.
It seems they just drafted a new release to communicate the groups of change from the previous releases.
That the whole industry embraced. Not bad for a piece of trash.
Well, it definitely becomes harder when you cannot (officially) access any of the WP infra, including themes and plugins.
That is exactly what Meta acknowledged, and this is not a product that is going to be released to the public anyway.
As a non-native English speaker, I may be one the few finding this addition really useful to correct syntax and spelling mistakes.
I am not 100% sure to understand the hostility towards such a feature, that seems accessible only via a user-action.
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).
@Sytten mentionned many issues with WebkitGTK, do you share the sentiment?
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 :)
Graphite is a code review tool (to organize PRs in stacked diffs), their data probably comes from their userbase, not just their internal team.
How is that an actual _fundamental_ problem?
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
cheers, and happy coding!
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.
Rome (written in Rust) is trying to be a faster tsc (amongst other things, like a faster webpack, babel, prettier, etc)
Secondary call-to-action is literally "Learn more" [0] and explains in details all the problems it solves
Until a blind person contacts your support team to tell them your website/webapp is not working with their screen reader.
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).
Can we change the HN title to the actual title of the article? "‘Kill more’: Facebook fails to detect hate against Rohingya".
It is explained in the second sentence:
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).
While I understand the concern, I'm not really sure I buy the argument "JS makes accessibility bad".
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.
That's true if you create your own bundle yourself. Famous frameworks like Next.js or Nuxt make much smarter bundles, with common dependencies grouped together, and bundling the rest by page/view, then loading each bundle when needed.
microSD none, but SDCard readers (the one here) are extremely useful to photographers.
I was talking about the M1 package. The 13' MacBook Pro can get crazy loud as well. But yeah, the XPS 15 is an excellent alternative to the MacBook Pro 16!
Can you put all that in a 13.3 inches chassis, make barely no noise when compiling hundred of thousand LoCs and reach 20 hours battery life on standard use?
Let's compare apples to apples.
In terms of reduced friction, I'm a big fan of the swiss transport system: you can hop in any bus or train without validating your ticket anywhere, and you get controlled from time to time. And the fine are big.
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
Where to start? A wild guess:
- 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.
Counter-opinion here: I am the maintainer of one of the most popular plugin for Next.js, and I am cruelly lacking data about how the users of my plugin use it, that would allow me to choose better defaults for it.
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_