351–360 of 801 posts
Earlier quoted context omitted.
> I think we'll get there eventually but until a native toolkit presents an interface as easy to use as the web developers are going to take the path of least resistance. Like Qt did with QML? http://doc.qt.io/qt-5/qml-tutorial1.html
Yeah, but Qt has licensing costs for commercial use...
With the GPU the only viable option for rendering blinking caret is to redraw the whole window. That's why it takes so much CPU as Chrome uses mostly CPU based rasterizer.
But redrawing the whole window in GPU is not that bad if the renderer is capable of caching GPU objects while rendering.
Here is what happens in Sciter (https://sciter.com) while rendering blinking caret in screen of similar complexity (editor with syntax hihglighting):
https://sciter.com/images/sciter-caret-cpu-consumption.png
As you see it CPU consumption is near to zero.
> Because you can write plugins in JS? Yeah, kind of. Sadly most developers have neither formal nor self-taught education about compiled programming languages and/or desktop development. They're only familiar with web-related programming, so if you only have a hammer, everything looks like a nail. Being a hardcore real-time desktop developer during the mornings and a freelance web developer in the afternoons, I hones…
Can we cut the "holier than thou" pretentious bullshit? Just because someone uses a different language, or solves different problems doesn't make them worse or any less "hardcore" than you. You are right, the average JS developer might not be able to instantly know the details about how to implement a text buffer, because they don't need to do that on a daily basis. You probably don't know the details about how to im…
Earlier quoted context omitted.
That's a fun analogy, made me laugh. :) I see this literally everywhere though, the article at hand is only a slightly better example than almost everything we do. Browsers consume gigabytes of memory to render a few basic web pages. We use high level scripting languages with tons of dynamic memory inside containers that are running on VMs to run all our cloud infrastructure. If we had the time, these things could be…
> cpu time & memory are close to free Not for 3 billion people. Also energy is not free at all.
But you're right, and on the global scale, we may actually be doing the equivalent of churning butter with jets. I totally wouldn't be surprised if the sum total energy expenditure on all computers in the world was greater than on all the aircraft in the world... and we are most definitely wasting the vast majority of the energy we use on computation.
Still, in my defense, I said close to free, and compared to the cost of a 787, cpu time & memory are closer to free than jets, no matter who we're talking about, right?
Earlier quoted context omitted.
I don't get this criticism. HTML/CSS is the closest we have to a universally understood syntax for designing interfaces. Why invent a new standard? HTML is fine, CSS is fine. Most importantly, everyone understands it and can work immediately with it. Any issues with performance is due to the implementation of the platform that renders this HTML/CSS interface. It's much more likely Google Docs feels sluggish due to th…
Why invent a new standard? HTML is fine, CSS is fine. Most importantly, everyone understands it and can work immediately with it. In order to render HTML, CSS and JavaScript, you need an entire web rendering engine. A new standard would let us get by with a lot less.
Getting to piggyback on V8 and Blink work is, I suspect, often a benefit rather than a cost in the eyes of developers of Electron-based editors. Sure, it's bigger resource load, but for use cases where the performance is acceptable, it's a lot less developer load to get the functionality out the door.
Earlier quoted context omitted.
>they are 'irrelvant benchmark numbers', because no such 'slowdown' is actually felt by most developers that try VS Code I don't think that's true at all. I have tried both VSCode and Atom, and immediately dropped them both after they crashed opening a file of a few thousand lines.
This. Text editor can't handle openning log file. (no need to highlight anything, complete anything, scan the structure etc. Just show me the damn log!) With the latest updates they are now able to open files up to 10Mb, wow.
This reminds me that as part of the Windows95 development effort, Microsoft disabled per-second updates of the taskbar clock to improve performance. Raymond Chen wrote a bit on it back in 2003: https://blogs.msdn.microsoft.com/oldnewthing/20031010-00/?p=...
On the other hand, iPhone's "Clock" app has an icon that shows the correct time with a super smooth seconds indicator. Which doesn't drain the battery.
I suspect that iPhone's "Clock" app would have difficulties both with smoothness and battery life if constrained to 4MB of RAM and paging...
I simply cannot understand why Atom and VSCode are so popular. I get that they are extensible, but is that really worth the slowdown to you? If I need more features than a text editor, I use an actual IDE. Someone just posted some really embarassing benchmark numbers regarding this issue yesterday: https://github.com/jhallen/joes-sandbox/tree/master/editor-p... Note that Atom and VSCode are nearly 10x slower than all…
It's not slow to me, I find my computer uses far less resources than say one of the million JetBrain IDE's. Combined with a bunch of useful plugins, it's pretty wonderful.
IDEs are definitely slower than text editors, but they have their benefits that comes with their tradeoffs (like most things).
Earlier quoted context omitted.
You both do realize that similar arguments could have been made back in the day when moving from, say, command-line DOS applications to Windows API applications - right? Ultimately, computing has always been one of abstraction from the lower "layers". Taken far enough, one could spuriously argue that if you aren't soldering together the flip-flops that make up your logic and memory, you just aren't being efficient...
There is a point to be made here though that is more valid than the argument against moving away from command-line DOS applications to Windows API applications. Moving from text-based to graphical is a much different shift than what we are talking about here. The idea here is that we are creating many abstractions to get the same basic result. I can't rewrite Atom.io for DOS, but I could rewrite Atom.io to use the Wi…
Earlier quoted context omitted.
So does it have a NoScript plugin to kill the unavoidable 200 tracking and ad scripts from Google, Facebook and who knows what running in the background? I am sorry if I offend someone with this, however the current Web experience is something I want as far away from my dev. tools as possible.
tracking or ad scripts by facebook or google are in neither atom nor VSCode. both projects are open source if you care to verify
