211–220 of 801 posts
Earlier quoted context omitted.
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.
[deleted]
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…
I think it'd be better to improve Electron so that native applications don't have so much of an advantage. WebAssembly is a big part of that. Another useful part would be an alternative layout mode that eschews legacy HTML/CSS cruft, for more predictable and performant GUIs.
Ah yes. The classic text editor debate thread. In this thread you can expect to find folks claiming that 2 seconds of startup time for editors, like Atom, is so disruptive to their workflow that they'd rather use notepad.
Earlier quoted context omitted.
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.
Javascript is meh, it's HTML and CSS that are the real culprits for the crazy inefficient GUI rendering. HTML was great for what it was designed for, but we're ten years beyond that. Something will come in and replace HTML, it's just a matter of time. The main driver is mobile. The many layers of abstraction burn battery, one day phone manufacturers will get tired of it and do something.
The amount of bad hacking that has to happen for NodeJS to work as a platform has said all I could ever want to possibly know about the quality of NodeJS developers: so pathetically in love with their trainwreck of a language that they would rather pile kludge upon hack upon kludge than to learn the language and environment most appropriate and most computationally efficient for the tasks at hand. Javascript devs wou…
And guess what, 90% of everything is shit.
The current "JS devs" are the former "PHP/Java devs" and the former "VB/Delphi devs" and the former "C/Cobol devs".
They're us.
Java developers have intelliJ IDEA, Eclipse and Netbeans, all written in Java.
JavaScript developers have Atom and VSCode. Since JS was created for HTML, it seems logical for me to use browser tech to build these editors.
It allows JS devs to build extensions without the need to learn a different language. As Java devs can build Eclipse plugins with Java.
Also, the Electron based editors aren't the only ones available, so it isn't as if someone would force the poor dumb JS developers to use these clunky slow tools, like when Slack built their client with Electron and you had to run a monster app for a simple chat.
If they want something faster, there is Sublime, Vim and Emacs...
Earlier quoted context omitted.
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.
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…
HTML/JS/CSS is just a stepping stone like any other, not an endgame. Don't grow complacent with it. Demand something better.
Earlier quoted context omitted.
Interesting, considering that CSS animations were supposed to be much better than JS animations in that regard. I guess a simple setInterval would actually perform better here.
CSS animations and raw JS animations perform equally well. JS had a bad reputation for animation only because the common libraries back then (jquery, mootools) had absolute horrible incompetent implementations. This also has nothing to do with the blinking interval. A setInterval would simply not do the same. The CSS animation is fading its opacity at 60 fps not toggling it. Doing the same with a setInterval(.., 1000…
Most of the cursor styles have some sort of animation, but the "blink" style is just an on-off blink with no fade. Chrome updates every animation at 60hz, even step animations like these. This is an acknowledged issue in the Chrome bug tracker as linked in the issue.
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…
Earlier quoted context omitted.
Google Docs takes a good 2-3 seconds to spin up a UI on my i7. I doubt much of that time is spent building the DOM tree for the UI. Google Docs does a lot more than a simple text editing widget - there's a networked file system, a multi-user collaboration engine, a realtime notification system, etc that all get initialised. Instantiating all that over a network in 2-3 seconds is really fast.
> there's a networked file system > a multi-user collaboration engine > a realtime notification system None of these apply to a new, unshared document. Those subsystems can be loaded slowly over the following 10 seconds, that's fine. Is it such a hard thing to ask to make the UI responsive within 0.1 s? Like, be able to type stuff and have it appear on the screen without delay? It's so bad that I often use the basic…
It's gotten so bad that I'm considering moving to another provider or using a good old email app again.