281–290 of 801 posts
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…
I recently switched from Atom to VS Code and have noticed a considerable reduction in lag, especially when using CMD+D and searching through project files.
Since I made the switch I've found VS Code to be quite nice. I miss having Hydrogen available but I can always run jupyter notebook if I need something like that.
Earlier quoted context omitted.
Also compare Google Docs with Microsoft Word and LibreOffice cold start up time. You will see 2-3 seconds is fast and the two mentioned are not even loaded from a remote resource...
Excel loads in ~1 second...and doesn't have UI lag after it does. Try working with large data sets in Google Docs and you'll have that 2-3 second lag time with _every_ operation you perform.
Earlier quoted context omitted.
> Why invent a new standard? Because they suck?
Care to argue why? Also, there are countless alternative languages to compile down to HTML or CSS available. Feel free to create your own if none agree with your personal leanings.
Where do I start?
1) Designed for document presentation, not for apps. 2) Limited widget selection (native forms and that's it). 3) Different implementations between vendors. 4) Bad at layout (20+ years to get to Flex and Grid CSS layout which kind of resembles UI layouts but is still not supported everywhere. 5) Slow 6) Batter hungry 7) Too many un-needed UI layers (DOM over native widgets) 8) Extra language layer (JS on top of v8 on top of native execution) 9) JS is not the best language to write large scale software (to put it mildly) 10) Restricted access/integration to native platform APIs.
Earlier quoted context omitted.
As was pointed out numerous times in that thread, they aren't 'embarassing benchmark numbers', they are 'irrelvant benchmark numbers', because no such 'slowdown' is actually felt by most developers that try VS Code. > But they have no place in text editing. Their popularity proves otherwise.
>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.
With the latest updates they are now able to open files up to 10Mb, wow.
will-change: opacity
https://medium.com/outsystems-experts/how-to-achieve-60-fps-...
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...
> 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? No, we don't. With Windows API there's no sandbox and extra embedded language overhead (it's still native code like in DOS, and even optimized better, able to use more available memory than DOS would allow, etc.). Oh, and you also got the benefit o…
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.
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…
This arrogance is amusing. The only thing the web and Javascript world proved is that we are bad. In the past it was much harder to distribute crap since you needed to, you know, find and install everything. Since websites are so frictionless, now we get to experience everything. 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 for…