14 ms·
That blog post does speak to me, but 20MB for a program with a truly functional, modern UI doesn't outrage me that much. IMO there's a tradeoff: we could be wr
by afavour 6y ago
That blog post does speak to me, but 20MB for a program with a truly functional, modern UI doesn't outrage me that much.
IMO there's a tradeoff: we could be writing all our programs in C, still. But it would be enormously difficult and there'd be way more bugs. On the other end of the spectrum we can be lazy, use web tech everywhere and never optimise our ballooning JS codebases. This feels like it's at least somewhere in the middle.
OT but a bone to pick with that article:
> Modern text editors have higher latency than 42-year-old Emacs. Text editors! What can be simpler? On each keystroke, all you have to do is update a tiny rectangular region and modern text editors can’t do that in 16ms. It’s a lot of time. A LOT.
That isn't what my text editor is doing, though. It's doing autocomplete suggestions, linting code as I type... all sorts of things we never had a couple of decades ago and are huge productivity boosters. Sometimes I feel like people forget that.
- setr 6y agoHowever, most of that should be done in the background — it shouldn’t affect your actual text input speed. Auto-format is more along the lines of something that could be blocking, but we’re not dealing with latex problems as to be significant
- andylynch 6y agoEven putting that aside, just showing text on a screen is much slower on modern PCs then older ones, since you have a far more complicated graphics stack and latency at several added steps. I remember an article a couple of years ago where someone rigged up a camera to measure key press to screen update on different machines and the results were eye opening. edit: found it http://danluu.com/input-lag/ http://danluu.com/input-lag/. The Apple ][ ties for first place with an iPad Pro.
- jart 6y agoAre you referring to this submission? https://news.ycombinator.com/item?id=23369999 https://news.ycombinator.com/item?id=23369999 Outstanding article. Total shame it only got 100 upvotes.
- fao_ 6y agoRelated, my favourite thread to come out of the queer tech circles: "Almost everything on computers is perceptually slower than it was in 1983" https://threadreaderapp.com/thread/927593460642615296.html https://threadreaderapp.com/thread/927593460642615296.html
- underwater 6y agoGoogle Maps is a truly horrendous interface. It's pretty, it's well built, but it's fundamentally a horrible UX. I find myself frequently bamboozled until I stop and try and determine which mode I'm in. Navigation behaves differently to browsing, which behaves differently to searching, which behaves differently to viewing an individual result. I'll be thrown from one mode to another and never feel in control of the app.
- 1ark 6y agoI hate it with passion. Clicking a photo on a café in the main view, horrendous because it does not actually open the photo, nor the overview on the café screen. Have to be on the photos screen for the photo to open up full screen. Pressing on some place while being in other than top mode. The back button experience. And the bottom drawer, no idea when I should pull it up or down, or if I am currently in it.
- jart 6y agoOne thing that's illuminating is go to chrome://settings/content/all and sort by "data stored" to see how much local storage websites use. Stuff like vice.com needing 100mb of space on your hard drive for who knows what purpose.
- jrochkind1 6y agoWow, thanks for the tip, never occured to me to do that. There were websites I had never heard of using hundreds of megs. Also acehardware.com for some reason using hundreds of megs. Also Github "community" forums and Travis "community" forums (I don't use travis anyore) using hundreds of megs. Are some websites just caching the entirety of every page you look at in local storage? How rude.
- esperent 6y ago> The Apple ][ ties for first place with an iPad Pro. * When used with an Apple Pencil (30ms). When used with touch it drops to 70ms. Also, it's worth noting that there's a very limited list of devices tested there and it heavily skews Apple.
- moosingin3space 6y agoAnother fascinating look into text on computer screens is this article: https://gankra.github.io/blah/text-hates-you/ https://gankra.github.io/blah/text-hates-you/. Just goes to show that text rendering is actually absurdly complex, unless you drastically restrict the problem space.
- makapuf 6y agoThis sometimes makes me think we're still on the skeuomorphism phase of text. Its more and more complex to render realistic looking with proper illumination and textured faux leather for your UI until until you just admit you're rendering a ui on a screen and then you're back to colored rectangles. We're still trying to render ideas and words resembling handwriting and print press characters, until we embrace screens and render arial and images or even monospaced fonts which are perfectly readable (I do that all day long on my code editor)
- skipnup 6y agoAnd then comes unicode and all the simplicity is gone again as the rest of the world uses more than 26 letters.
- moosingin3space 6y ago> until we embrace screens and render arial and images or even monospaced fonts that are perfectly readable This is part of what I meant when I said "drastically restrict the problem space".
- vmladenov 6y agohttps://twitter.com/id_aa_carmack/status/193480622533120001?s=21 https://twitter.com/id_aa_carmack/status/193480622533120001?...
- tshaddox 6y agoI’m pretty sure that none of these latency benchmarks are showing that text input speed is affected. You can definitely input more than 1 character every 40ms in modern “slow” text editors.
- tleb_ 6y agoThe question isn't about throughtput but latency.
- anthk 6y ago>all sorts of things we never had a couple of decades ago We had them.
- throwanem 6y agoEmacs does those things too, these days. It's still snappier than anything else I've tried recently.
- unknown2374 6y agocough vim cough I'm just kidding. Don't want to start a fight here.
- throwanem 6y agoWell, with vim, it probably depends more on your terminal and tmux, while Emacs renders its own graphical frames. But those wars are long over anyway, these days. One might just as well fight over whether the monolith on Earth's moon is better than the one on Europa, or vice versa.
- deleted 6y ago[deleted]
- GuB-42 6y agoInteresting how what was seen as slow and bloated back then become the opposite today. Eight Megabytes And Constantly Swapping, yep, back then, 8MB was unthinkably large for a text editor... Another example is the Enlightenment window manager. It was considered a little heavy, but good looking. But because there was a large hiatus in development, it got "stuck in the past" and now, it is one of the lightest there is.
- unknown2374 6y agoAs mentioned in the other comment, emacs does those things, and so does Vim (with plugins of course). I moved from sublime to atom to VS code, but eventually settled on Vim because I was able to get the same features (that I used) while getting almost instant response. A feeling that has completely changed how much I enjoy writing any sort of text.
- higerordermap 6y agoYeah. LSP has changed a lot for me. For C/C++, could use QT Creater or KDevelop too, which I think are pretty good in latency.
- zant 6y agoI tried to move from VS Code to NeoVim with NerdTree and some other plugins to make it more IDE-like. But eventually wasn't able to get the same code completion, and searching was also a bit more painful. How do you go about that? Would you mind sharing your setup? :)
- smichel17 6y agoWrite code in vim with no/few plugins. Don't worry about getting the variable names right. Then move to your IDE to get it to compile. It's conceptually similar to sketching out the design of your code with a pen and paper or whiteboard. First write it quickly, then make it correct.
- Aeolun 6y ago> It's doing autocomplete suggestions, linting code as I type Even so, shouldn’t it be able to do that in 16ms?
- dsr_ 6y agoFermi guess: 60 wpm, that's one 5 character word per second, it probably doesn't make sense to give a new prediction more often than once per character -- that's 200ms to chew on autocomplete and linting and fancy animations. Meanwhile, please render the specific character out of your lookup table in 16ms, thank you. Do modern graphics drivers for X or Wayland hand off font rendering to the GPU? They probably should -- it's maybe 100 or so small textures per font-selection, 150KB or less prerendered with 3-bit alpha, and maybe 100 loaded up into graphics RAM at a time -- 10MB is nothing, really.
- chii 6y agothey certainly could. Games can do 16ms frames, while calculating full physics simulations. It's just that text editors of the modern day are programmed by people who prefer to not write it that way - mainly because it's quite hard, and the modern OS doesn't usually fit well into this framework of rendering for multi-tasking. And it takes more effort too. Much easier to rely on a UI framework which adds overhead. The expectation is that the user probably won't care, and prefer that the software be more feature rich.
- xvilka 6y ago> IMO there's a tradeoff: we could be writing all our programs in C, still. No need for that - you could use Zig or Rust. Though both need a better GUI frameworks, but it's certainly more efficient with them.
- deleted 6y ago[deleted]
- badsectoracula 6y agoI might sound like those weird language evangelists, but... > we could be writing all our programs in C, still. You don't need to use C, there are other languages. For example a hello world in Free Pascal[0] (a natively compiled language with no runtime or other dependencies, which supports object oriented programming and has RTTI rich enough to implement automatic object serialization, semi-automatic memory management, strings that know about their encoding, etc) is just 32KB. Some time ago i wrote Fowl[1], a mostly complete recreation of the OWL toolkit that came with Turbo Pascal for Windows, the demo program of which is around 80KB. Of course for a more realistic (and MUCH easier to use and develop with) approach, you'd need something like Lazarus[2]. A minimal application in Lazarus is 2.18MB. This might sound too big... and TBH it is, but the size doesn't grow too quickly from there. For example a profiler i wrote recently for Free Pascal applications is... 2.16MB (yes, smaller, why? Well, because i replaced the stupidly huge default icon with a smaller one :-P and without the default icon a minimal application is 2.05MB so the profiler added around 100KB of additional "stuff"). > It's doing autocomplete suggestions, linting code as I type... all sorts of things we never had a couple of decades ago and are huge productivity boosters FWIW we had those, Visual Basic (or even QBasic) would format your code as you type it, Visual Basic 6 and Visual C++ 6 would profile auto-completion (VB6 even for dynamic stuff), etc. Only issue with C++ was that sometimes it wouldn't work around complex macros. But modern editors do a bit more, still no excuse for being that sluggish. Lazarus does pretty much everything you'd expect from an IDE with smart code completion (e.g. things like declaring variables automatically, filling method bodies, etc) and code suggestions yet it runs on an original Raspberry Pi. Now i'm not saying that you should not be using whatever you are using or that you should code on a Rasberry Pi or even to switch to Free Pascal / Lazarus (which honestly is far from being free of issues), but i think that you're overestimating what tools do nowadays and many people are so used to running slow and bloated software that take it for granted that things should be like that and cannot even imagine things being better. [0] https://www.freepascal.org/ https://www.freepascal.org/ [1] http://runtimeterror.com/tech/fowl/ http://runtimeterror.com/tech/fowl/ [2] https://www.lazarus-ide.org/ https://www.lazarus-ide.org/
- jbluepolarbear 6y agoVisual Assist Tomato wouldn’t have existed if Visual C++ did what you said. I use Rider (mostly) and I don’t even know how I’d program without all the features it adds. Auto import, code cleanup, code optimizations, memory allocation and boxing highlights, decompile assembly, Unity engine integration. I remember the days using Visual C++ and banging away on trying to get QT to not look ugly. I don’t miss anything about the development process from 15 years ago.
- abraxas 6y agoI wrote 3D visualization apps in 1998 using FLTK and OpenGL and the (statically linked) binary was less than 20 MB. I think my desktop had all of 64MB of RAM. It was snappier than a modern TODO app on Electron and far, far easier to write. What on earth have we done to ourselves?
- cwyers 6y agoAmong other things we've done to ourselves, we've got higher-resolution displays, and we have GUI apps that can scale to different resolutions seamlessly. We have support for high DPI displays. We have fonts with sub-pixel rendering for sharper, easier to read text. Speaking of font-rendering, we have Unicode and internationalization support, so that people who read and write Arabic, Chinese, Japanese and other languages that don't use the Latin alphabet can use their native language in file names, dialog boxes and in anywhere else they might want to. We have better support for screen readers for the blind. For people who aren't fully blind, but have vision problems, we have the ability to make text and UI features larger dynamically to support them. We have better multitasking support, including process isolation to keep a badly-behaved application from crashing the entire computer. We have better security at the OS level to prevent malicious applications to take over the whole machine. That's a big part of what we've done to ourselves. And this makes computers better for a whole lot of people.
- abraxas 6y agoYeah, no. First, all those things sans high DPI functionality existed in 1998. Second, most of Electron apps don't benefit from these theoretical advancements. Preemptive multitasking existed in 1998 and worked every bit as well as it does today. Even in MS Windows. Security, nah. We have more attack vectors than at any point in the past. And just more crapola caked on to "protect" against those.
- akhilcacharya 6y agoEasier to write? I’m curious are there any sample apps like this that I can read?
- naikrovek 6y ago> That isn't what my text editor is doing, though. It's doing autocomplete suggestions, linting code as I type... all sorts of things BEFORE the typed character shows up? Are you sure? 16ms should be an absolute upper bound for a character to show up. Everything else comes after.
- andi999 6y agoBefore the second character is typed...
- spacechild1 6y agoNo. These things should happen concurrently, probably on different threads. If I quickly type “foo“, I don't need to do run autocomplete and code analysis between each character. That would be horrible.
- pjmlp 6y agoI bet some of those UI coded in Delphi versions targeting Windows 95 would be way less than 20MB.
- qw 6y agoMany years ago I wrote a simple Delphi application that used the standard rich text editor. The size was less than 150kB
- canadianfella 6y agoIt outrages you somewhat?