A Fistful of Megabytes (In defense of Electron)

[@SADDE]

"if you're an english speaker with working fingers, working ears, and eyes, most of the system is invisible to you" that quote goes hard

[@comradestinger]

The part where you talk about text rendering was very relatable. Recently wrote a TTF reader / font renderer from scratch in C. I went in knowing it was going to be complicated, but oh my god I was not prepared.

[@gfasterOS]

This is exactly why I believe that while your chat app front end should absolutely be a web app, you should also open the API so weirdos like me can build their own CLI clients. Obviously that’s not quite so simple either, but I do wish that Discord wouldn’t ban you for trying.

[@fasterthanlime]

We're in agreement there! The Discord situation is unfortunate.

[@claritise]

yes but that sweet sweet advertising revenue...

[@vaap]

i agree, and also specifically about discord btw: their method of verifying client requests (user agent hearders + x-super-properties) hasnt changed in years so it's relatively safe to make your own client these days, but sadly the safety isnt guaranteed to work forever

[@sidma6488]

...or build Native GUIs around the API.

[@6XeNoN9]

"Get fast quick scheme" 🤣

[@ゾカリクゾ]

Conclusion: Browser developers are a different breed

[@boscovallejo-nagera6073]

I'm not mad when a chat app uses electron for their client, I'm mad when they go out of their way to block 3rd party clients

[@stok3si3]

I'm really, really happy to see someone taking a rational position on this rather than the uncharitable 5-second analysis you see all over reddit/hackernews/twitterverse - and it doesn't surprise me at all that it's coming from you. I'm a big fan, and glad to see a kindred spirit out there whose viewpoint isn't driven by outrage but rather curiosity and consideration. Thanks for making these videos and for the awesome write ups.

[@saintpyo]

I'm currently on a little rabbit hole stroll after discovering this channel, amazing work, great video!

[@hashtag9990]

This is why I don't write cross platform apps, I just ship windows along with my app in a VM.

[@MatheusOliveira-er4gq]

I saw myself (my first job) complaining about frameworks my company uses, my question is why we dont make it ourselves? Now, I know.

[@ISSOtm]

I completely agree with the points you brought up about system complexity, but I'm pretty sure that browsers aren't the right solution either: using them for this purpose means that they've gotten incredibly complex, to the point that they're basically OSes now (and I'm not talking about Chrome OS, though there may be a point to be made). What I really don't like about that isn't the performance loss (which I do hate regardless, as I have to close Firefox whenever I'm forced to fire up VS Code or Discord) as much that we're trading legacy for legacy-JS *sucks*, CSS rules are incredibly complicated, etc-and I fear where this is taking us. Bonus chatter: why do we bother having an underlying OS if we're gonna end up running everything in a browser anyway? Browsers can run OSes too now (cf. that W98 WASM demo, for example), so we could probably flip the paradigm on its head: start in the browser, emulate the old-fashioned OSes within it.

[@alichay]

Of course browsers aren't the *right* solution - at least in like, a philosophical sense. But practically, someone has to *make* an alternative, and there's no money in that when you can reuse existing browser infrastructure (infrastructure which has a massive financial incentive to maintain) to ship your applications instead. I foresee something coming along to replace electron, but it would probably just be a browser engine with the legacy junk ripped out. But that's just a pet theory, we'll see :)

[@zyansheep]

@@alichay (cough cough, *tauri* cough cough)

[@alichay]

@@zyansheep tauri is definitely an exciting step in the right direction, but I was more picturing something like raw webrender with a ui library strapped to it

[@samsu9678]

Then you are emulating emacs?

[@CharleyWright-w1y]

@@alichay What about CEF? It's certainly still got bloat, but If you compare Spotify's memory usage with Discord, it's not even close

[@meowmeowmeowmeowmeowmeowmeowml]

Telegram's desktop is written in Qt and it looks amazing. If only more people used it

[@fasterthanlime]

I love Telegram apps on both desktop and mobile - my understanding is that they have a lot of custom stuff (and their own trimmed down build of Qt). Basically it's not as easy as "just using Qt".

[@meowmeowmeowmeowmeowmeowmeowml]

@@fasterthanlime As far as I'm aware, their changes to Qt are relatively minimal. They do require a lot of third party libraries, but I think that's the case for most desktop apps anyway. Qt especially has so many built-in things that are useful and solve most of the issues mentioned TMK, but even so can be trimmed down or upx'd if unneeded, which is harder to do in Electron apps.

[@trejkaz]

Back when I was still very active on XMPP, I used to use Psi, which was also written in pure Qt. It was the best looking client at the time.

[@baggern]

ok ok ok ok ok, but instead of every application shipping their own browser, they could mostly just be a (progressive) webapp. Also most website are incredibly bloaty

[@fasterthanlime]

I'm with you on progressive web apps! Although ad a user I still don't interact with those the way I do "desktop apps", I'm not exactly sure what's missing, but there's still a rift there imho.

[@andreapivetta]

use chrome os for a while to realize how much you don't need native clients 😅

[@pablosanfilippo4781]

The other option is using the system native webview like tauri does

[@PeidosFTW]

didnt firefox stop supporting pwas?

[@6XeNoN9]

I *love* all the things that come baked in the browser that smarter people have made already figured out for me, but oh god do I HATE having to use the ill-fitted HTTP+HTML/CSS/JS formalism for desktop GUI app work

[@soniablanche5672]

Know what browser also have? A Gamepad Web Api. You don't need to worry about finding a library for that lmao.

[@alexandermendez9013]

Ok so I made an os in electron

[@keokawasaki7833]

Let's get terminals to browser level engineering

[@myronkipa2530]

tauri is new electron

[@georgecoldwell6792]

I don't get this. Yes, font rendering is hard, text input is hard, encryption is hard, and there are many, many more things that I absolutely would not want to do myself, but these are not something that I would have to do anyway. Pretty much every UI library/framework in existence does these for you, some of them even in a multiplatform manner (Qt). I totally get that people love HTML/CSS/JS, but I do not think that it's because they do not have to do font rendering themselves with them.

[@RemcoJvGrevenbroek]

Next up...dates and timezones

[@fasterthanlime]

Woof, I really need to do that one, don't I.

[@RemcoJvGrevenbroek]

@@fasterthanlime yes you should. Haha

[@trejkaz]

@@fasterthanlime Beware, if you do that one, there will be people out there watching it like a hawk for all the edge cases they have dealt with that you don't cover. LOL

[@rika-chan]

Am I crazy or are there tons of audio pops throughout this whole video? 1:20 2:34 3:11 3:25 etc

[@bitbraindev]

I really appreciate your perspective on this. I have to admit I was one of those people shouting at Electron but it really solves a lot of problems!

[@cad97]

I wonder where the line between dynamic and static linking should be... I'm not a fan of system-wide dynamic linking in the "everyone uses the same version of every library" manner, because that's DLL hell at best (plus application specific patches, etc). But at the same time... to me it makes more sense to treat the browser as a platform, and use the OS browser rather than shipping your own outdated copy of chromium... for the exact same reasons advocated for dynamic linking. There's a point at which it makes sense to dynamically use the system provider rather than bundle and statically link your own copy. And somehow, my current position is that rustc bundling LLVM is fine and good, but (insert electron app) bundling chromium is suboptimal. What is the differentiator? Is it scale? Is it the latency of end user updates of the provided service? How integrated into the OS services it is? (When OSes are actively debundling historically bundled services to be updated in userland?) I honestly don't know. But static versus dynamic linking sounds like it could be a good topic for another rant (series)!

[@cad97]

For a cross-platform application Dynamically use the system: - Browser functionality - Native WASM/WASI engine - GPU interface (WGPU/Vulkan portability?) Statically bundle: - Everything else? That's the best I have right now, though I lack confidence in the reasoning behind the cutoff, beyond "web as a platform."

[@alexchichigin]

Where's another like button?! I'm in dire need of more likes for this video!!! It's so much better than I expected, a real joy. :D

[@TheBuzzSaw]

But most Electron apps close off 80% of what you're describing. The devs do not test foreign language glyphs. The web dev tools are always disabled. So, basically, Electron apps are all super heavy all while preventing me from gaining all the benefits browsers supposedly offer. As other commenters have mentioned, I'd be happier with most Electron apps just being PWAs. Also, this is a much deeper discussion, but... HTML/CSS/JS are most of the problem too. The problem with these DSLs is that that they are woefully under-specified and non-deterministic by design. That means there is no way to fully optimize them. The closest we can get is "well, we see this pattern a lot, so we'll watch for that and use a code path shortcut". From there, I keep running into bugs that boil down to "it's a bug in Electron". Well, I can't update your Electron. If it were a PWA, it'd be cake, but I have to hope/wait on the devs. The only good part about Electron is, like you said, the strong consistency it offers across operating systems. However, this bloat is outpacing hardware developments. Computers and apps were measurably simpler and faster in years past. "But modern apps do more!" Nah, not really. Just look at the history of Photoshop or Visual Studio over the years. They do WAY more than most apps and stayed fast until recent years. I'm glad developers can build things quickly today, but the pendulum has swung too far, and we need to rethink some things. Thanks for reading.

[@a_commenter]

tbf, the web dev tools being disabled is mostly for users, and the devs can still take advantage of them, which I think was the point.

[@oliveiracaio57]

VERY nice video, Amos.

[@sodiumsalt]

When you want to prepare a dish, you don't start at the farm planting seeds, you pay for gas and go to a mall.

[@casperes0912]

Proteus sounds there at the end.

[@Vagelis_Prokopiou]

Valid points, unfortunately :-)

[@zahash1045]

This video just made me love browsers

[@fasterthanlime]

Well let's not go overboard now

[@zahash1045]

@ imma make sweet love to chrome

[@kh0kh0]

I am sad that I have to agree with you :)

[@dmitriid]

Why does an app that renders text and images needs to also ship: an implementation for USB and Bluetooth, XML and XSLT, 50 debug tools, 4 different client-side storage implementations (cookies, localStorage, IndexDB and Origin Filesystem), a full FTP support (until a few years back) and god knows what else? Actual proper software doesn't include what it doesn't need. With Electron you get half of an OS shipped even if all you do is show pictures of cats

[@sheikhspeare6637]

I was looking for this video for so long but couldn't remember the title / channel name. Finally found it because your account popped up on my Github homepage. Consider adding / mentioning Electron in the title maybe?

[@fasterthanlime]

Just added "(In defense of Electron)" in the title for future reference!

[@blarghblargh]

okay so what if we agree with you that browsers are fine and that we need a ton of stuff to support all users. we still haven't conceded that html + js + css is the best way to define application UIs. they're quite poor at application layout.

[@tomontheinternet]

Great video. Thank you

[@cotneit]

Is that a Fistful of Frags reference? xd

[@Necriptos]

Hey man, great video, first time hearing you in English you are awesome haha, I completely agree with what you said, it kinda reminds me of the same thing happening with games made with "easy" engines like Unity, people are always eager to berate the engine even though some really great games have been made on it but people only seem to think of the "bad unity games".

[@nilshaberstroh2705]

Ranting is fine when it's entertaining™ (also: very valid points imo)

[@sachindraragul1094]

How is flutter doing that now? I'm a noob in this area.

[@trejkaz]

Flutter is similar to Jetpack Compose is it not? Built on Skia, but you write the app in Dart instead of Kotlin. Both of them also heavily use Material for the UI.

[@Aderic]

Electron does suck though. Besides the stupidly high amount of system resources, we still don't have Wayland support. They could've used smaller, well-written libraries to accomplish the task. It's not like it's a team of five developers that had to rely on an entire web engine. At the end of the day, it is still a chat program, they didn't need the entire kitchen sink. Your point basically boils down to "it's hard to write everything from scratch". You don't have to write everything from scratch, that's what libraries are for.

[@PeidosFTW]

lets just start using flutter then

[@mibdev]

eyo Æ isn't a ligerature; it's a letter, in some Scandinavian languages. I get that it's a great example, but how about the classic `ff` instead? ;)

[@PaulGrayUK]

Learned ages ago that it is the simplest things from a user's perspective that takes forever and it is from a user's perspective of things that will take a long time, that is the quickest. Fonts, lol, yip, has become a whole area of expertise until itself. Adding postcodes to addresses was the first simple thing that is a rabbit hole of exceptions. Simple. Well, not when the decades prior they had a free-form address field and yes, some had used that to include the postcode and more so, not all those were right. Addresses spelt wrong, which rings the old gardage, of - garbage in, garbage out. So that simple task, well, wasn't so. Then dates, oh gosh dates DD/MM/YY or YYYY or MM/DD/YY.... what fun, more so as need the year to and the month to validate the date. Then you encounter time and TZs and leap seconds and other wonderful gotchas that you learn from experience.

[@segsfault]

*doesn't apply to many applications out there*

[@jbca]

You have a KZbin channel?!

[@fasterthanlime]

It all happened so fast! But yes!

[@TheRealisticNihilist]

This is a good argument.

[@soniablanche5672]

I think most people use electron because they already know HTML+CSS and don't want to learn a new GUI library.

[@trejkaz]

That hits the nail on the head. This whole situation is happening because "native" (for want of a better word) GUI developers are becoming harder to find, and the web developers which the company already hired are being pressed to make GUI applications.

[@herkulessi]

Honestly, just write the dang thing in HTML+CSS+JS, but then RUN IT IN THE BROWSER! that way the browser can do magic stuff to improve performance or save ram or whatever, and at the same time you save so much resources by not loading a new copy of the browser for every electron app. And let's not talk about the electron version most things are built against (hint: ancient)!

[@DarrienGlasser]

What if I like being angry 😌

[@zxnnightstalker2289]

only C & C++ programmer knows that.

[@noxabellus]

It's not about memory to me, in the slightest. 300mb electron is a small price to pay for all of that, as was said here. However, in the best case performance-wise you're running inside a wasm vm integrated into a javascript runtime inside a browser inside the os. Every time you want to actually interact with the outside world from your program's business logic you have to reach across all of those layers and crossing each layer boundary has a huge cost. Just doing simple opengl draw calls from wasm requires you to translate all your wasm data into javascript objects then translate all of those back into native code to send to opengl. Things like WASI and WGPU are definitely a better path forward: Take the more-universally useful components discussed here out of the browsers and abstract them into reusable apis with a shared abi specification that is retargetable by design.

[@mzg147]

Amazing video, I thought people hate on Electron because they hate on Javascript, at least I do it 😅 One file of js to bootstrap wasm is just fine :)

[@mbirth]

I’m sorry but most of the things you mentioned are things the operating system can and should handle for an app to feel “native”. Using this as an excuse for Electron is just lazy. There’s only one reason to use Electron, but it’s not a reason for end users: It’s cheap. Everyone and their dog can do JavaScript nowadays, so JS developers are cheap. And using the one-size-fits-all (i.e. one app for all platforms) approach means you don’t need to care about OS specifics. But for the end user this results in a degraded experience. It doesn’t matter how hard an Electron app tries to appear as an actual app, it will always feel a bit off compared to actually native apps. Because it’s a website in an encapsulated browser.

[@alexchichigin]

It's so wrong on so many levels, it's just lovely! :) > the operating system can and should handle for an app But _does_ it? Do all of them do this things _the same way_? LOL, nope. :D > so JS developers are cheap They aren't really but even if... Paying more than strictly necessary to people is a good and noble thing, but I can't see the point in hiring more expensive developers for the sake of having more expensive developers. Or do you mean we should hire more C/C++ developers to have longer development times, longer debugging sessions, more segfaults and more security holes? ;) > you don’t need to care about OS specifics LOL, it's so funny I don't even have anything to say... :D But you have my respect regardless. Stay brave, keep learning! :)

[@----__---]

@@alexchichigin People should hire more C++ developers for quality software, not for a quickly hacked-up slow javascript code.

[@alexchichigin]

@@----__--- well as long as your definition of "quality" does not include security, robustness, absence of memory bugs, etc... Yeah, sure! 😄

[@----__---]

@@alexchichigin Yeah because javascript is definitely the most "secure" language lmao

[@alexchichigin]

@@----__--- among JS, C++ and PHP? I bet it is. 🤷

[@jeremysaklad6703]

I think Electron programs should stop pretending to be native programs and actually just be websites. If you don’t want to do the work, just… don’t. Saying you support a platform is a promise, and you shouldn’t bite off more than you can chew. If you want to have a dedicated app, it should feel like a dedicated app. That’s certainly hell on Windows, and there’s obviously the potential for choice paralysis on Linux (though seriously, do you really need to attempt supporting *every* distro at once?), but on macOS this isn’t exactly rocket science. And those UI frameworks and such? They *are* lighter than a browser. The browser probably uses them. There is a reason everyone loves iOS apps, and it’s quite simple: Apple strong-arms people into meeting a certain level of quality, and it is usually easier to go along with it than escape the notice of their reviewers.

[@SimonBuchanNz]

Web apps are great, but how do you write a background service configuration ui? Or an installer? Or a game launcher? Or anything else that would need weird and dangerous permissions. Heck, can you even launch on startup? Sometimes its as simple as you're not allowed internet access. And no, browsers largely reimplement all the native controls (unless you're safari and only run on one platform). Because they need to behave the same on all platforms (in terms of integration with input, display etc) and they need to support what html requires eg styling, containing images, other controls. And because css and js are so powerful now, it's actually just easier to implement each platform's style than to integrate the actual controls one you're already implementing all the text rendering, layout etc logic you need for html.

[@ivanhbxyz]

this is poetry.

[@0x2a1A4]

tauri.. :D

[@joaoalves1359]

Remove LLVM and GNU Binutils and see what happens it the world

[@goawqebt6931]

Not convinced

[@abzq5769]

refterm lol

[@CallousCoder]

Then still the argument holds because Amiga and ST with their tiny 68000 did do this. And even lame ass 386 with Windows. Okay not as nice but still with moderate memory usage. There’s no reason for frontend UIs to hog 300MB and about 5 old 486CPUs. As we know because most operating systems implement everything as well and use as much (or less memory). I recently installed Reaper daw a tiny 128MB executable a RSS clean start of about 180MB. But I’ll raise the argument that developers and CTOs are lazy or inexperienced further by pointing to the hell that has become the back end. All those idiotic microservice APIs that do hardly anything that are written in shitty runtimes like NodeJS, Spring Boot, Flask and for a simple date service or fetch name service consume at least 90MB RSS! That’s just stupid! I ran a bloody file server with 100+ clients where clients booted from the file server on a whopping 64MB! Which was a lot in 1995 when the average file server ran 16-32MB. In my first job we wrote software on an interpreted system (MUMPS) too because those developers weren’t CS majors either. But we served with nice ASCII terminals from 1-128 users concurrently. The system booted already on 1MB and could server 8 people. Because MUMPS was clever, every user had 1K of program space. It was time sliced, and the program was written in single character instructions. So you could have a whopping 1024K of instructions on memory. And I tell you that a veterinary or medial management system is very complex. But by clever loading parts when needed we never ran into resource issues. And the biggest database from one client was 200MB after 6 or 7 years of daily use. My dad build ball bearing monitor system back in 1982 for bespoke ball bearings, and only had 256KB of memory at his disposal (and that was massive at the time!) and that system had to run for 7 years controlling the forces on the bearings 24x7 because you couldn’t get into the challenge tunnel and pull out the TBM and dismantle it to get to the main drive shaft bearing. Something happened both in education, and mind set that we just don’t care about excellence and usability anymore. Just quick gains and quick to market schemes, and rewrite after rewrite after rewrite (especially for web crap). I can work just as well on an old kernel with 90% of my tasks as I could in 1995. The work hasn’t changed the tools have changed but the tools spent speed up. More memory more cpu cycles and not equivalent speed up - for most things, video is absolutely great! But when you look at Davinci memory footprint and what it does (especially on RAW files is amazing). And on average within data just as much memory usage as the web crap front ends! But that actually does something, and they pride themselves in offloading to GPUs speeding up and reducing memory footprint. Most developers these days don’t even know how the garbage collector on their crappy interpreted language works. They keep allocating and dropping the reference and then we the end user of confronted with a sudden freezing experience and blowing fans because the GC is stressing out. And for the sake of all that’s holy, stop using HTTP for stupid little requests! There’s far better more lightweight and reliable solutions like MQTT for that! There’s a reason why we don’t use http in ToI!

[@thebrowhodoesntlift9613]

I mean... Yeah but Tauri is cooler.

[@IngrownMink4]

I couldn't disagree more with the video. Electron is a horrible technology, and one of the reasons why web pages today tend to work properly only in Chromium-based browsers, and facilitate Google's monopoly on being able to dictate its own rules. Electron, as you rightly mention, facilitates and democratizes the use of many advanced functions that would be difficult to implement with the libraries of an OS, so far I agree. But you forget to mention that each app written in Electron has its own instance, that is, each one uses a DIFFERENT embedded Chromium engine. If you have Spotify, Discord, Slack and the Xbox app open, you are literally using 4 non-optimized instances of the same technology. And my question is, why don't they share the same web engine? That's when I think you should talk about Tauri. Tauri has a smarter approach, because it uses the OS WebView in order to render the content, and thus uses the computer resources efficiently. Because although you don't mention it in the video, Electron wastes a lot of CPU cycles in the background, spends a lot of energy irresponsibly, and doesn't integrate properly wherever it runs. And I agree that many web APIs work better than their native OS counterpart. But that doesn't mean Electron is the ideal choice for building apps. In fact, it's the worst possible and least user-friendly option. You say that in Windows there are too many frameworks and a developer probably doesn't know which one to use. It's a reasonable argument, but it's funny that you use that pretext to push the use of Electron. Wouldn't it be fairer to require Microsoft to go with an official framework, instead of just using Electron for anything? And with Linux, you're lying, there are agnostic frameworks. Apart from this, Electron is very difficult to optimize. It supports too many unnecessary things that, even if you try to deny it, have a very negative impact, especially for users with low-resource PCs. This also has an impact on the size of the program. 500MB may be reasonable for a complex program, but it is unacceptable for simple apps, especially considering that if every developer opted for Electron, the average user would have 1GB occupied by only 2 applications. If you think 1GB is not enough, I remind you that Crash Bandicoot weighs 429MB, so you can't defend that a calculator in Electron weighs more than a videogame. I just hope you don't have to use an app written in Electron on a less powerful device.

[@andrewdunbar828]

Everybody complains about Electron apps but nobody, nobody, nobody (almost nobody) writes native apps for Mac...

[@trejkaz]

I've done it but only for a situation where it had to embed into the System Preferences app...

[@SirLancelotS]

Electron is trash and will always be, I don't want no damn wep app. Give me a native desktop app.

[@dealloc]

Build one then; try and recreate an existing web app and re-implement it feature by feature, with accessibility, security, UX, cross-platform, distribution and everything in between. Then come back and tell me how it went and how many bug reports you ended up with in which areas.

[@danny-jo1rb]

@@dealloc which is exactly why these multi billion dollar companies have hundreds of developers to help with that. most of them are just lazy

[@trejkaz]

Judging from my experience over the past 8 months, most web developers wouldn't know UX if it came up and slapped them in the face. If you think I'm wrong, try making a simple registration form for a web site which takes the user's name, or perhaps a shipping details form which takes their name and address. I can _almost guarantee_ that you will fuck it up. Why? Because everyone out there seems to fuck it up. Even companies like Shopify, who have been doing it for so long, are fucking it up.

[@User-md3ul]

Though that raises the question why you're coding in rust at all ? Fast prototyping ? All-encompassing ecosystem ? Working natively in any browser ? Nothing of that can rust provide. (No webasm doesn't count.)

[@otak_]

It...doesn't? Why would you need fast prototyping if your work focuses on the "invisible" part of systems? Why would an all-encompassing ecosystem exist if you're actively involved into building that said ecosystem? Why would you need something that works in any browser if you're not actually targeting browsers? I'm just saying, that everyone's work fields are different and what *you* need probably is very different from others' needs. As a side note: WASM very much counts. If you're using any kind of E2EE messenger (Signal, WhatsApp among others) you're actually running Rust compiled to WASM running in Electron/your web browser of choice :)

[@LarsDonner]

This video is so full of inaccuracies, it's not even funny. The difficulty of rendering text is completely blown out of proportion (and hey, Windows is in the process of removing subpixel rendering from its UI because it completely breaks in all but the simplest black-on-white cases). Text input is "solved" by the operating system and only requires extra work if you want to be fancy and integrate the IME textbox with your own. Giving up on sending binary data, just to re-use the browsers encryption is insane.

[@fasterthanlime]

Thanks for summarizing the thesis of the video: when you don't care / have to do it yourself / pay attention to the details everything appears easy. Claiming that browsers "can't send binary data" (I'm assuming you mean: from user code) is also hilarious and possibly a couple decades outdated. But thanks for watching!

[@TheHellst0rm]

@@fasterthanlime I agree with some parts of the video, but especially the point you are making about input mode editors is not correct. Afaik IMEs for Japanese or Chinese are like over 30 years old. Take a look at when the XIM specification for the x server was written. Granted, Linux IME input is just bad, but that's more of a problem of Linux desktop environment. With native apps, you get really nice text inputs with IME support which the browser does not even support. There is a Javascript IME API proposal, which... no browser seems to support. On native apps, you can nicely interface with the IME. And every input field of each major toolkit just supports IMEs. Of course, if you handle keystrokes yourself (like some games might do), you won't get IME support. But that's just stupid, who would do that?

[@trejkaz]

@@TheHellst0rm speaking of IMEs, Windows' is pretty terrible as well. There's an open feature request to make WinCompose properly show the composition in the IME as it's being input, but apparently it's so hard that nobody can figure out how to actually make it work. At the moment, you hit the Compose key, and nothing appears. Then you type "*" and nothing appears. Then you type "u" and "θ" suddenly appears. (Also the answer to your last question is - Minecraft. Or, I suppose, more accurately, LWJGL. But that's why we still get no good IME for Japanese in that game.)