421–430 of 441 posts
Earlier quoted context omitted.
This is entirely feasible but what percentage of people can write replacements for problematic tools and what tools can they afford to replace time?
Among software engineers? I would expect (hope?) that the percentage that could do this approaches 100.
Earlier quoted context omitted.
Qt?
That won't really look native, will it? I thought Qt things looked like Qt things.
Earlier quoted context omitted.
As a user I think Electron is great. It means many more apps have a Mac version. Compare to games, where Electron typically isn’t feasible, and observe how many games don’t have a Mac version. A little extra memory usage is fine by me. I can understand how people disagree, and that’s fine, just don’t use Electron apps. No need to ban them from the platform.
Yes, this is the thing. The option isn't electron vs native, it's electron vs nothing.
As a user I am glad. As is custom for all Electron discussions, someone must point out its flaws. Why the dislike, you ask? A picture is worth a thousand 64-bit words: https://imgur.com/a/XnCOHUD And mind you, GitHub Desktop is taking that much just for showing a mostly empty window! while Fork and Tower are displaying a lot more UI, more controls, trees, custom drawing, more text, and have overall more features (bes…
>Why the dislike, you ask? Nobody is asking that, there's a crowd in here that restates the same three points about memory, performance and native UI about once a week. I dislike waste, I have written assembly code for tiny processors. And yet, I run several Electron apps on my 8gb 2013 Macbook Air and it runs fine, especially VSCode. I am picking that over my previous choice which was native (vim), because I think i…
Say a somewhat below-average user has 6GB of memory (I'm being generous here; plenty don't have more than 4GB). Today is a worse-than-usual day, and 4GB are taken by everything that isn't Electron because 40 tabs are open for a research paper due tomorrow. That leaves three gigs to spare. Now the user starts up some Electron apps.
- Music player? +400mb
- Note-taking? +300mb
- Messaging? +500mb (thanks, Slack!)
- News? +300mb
- Editor/IDE? +500mb
That's it. No more space. And that's before we even begin talking about what we're putting that dual-core CPU through. Battery life is a joke at this point.
A comparison: My OS, window manager, mail client, password manager, taskbar, music player (mpd+ncmpp+clerk.pl), file manager, system monitor, RSS reader, podcast player, IRC client, and editor/IDE (neovim+language servers with diagnostics, gotos, floating documentation, and refactoring all running) barely use over 1GB of memory, combined. Let that sink in. Essentially, a single electron app using 500mb of memory would increase my memory usage by 40%.
People shouldn't have to throw away/upgrade their computers every four years. I'm still rocking a 2013 HP Elitebook G1 with a Haswell i5 as my secondary machine. It runs just as well as my desktop for anything except heavy websites with JS enabled, compiling, and graphics-intensive work. I plan to either continue using it for another few years or donate it and switch to a more lightweight \$199 Pinebook Pro. Using less powerful hardware forces me to empathize with users who are using tech from the past rather than the future, because that's my job. I build tools for people besides myself to use.
If you must use the web, consider making your "app" start a local web server and launching the users' preferred browser for a more lightweight solution.
Earlier quoted context omitted.
Is that a joke? Surely you aren't suggesting that developers should have full knowledge of all transitive dependencies that compose their application stack.
as CTO I know all the dependencies in the application stack of our company and I require developers to have sufficient understanding of their purpose, licensing model etc. There are tools to simplify this task. It’s much harder to do for TypeScript than for Java, mostly because NPM ecosystem is a huge pile of junk, but it’s still important part of developer's job.
Earlier quoted context omitted.
Again you spend more time replying than reading. I said this internal API rejection situation of Apple not treating developers like partners Like it's literally right there in the comment you replied to clear as day and yet you manage to muck it up then spend several more paragraphs on a new screed nitpicking your wrongly quoted text. I'm done replying to this.
The internal API rejection is about not treating developers like “partners”. You aren’t their partner. Internal APIs are just that - for internal employees. It’s dumb to use “internal”, private APIs. It always has been. It hurts your products stability, it hurts your customers, and it keeps the platform vendor from making rapid changes. Microsoft never cared about you as a developer - they would just as easily run ov…
Microsoft has a history from the earliest days of existence of bending over for developers.
Going as far as to literally to add a special case to their memory allocator to support explicit undefined behavior (reading memory after free) for when a specific game, Sim City.
They avoided writing more than 80 characters on any given line in system.ini, because one specific program would fail to read those lines correctly, then delete the system.ini when attempting to write it back
Microsoft is literally still packaging 16-bit subsystems with Windows 10
Anyone actually interested in learning more about it should read Raymond Chen's blog and learn about the truly insane lengths Microsoft goes to make sure they don't break what developers have done, no matter how wrong it is:
https://devblogs.microsoft.com/oldnewthing/author/oldnewthin...
Honestly anyone who doesn't know the lengths Microsoft goes to treat developers as partners doesn't have the base knowledge for the conversation this thread has been about, but I digress.
Earlier quoted context omitted.
> Apple is at the height of their arrogance towards developers. Yep. I've migrated away from macOS after using it for a decade over to Linux, and the developer experience is first class.
is it possible to write a GUI app that looks native in all common desktop environments yet?
Earlier quoted context omitted.
Among software engineers? I would expect (hope?) that the percentage that could do this approaches 100.
How much extra time do you have to reimpliment things that work because you disagree with how they are written?
If devs can't do things like be able to tell what dependencies a module/library has, then they shouldn't use that module/library.
Putting it together: This is about submitting an app to the Mac App Store. Apple has had a requirement that apps not use private APIs for a while. It sounds like Chromium, and hence Electron have had references to some private APIs for a while, but Apple has only recently started enforcing their requirement. (Or perhaps only recently started scanning for these particular APIs.) It’s a little painful for the developer…
Earlier quoted context omitted.
Forgive me if I'm not understanding correctly, but in your description here it sounds like the problem is in how your organization functions around this, not in Apple's policies. It's not really fair to expect Apple to resolve or work around your own organizational problems.
Why not? Microsoft does it all the time. So does Google, to an extend. Apples inability to work with us is the primary reason we replaced thousands of iPads for school children with Chrome books. Eventually Apple caved to our needs, but it was way too late. Google were “what can we do to make this deal work for both of us?” from day one.
What I'm saying is that it's unfair to expect it. As in, if a company is not willing to bend over backwards for you, it's not fair to condemn them for that. It's totally fair to praise their competitors who will, though.