101–110 of 801 posts
> The JS implementation uses an interval of 500ms between updates while native animations will be updating at 60Hz. At the moment we're not smart enough to deschedule ourselves during animations with step timing functions.
https://bugs.chromium.org/p/chromium/issues/detail?id=500259
Earlier quoted context omitted.
I don't know why you're saying they are slow. vscode starts up pretty fast. Sure it consumes more resources than vim. However having code completion, debugging, linting, and a bunch of IDE like features is super useful including the fact that it's cross platform and open source. It's very hackable. Just last night I fixed an issue that had been bugging me for a while. Pages with ads use a lot more of my CPU so I'm no…
100% of vim users will tell you that their vim setups also have code completion, debugging, linting, etc...
TL;DR: It seems to be a problem in Chromium, the relevant CSS (one second change) results in a 60hz animation cycle. Workaround: "editor.cursorBlinking": "solid"
I recently discovered the same issue in a webapp I develop... a simple CSS animation for a "loading" spinner was pegging the CPU. Using steps(n) with a low number basically resolves the issue. https://css-tricks.com/snippets/css/keyframe-animation-synta... Kind of ridiculous that it's so easy to make this mistake.
Adding ANOTHER interpreted language to the pile? Jeeze you guys are crazy. Just STFU and learn C/Go/Java
Does ANYONE in NodeJS world care about efficiency? Or does this "plebian" (ew! hacking is not plebian!) hackability trump all other concerns?
Earlier quoted context omitted.
> easy to get started Yes. > cross platform support Yes. > Because you can write plugins in JS? Yes. --- As much as I prefer native programs as a user, it's impossible to ignore the benefits of cross-platform development and plebeian hackability/debuggability.
>> cross platform support > Yes. WOW FINALLY SOMETHING that will run on my LINUX and FreeBSD! ohh.. a lot of plugins don't support linux and it doesn't build on BSD?
doesn't run on ZX Spectrum either
Earlier quoted context omitted.
> easy to get started Yes. > cross platform support Yes. > Because you can write plugins in JS? Yes. --- As much as I prefer native programs as a user, it's impossible to ignore the benefits of cross-platform development and plebeian hackability/debuggability.
>> cross platform support > Yes. WOW FINALLY SOMETHING that will run on my LINUX and FreeBSD! ohh.. a lot of plugins don't support linux and it doesn't build on BSD?
>A workaround for folks who are similarly obsessed about battery life That's odd wording. Obsessed because I don't want to waste energy, which leads directly to pollution? Or don't want a short battery life on my laptop? Power savings shouldn't be seen as irrelevant geekery. 13% is half the capacity of a single core in a four core processor. My 5 year old 2500k peaks at 120 watts. So 15 watts to render a cursor? Micr…
It just doesn't go in my head that we are building text editors inside a web browser! I get it, there are many good use cases for Electron and it's easy to get started with cross platform support, but why is everybody going crazy about text editors in them? Because you can write plugins in JS? Wouldn't it be better to make native application, especially for code editors, where developers spend most of their time, whe…
An additional feature is that you can run the IDE in the web browser, so that you can have an online code editor. Think for example about configuration files on the Azure website, or a cloud IDE with multiple people using it.
Honestly I think Visual Studio Code is not slow enough for people to switch. A long web page is very similar to a long code document, all the keywords are just span's with a colour. Furthermore, it is not like Visual Studio or IntelliJ are known for low CPU or smoothness.
It just doesn't go in my head that we are building text editors inside a web browser! I get it, there are many good use cases for Electron and it's easy to get started with cross platform support, but why is everybody going crazy about text editors in them? Because you can write plugins in JS? Wouldn't it be better to make native application, especially for code editors, where developers spend most of their time, whe…
Yep. I also can't wrap my head around the fact that we are now constructing buttons, drop-down boxes, tagged text boxes using dozens of nested layers instead of a native widget that writes directly to the screen. My 486 rendered UIs with nearly imperceptible lag. Google Docs takes a good 2-3 seconds to spin up a UI on my i7.
It just doesn't go in my head that we are building text editors inside a web browser! I get it, there are many good use cases for Electron and it's easy to get started with cross platform support, but why is everybody going crazy about text editors in them? Because you can write plugins in JS? Wouldn't it be better to make native application, especially for code editors, where developers spend most of their time, whe…
The lesson here is that our assumed bars of quality for what makes a text editor good are inaccurate. It turns out that the minimum performance bar is lower than you think, and that ease of customization is, in fact, much more important than you think.