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...
The extra abstraction layers you're talking about are invisible to the user... while our GUIs are slower, and our processors faster. It feels like, after 30 years, we should be able to have our GUI cake and eat it, too.
In the "good old days" the user interface was 640px x 480px (original VGA[1], skipping past the original MDA, CGA, and Hercules graphics cards[2] since they predated "modern" GUIs). Then it was expanded to 800x600, etc. The programs of those days were hard-coded to the graphics adapter resolution. If a program did not support the graphics adapter you had, you had to run your GUI in lower resolution compatibility mode. Sometimes it didn't work at all.
In lower resolution compatibility mode, the program's display got uglier and uglier as the screen resolution went up.
The abstraction layer today is adaptive and high DPI. Since the abstraction layer abstracts away the actual display resolution, programs (generally) can take advantage of the resolution that is available on a given display without change, allowing a program to run on small hardware displays (phone/tablet form factor) up to mega 4K++ displays, looking better and better as the screen resolution goes up.
GDI was originally designed to run on printers as well as screens, where the DPI values are completely different.
The declarative model of CSS has nothing to do with it. You can specify pixel values in CSS if you like.
And many (most?) do... leading to the reinterpretation of what "pixel" means in the CSS spec. Yes, CSS pixel does not mean a physical pixel on the screen.
Integer pixel coordinates are right there in the most fundamental functions:
HWND WINAPI CreateWindow(LPCTSTR lpClassName,
LPCTSTR lpWindowName,
DWORD dwStyle,
int x,
int y,
int nWidth,
int nHeight,
HWND hWndParent,
HMENU hMenu,
HINSTANCE hInstance,
LPVOID lpParam);CSS people still think a grid is a choice of "small" "medium" and "large" columns/rows. Haha.
> CSS people still think a grid is a choice of "small" "medium" and "large" columns/rows. Haha.
CSS Grid is literally Microsoft taking the WPF grid layout and porting it to the Web!
And even now it's still not mature and supported in all browsers.
> we don't need the new stuff
> how about we throw both away to shut everyone up, would that make either side happy?
There's nothing special about javascript the language. The nice thing about web development is that the really fast framework iteration cycles. And everyone complains about them, but as a result we have some fantastic APIs for UI development in javascript land now. (Eg, react.)
What I want to see is someone port those lovely abstractions across to native languages. For example, a port of choo[1] to swift on top of uikit would be gloriously fast, efficient, small and easy to work with.
Edit: I'll add, I frequently see people say that Windows XP was the best OS ever made. Why the rose-tinted glasses? It was the tail end of the era when hardware was getting faster, faster than software was getting slower.
Yes, I know, he's still around...
The thing is, using C++ instead of React for mobile development of a simple application would probably make me miss deadlines... So we just stick to whats popular.
This is absolutely not true.
Going to windowing GUIs from character-mode DOS was a massive usability improvement. No more exotic ctl-alt-function key combos (or control-control sequences for WordStar users like me).
Going from desktop apps to webapps changed the abstraction layer of how we access and share documents. No more installing software on the desktop. Docs are available on every computer we log into. Multiple people can edit the same document.
Maybe you don't care about document sharing and would be happy installing old school word processors and spreadsheets? That's a fair statement to make, but the market appears to be voting otherwise.
At least VS Code has to be installed. It is a plus for Google Docs & Co, but not universal. And in most cases, instead of installing you now have to create an account.
>Docs are available on every computer we log into. Multiple people can edit the same document.
Those features are completely independent from the platform the application uses. Those features are commonly implemented in web apps because for a long time they had no other choice, but cloud storage and collaborative editing can be equally well implemented in a destop application.
cough Blender ...
I would point to Eclipse as another classic example of "obviously designed by an engineer". There's tons of functionality under the hood and it's a fantastic jumping-off point for further customization... but its layout is intensely non-intuitive in so many ways compared to a purpose-built IDE.
Everything is locked away in menus and "perspectives". If you're writing a Java web app - do you want the Java perspective, the Java EE perspective, the Web perspective, or the Debug perspective?
I hear GIMP's no picnic to work with either but can't confirm personally.
It used to be that OSS was developed by people that actually used it. Maybe it wasn't pretty, it had a steep learning curve, but it got things done and was efficient once you learned how. Often you got fresh perspectives on how an interface could be done, since people got fed up with existing solutions.
Nowadays you get UX experts preaching how an interface is supposed to look like, which mostly means copying Apple or Google. You get tons shiny whitespace. Burger menus, because that's what "everybody is used to".
GIMP with "good UX people" would turn into a bad copy of Photoshop.
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 of a FULL graphical interface over DOS. Here you have slower performance, extra cruft, bad apis AND the same final output (as a GUI app).
Not to mention that the Windows API UI toolkit, while bad, is sane compared to the web stack.
The lack of games was mostly due to reluctance of game developers to abandon Assembly and using directly PC hardware, specially because C and C++ compilers were "too slow".
And the "assembly" argument doesn't make any sense. You can program Windows games in assembly if you want.
Sure you can use Assembly on Windows and there were a few books teaching exactly that, but you weren't allowed to touch the graphics hardware any more, unless you were doing a graphics driver, and do all those graphic card tricks, specially mode X.
Completely disagree. Charles Petzold's HELLO.C is hundreds of lines of code. Hello World on the Web is, well, "Hello world!".
"Sane" environments don't force you to make up a distinction between "long pointers" and "pointers" if you want to conform to the house style in order to match 16-bit x86 real mode. Or route all events through one WndProc, forcing use of "message crackers" to poorly recreate the ergonomics of addEventListener. Or have to recreate the vector graphics stack not once but twice in order to deal with the lack of forward thinking (GDI, GDI+, Direct2D). Or deal with incredible apartment threading complexity to maintain VB6 compatibility. Etc. etc.
If you had said .NET, maybe. But Petzold-style Win32 is bad.
It's actually 87 lines of code, with a disclaimer comment, ample empty lines, a callback to play a wav when clicked, and an error message for when it's not run on NT. So, like 30-50 lines of actual Hello World necessary code. And that includes the starting up boilerplate.
That's about as relevant as complaining about the large binary size of a hello world program in a language creating static binaries. It might be larger than expected, but it usually includes a whole runtime. So once you add actual code, the binary's size doesn't scale linearly with the code size.
For comparison, a modern CSS "reseting" file, which just removes empty values is usually larger than the hello.c example.
This is the problem with trivial/contrived examples. They don't show you how the thing you're discussing scales in actual use.
In this case, the hello world in HTML is not representative of what you need to do to create a medium/large SPA in HTML.
And the old Windows api you could always wrap in higher order stuff, or even use as a basic layer to create your own UI library (still native).
The web stack, because of how it is done, you can't.
Petzold's Hello World is far more than what I'd consider a Hello World in Win32, because in addition to what you noted, it also creates a "full" window with all the associated complexity of managing its drawing yourself. A more suitable Win32 Hello World is not that much more complex than the traditional C one:
#include <windows.h>
#include <winuser.h>
int main() {
MessageBox(0, "Hello World!", "Hello World!", MB_OK);
}
In other words, I'd say Petzold was at least partially responsible for giving the impression that Win32 is impossibly complex even to start with. Fortunately others have come up with better introductions like http://www.winprog.org/tutorial/ or even https://win32assembly.programminghorizon.com/tutorials.html since then, but it seems that the damage has already been done and a whole generation of programmers have gotten the "Win32 is hard" notion embedded into their minds.
I was unfamiliar.
As much as I want as few layers between me and the hardware as possible, I would rather have many sane layers like much of the web than 1 insane layer like the win32 API. It doesn't follow good C, C++, std library or other conventions. Many functions have multiple poorly documented modes based on which structs you pass are empty or null pointers. It also just fails often for no reason I can understand, and the distinction between windows application and console is quasi magical and counterproductive.
Posix... Is a blessing by comparison. Every time I need to touch it it take me something like a single hour and I have a function that works reliably and just does what I need. Until we get to X11 and manipulating those windows. Then I just want to punch everything, but at least X11 works once the code is written, even though its inside out and backwards.
Now I just strongly prefer to use a good library to get at OS facilities. Things like SDL, boost or Intel Threading build blocks, etc. They are fast and generally tight enough I can open them and understand down to the hardware when I want.
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 Windows API directly rather than being Electron-based.
We're talking about VS Code using 13% of the CPU while idle to render a blinking cursor. What benefit does the user get from this? We could render a blinking cursor with less then 13% of a much less powerful CPU years ago.
(Not that Qt is a bad library, but it's bizarre that such an important area is so neglected by our industry).
And it does seem very very strange. I'm imagining this Socratic dialogue:
---
Socrates: What is the most popular programming language?
Developer: Java.
Socrates: And why is Java so popular?
Developer: It's the first language most people learn nowadays, so everyone knows it.
Socrates: So it's popular because it's popular?
Developer: Well, it's very similar to C++, which was the most popular language when it first came out, so it was easy for people who already knew C++ to learn.
Socrates: So why not keep using C++?
Developer: C++ had a lot of problems that made it hard to use, and Java solved a lot of those.
Socrates: Such as?
Developer: If you wrote an application in C++ that ran on any given operating system, like Windows, you wouldn't be able to run the same code on another operating system like Linux or Mac; you would have to rewrite much of your work from scratch to support more than one operating system. Java is "write once, run anywhere." Your Java program will run exactly the same way, without having to rewrite anything, on any operating system that has a Java implementation.
Socrates: Interesting! Can you show me?
Developer: (Writes "hello world," demonstrates it runs the same in both cmd.exe and Bash)
Socrates: And that works with real programs too?
Developer: What do you mean? This isn't a very long or useful program, but it is an real program.
Socrates: What's special about what you just showed me? Can't you write these command line things in any language? Look: I learned a bit of Python a few years ago. (enters python -c "print 'Hello, world!'" in both terminals)
Developer: OK, maybe that wasn't the best example, but when you're doing more complicated stuff it gets harder and harder to write code for more than one operating system in a language like C++, so a language that runs the same everywhere, like Java, or Python, is better to have.
Socrates: So like an application that you would install?
Developer: Exactly!
Socrates: OK! So could you show me a real application then? Like, it says "Hello, world!" in a window, with a menu and buttons and stuff? And it will be the same on both Windows and Linux?
Developer: No, that's not possible.
Socrates: Hm?
Developer: You can't do that in Java.
Socrates: So, Java is the most popular programming language, but you can't use the programs you write in it?
Developer: Alright, you got me there. Usually Java is used for writing applications that run on servers, not PCs.
Socrates: Servers?
Developer: Yeah, like if you go to a website, there might be an application on its server to fetch your account information from a database.
Socrates: But why do you need a special application for that? Can't you just ask for the information you need directly?
Developer: Good question. We're moving in that direction. But for some things you really do need some kind of custom logic, and for those things Java is a good solution across different platforms.
Socrates: What different platforms are there in servers?
Developer: There aren't really that many platforms. Almost all servers run Linux. But there's also a few that run Windows, or FreeBSD, which is very similar to Linux.
Socrates: So if you were on a less popular operating system, like Windows, you would use Java to be compatible with Linux?
Developer: Probably not; really, the only reason you would use Windows on a server instead of Linux is if your application were written in C#, which is Microsoft's Java competitor.
Socrates: So Java is the most popular-because-it's-popular programming language you can't write programs in, and it's useful because it runs on every platform, on only one platform?
swing? awt? javafx?
Ugh, reddit's standard, snarky response: "you do realize... right?"
There's simply no way to get around the fact that by and large, many in-browser apps are poorly performant by any modern standard.
To me, it seems like there's a faction within the web development community whose goal is to take things that worked perfectly fine as native apps and re-implement them with poorer performance in the browser, with seemingly no benefit.
I wish these people all the success in the world, if that's what they enjoy doing. But for the most part I simply cannot tolerate the work they produce.
Effectively we are back to the world of time-share terminals.
This realization that always-connected apps might be joined by disconnected apps is emphasized when looking to markets across the world. There are more disconnected people in the world than always-on, high-speed, low-latency connected. There is a burgeoning middle class characterized by sporadic, low-speed, high-latency connections, who are willing to spend some money online, for those times they make it online. They might spend pennies each today, but whoever captures those markets is addressing billions of underserved online customers. I'd take a billion $0.01 payments a day any day.
But if you set the cookies
document.cookie = "age_checker=pass; expires=Thu, 18 Dec 2037 12:00:00 UTC; path=/";
document.cookie = "is_legal=yes; expires=Thu, 18 Dec 2037 12:00:00 UTC; path=/";
Just because a design introduces extra indirection into a system does not mean that the design is providing any abstraction.
Likewise just because a design changes from one implementation to another does not mean anything has been abstracted.
Your example of moving from DOS to Windows is really good for illustrating this. DOS had almost no hardware abstraction support, you had to include drivers for a lot of hardware into your application. Moving from DOS to Windows 3.1 only provided abstractions over the video drivers, for example when it came to network cards you still had to use DOS drivers.
Moving a text editor from DOS to Windows does not provide you with any abstractions for things like the cursor. It is only changing the API for the sake of having your text editor run on a different platform.
Guess what? This is the same with trying to get your cursor and text rendering working on a web browser. There is absolutely no abstraction here, you are just changing your code to work with the very awkward DOM API.
But hey, thank god we finally have a framework we can inject ads in at will.
When Windows was developed, we had enough CPU power to do the basic tasks people wanted done with a computer at a reasonable speed - the idea was that spare capacity was being traded for user friendliness.
For some applications, even today, when maximum efficiency is necessary, purpose built machines ('soldering together the flip-flops that make up your logic and memory') are still used - it's just that it's often an ASIC that is fabricated.
And in many cases that led to an instant drop in productivity. Those old green-screen systems were not pretty but they were quite efficient to use.
Having worked on the system myself, they were right (this was as a noobie to both systems).
There is something to be said for a small, tight system.
This because the doctors insisted on using a DOS based patient journal, as they could operate it completely by keyboard while maintaining a conversation with the patient.
I speculate that one reason for this is that DOS allowed each program to have full keyboard access, while Windows and other GUI has to reserve certain keys for managing the UI (switching between windows etc).
Thus what was earlier a series of single key presses now involves holding down a modifier for the duration. And that is if the developer even remembered to put in a hotkey for said action.
It's just that software makers don't do it; most everyone thinks everyone loves to do things with mouse et al.
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.
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 HTML version of Gmail because it loads in less than 1 second. The normal "AJAX" version loads in 3-4 seconds. And I have a 200 megabit connection. Who wins at getting me my information faster?
It's gotten so bad that I'm considering moving to another provider or using a good old email app again.
Bloated single page apps is the curse of the modern web.
Also, Inbox did not show me full e-mails on my Android Wear smartwatch while Gmail did. Also, I couldn't figure out how to set up the filters I needed in Inbox.
Google Docs is truly amazing technology for the browser. It's just bringing its model to "native" apps that I have very mixed feelings about.
I see. In your opinion, do you think Chrome would be even faster if it managed to spin up an entire sandboxed docker container (in case any web site wanted one, to do whatever it wants with), as well as another one with a full Postgresql install (again in case any web site wanted one, to do whatever it wanted with, oh, and also for Chrome's own bookmarks and stuff), yet still launched within a blazing 14 seconds?
Would that be even faster, considering?
Because from where I'm standing, that wuold be 5-7 times slower.
And 3 seconds to start is 2.95 seconds too slow for me to start typing into a URL box, which could appear within 50 ms if it was done right instead of done wrong.
Chrome does things wrong instead of doing things right, and it really is that simple. I'm a human, not a network share. I use software so I can interact with it. It should do the rest on it's own time and as needed.
Loading a bunch of stuff "quickly" does not equal being quick. Google should know better.
Sometimes I think that comments like these arise out of not having experienced text-only rendering at 300 baud...
I know that's a generalization, and most likely unfair - but damn, today's phones, to this old man, are pocket super-computers (for that matter from my vantage point, an Arduino is a wonder, and a RasPi is utterly amazing)!
At the same time, we are now living in the future. With "pocket super-computers" that are more powerful than the Crays that existed when you were waiting on 300 baud text rendering, yet we are using 13% of that power just to render a blinking cursor? Does that not seem like we haven't made as much progress as we should have?
The point being, for the past decade or two, we've been burning all hardware performance improvements on things that are neither visible to user, nor enable them to do more with their computer. Surely, there must be ways of spending those CPU cycles and RAM bytes on things that are actually useful and enable people to do more / better / faster work.
Windows 7 boots in approx. 5 seconds to the desktop (if no password is set), and stuff like Word or Visio starts instantaneously. Web applications on the very same computer are a whole different story.
Let's just acknowledge that SaaS is not and never was about any kind of benefits for the user or customer, but just about either centralising resources and services back to the vendor's control and/or increasing money extraction.
I mostly use Ubuntu and there Libreoffice still has a stupid splash screen. After that though the amount of time is too small for me to count.
Please try to find a single example where this is true. Niche cases and greater diversity all come from a lot of work keeping runtimes up to date and APIs backward-compatible. This is only because of Free Software. Trying to credit this to "abstraction layers" is insulting to all of the programmers working on Free Software libraries, compilers, runtimes and operating systems.
So, I can't give a specific example but am instead pointing at the diverse ecosystem of applications and rich functionality. It's logically impossible for me to prove that these apps wouldn't exist without inefficient abstraction layers. It's my supposition, and the developers who write electron apps would probably agree.
The literally millions of applications not written on top of the specific crapware you list are an existence proof. This was the case even with assembly/Pascal/BASIC applications on microcomputers in the 1980s. Your whole argument is that somehow the web stack is easier to write applications on top of because <insert nonsense adjectives like "diverse" and "rich">. To go back to the Pascal example, a lot of people who program in Delphi strongly disagree even today, and Delphi has been around since 1995. What makes you think that the web stack has a higher speed of development than other software tools? Why do you think that high-speed development depends on inefficient abstractions? That is all total nonsense. There are a lot of problems with the web stack. You need to stop making up bullshit rationalizations and learn about other approaches to software development.
If speed of development isn't the reason, then what is the attraction? I'm serious and curious. I looked through your profile and you clearly know your shit. Are we just in a period of a bad stack being popular and used despite there being other, better options?
Google Docs uses the Internet, so did anything on an old modem. Word didn't (especially 20 years ago).
I'm not sure your arguement makes any sense.
"10secs! I was supposed to be at work 15 seconds ago!"
"Writing directly to the screen" (by which I assume you mean writing pixels one by one to the framebuffer) is a bad idea for modern graphics hardware. It was fine on the 486, but nowadays you need the ability to do global optimizations for good 2D (or 3D) graphics performance. Ironically, the Web stack is much better positioned to do this than, say, Win32, because of the declarative nature of CSS.
Besides, as some downthread have pointed out, you didn't "write directly to the screen" in Win32. You went through GDI.
What happens if you try to present an immediate mode API for UIs is the status quo with APIs like Skia-GL. You frequently end up switching shaders and issuing a new draw call every time you draw a rectangle, and you draw strictly in back to front order so you completely lose your Z-buffer.
Imagine if games worked like that: drawing in back to front order and switching shaders every time you drew a triangle. Your performance would be terrible. But that's the API that these '90s style UI libraries force you into. Nobody thought that state changes would be expensive or that Z-buffers could exist when Win32, GTK, etc. were designed. They strictly drew using the painter's algorithm, and they used highly specialized routines for every little widget piece because minimizing memory bandwidth was way more important than avoiding state changes. But the hardware landscape is different now. That requires a different approach instead of blindly copying what the "native" APIs did in 1995.
"What happens if you try to present an immediate mode API for UIs is the status quo with APIs like Skia-GL."
I don't know what Skia-GL is, but in games, the more experienced people tend to use immediate-mode for UIs. (This trend has a name, "IMGUI". I say 'more-experienced people' because less-experienced people will do it just by copying some API that already exists, and these tend to be retained-mode because that is how UIs are usually done). UIs are tremendously less painful when done as IMGUI, and they are also faster; at least, this is my experienced. [There is another case when people use retained-mode stuff, and that's when they are using some system where content people build a UI in Flash or something and they want to repro that in the game engine; thus the UI is fundamentally retained-mode in nature. I am not a super-big fan of this approach but it does happen.]
"and you draw strictly in back to front order so you completely lose your Z-buffer"
That sounds more like a limitation of the way the library is programmed than anything to do with retained or immediate mode. There may also be some confusion about causation here. (Keep in mind that Z buffers aren't useful in the regular way if translucency is happening, so if a UI system wants to support translucency in the general case, that alone is a reason why it might go painter's algorithm, regardless of whether it's retained or immediate).
"But that's the API that these '90s style UI libraries force you into."
90s-style UI libraries are stuff like Motif and Xlib and MFC ... all retained mode!
I don't agree that an IMGUI style forces you into any more shader switches than you already would have. It just requires you to be motivated to avoid shader switches. You could say that it mildly or moderately encourages you to have more shader switches, and I would not necessarily disagree. That said, UI rendering is usually such a light workload compared to general game rendering that we don't worry too much about its efficiency -- which is another reason why game people are so flabbergasted by the modern slowness of 2D applications, they are doing almost no work in principle.
Back to the retained versus IMGUI point ... If anything, there is great potential for the retained mode version to be slower, since it will usually be navigating a tree of cache-unfriendly heap-allocated nodes many times in order to draw stuff, whereas the IMGUI version is generating data as needed so it is much easier to avoid such CPU-bottlenecking operations.
Here is a (somewhat old) video explaining some of the motivations behind structuring things as IMGUI: https://www.youtube.com/watch?v=Z1qyvQsjK5Y
pcwalton seems to be presuming that part of the contract of an "immediate mode API" is like old-school ones it actually immediately draws to the frame buffer by the end of the call.
Whereas you are talking about modern "immediate mode API"s where the calls just add things to an internal data structure that is all drawn at once, avoiding unnecessary shader switches etc. IIRC this is how Conrod (Rust's imgui library) and https://github.com/ocornut/imgui work, although with varying levels of caching.
One point to make about retained mode GUIs is I remember reading an argument that immediate mode is great for visually simple UIs, such as those in video games, but isn't as good for larger scale graphical applications and custom widgets. For example when rendering a large text box, list or table you don't want to have to recalculate the layout every frame so you need some data structure that sticks around between frames specific to the widget type, so that's what retained mode APIs like Qt do for their widgets.
Sure you can do the calculations yourself for exactly which rows of a table are currently in view and render those and the scrollbar with an immediate mode API, but the promise of toolkits like Qt is that you don't have to write calculations and data structures for every table.
Immediate mode GUI systems are allowed to keep state around between frames and the most-featureful ones do. The "immediate mode" is just about the API between the library and the user, not about what the library is allowed to do behind the scenes. The argument that retained-mode systems are inherently better at this doesn't hold water; it is kind of an orthogonal issue.
This works just as well/quickly as a retained mode API in almost all cases. There's some cases like extremely long tables with varying row heights and sortable columns, where you need an efficient diff of the table contents. Since recalculating layout and sorting every frame is inefficient. Retained mode APIs do this with methods to add and delete rows. It's possible to do with an immediate mode API, but to detect differences in the rows passed in quickly you need to use a functional persistent map data structure with log(n) symmetric diff. Or you can just have an API that is mostly immediate mode but has some kind of "TableLayout" struct that persists between frames and is modified by add and remove functions.
I'm curious what API you would use for implementing a table with varying row heights (that you only know upon rendering but can guess beforehand), sortable columns and millions of rows. I implemented this in an immediate mode GUI API a few months ago, and I did it with persistent maps and incremental computation in OCaml. Incrementally maintaining a splay tree and a sorted order by symmetric diff of the input maps. This isn't as nice of an API in languages like C++ so I'm wondering if there's a better way.
In general my policy is that when things get really complicated or specialized, the application knows a lot more about its use case than some trying-to-be-general API does, so it makes sense for the application to do most of the work of dealing with the row heights or whatever. (It's hard for me to answer more concretely since it depends on exactly what is being implemented, which I don't know.)
Most "modern" mainstream native toolkits - e.g. GTK+ 3, Qt 5, WPF - encourage this separation into layout - GtkBuilder, QML, XAML - and style - CSS, Qt Style Sheets, XAML Styles.
So, this isn't a "web browser" problem. Or, this style of GUI isn't the problem with Electron. I find GTK and Qt apps to be plenty responsive enough, even when their GUIs are loaded from XML files.
Try working with large data sets in Google Docs and you'll have that 2-3 second lag time with _every_ operation you perform.
I got a popup inside the calculator asking for feedback about it once with an inbuilt form and submission. I can only assume it has toooooons of hidden away cruft that does everything but assist in calculating things.
Manager: All apps have to use this feedback framework now, no exceptions. Getting feedback is super important so we can be more Agile!
Dev: ok... uh, but this is 40x the size of all of calc.exe. Plus it's just a calculator and we've refined it for years so it's pretty good already. Isn't that kinda nuts?
Manager: metrics! Feedback! Agile! Just do it!
https://news.ycombinator.com/item?id=10791667
(Note that the "Calculator Plus" mentioned there has --- not suprisingly(!?) --- disappeared from Microsoft's download center, but you can still find the official, signed installer by searching for "CalcPlus.msi".)
Given all these factors, any product using web technologies for UI can move much faster than products which don't. Like how Sublime and every other programming text editor basically got eaten up by VSCode and Atom in about a year and half.
There is a very succinct rebuttal to that, and a good explanation for why apps based on "web technology" are they way they are: "quality is not quantity."
[citation needed] - web application development is incredibly complex and can't be compared to just "web development" (e.g. writing a HTML document or template and styling it).
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 the javascript it executes in order to control the rendering of its html/css, rather than the rendering itself.
(not to say that HTML and CSS aren't useful, but they are far from the idea means of rendering a UI).
HTML does work fine when you use it for mostly document focused work, and I enjoy the interactivity and connectivity that web browsers have brought to the web, but I'd love to see an improvement on it all.
If you discount flexbox due to "not [being] used very often", then you can't logically argue for burning down the HTML and CSS stack and replacing it with something else that has zero market share.
I'm not saying that we should burn the HTML and CSS stack. It has served the web very well and will continue to do so, but until the last few years, it's been a document focused stack that's been twisted into doing app development, and in some sense, it still is.
HTML and CSS are not the best tool for heavy GUI development, a la Photoshop, Visual Studio (not VS Code) or other large GUI intensive things. Most web apps have yet to replicate the combination of features and/or performance of those types native applications. Flexbox is an improvement there that helps with layout, but that doesn't change the fact that we are working with the DOM under the hood, with all of its various quirks and performance issues. (Not to say other GUI frameworks/APIs are perfect, or necessarily better. Some of them just allow you to optimize a little closer to the metal).
One can point out that large GUI tools like Photoshop aren't being created as much these days, outside of AAA game dev, CAD, or the like, or that many large GUI's use web views to help display documents, a la Steam.
I sincerely hope that Servo's "Web Browsers are essentially AAA game engines" approach catches on.
I'd be interested to see how an event-based html5 canvas GUI library would compare to DOM.
Q: How do you make an image maintain an aspect ratio and fill up the width or height of the screen, whichever comes first? A: Nested div hell and JavaScript.
Q: How do you make a scaled background image stay put even when the keyboard input pops up on a phone? A: Supreme JavaScript, CSS, and div hell.
Q: How do you center a paragraph of text vertically in a div? A: Nested div hell.
I'd say FlexBox is pretty inadequate. Why can't we have things like:
#my-video {width:80%;height:calc(width*2/3);}HTML/JS/CSS is just a stepping stone like any other, not an endgame. Don't grow complacent with it. Demand something better.
No it's not. If you want a fast full-featured cross-platform GUI toolkit, there are many: GTK+ and Qt are especially great, and have bindings for several languages.
However QML is an improvement. It was a bit quirky to get render the way you wanted and it was not native & look and feel, but maybe have gotten better since I used it. I could imagine that TypeScript + QML could be quite pleasant. Big downside is that the install size of your program is quite big.
I say that from the developer and the user perspective.
> Posted in Dev Loop, Qt Quick Controls, Styles
You might not like the envelope they are pushing, but they are cutting-edge explorations into web tech, coinciding with other cutting-edge developments like HTML/JS -> Native interfaces.
Just because js is good on web, doesn't - and shouldn't - mean that we should be doing that.
Of the 3, javascript is the most dispensable, there's nothing stopping us writing platforms which have UIs designed in HTML/CSS but have a DOM controlled by python/c#/ruby.
I was not suggesting we stop progressing, but we need to recognise the phenomenal amount of overhead involved in replacing these 3 technologies. What benefit would be served when they can just be abstracted on top of, at least with regards to the web?
Case in point, Assembly Language, we could theoretically replace the standards that have been reached over decades of collaboration with something more suited to our modern leanings. But what would be the point, when we've long since abstracted it out of our minds?
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.
Because they suck?
Yeah, like my favorite of these lately, widows and orphans. Chrome changed a default that affected inline-blocks within columns that caused them to wrap prematurely after version 52 or so. It is especially bad because the other popular browsers don't even support these yet and looked fine.
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.
I agree that simply saying X sucks is not a valid argument. Howeever with CSS/HTML the flaws are too numerous and already discussed ad nauseam over the past 15 years. Everytime a new version of CSS comes out, people go and try it and find out that it sucks, whether its th broken box model or the broken float layout techniques or the constant fiddling you are forced to do to get anything working. Every web developer I've seen adopts the 'edit and refresh' trial and error model of developing which is the direct result of a bad spec. Which also explains why there isn't even a reference implementation. As far as UI layout is concerned I am fairly sure I could out-compete a web developer in terms of time taken to implement, using something like IMGUI.
As someone who has spent years implementing those standards, a reference implementation would not help me at all.
> As far as UI layout is concerned I am fairly sure I could out-compete a web developer in terms of time taken to implement, using something like IMGUI.
Dear imgui's layout model doesn't scale at all, due to the fact that it's immediate mode. It redoes layout from scratch every frame.
Well, considering that the web has been for decades a landmine of subtle rendering differences based on different interpretations of the same standards, it would surely help others...
Also, I'm not sure what you're saying here. That, warts and all, you love the web as a programming platform?
Well, maybe you do.
But then again, you don't program everyday IN it. You program a rendering engine for it in Rust, so you're safely protected from the horrors of web programming.
>Dear imgui's layout model doesn't scale at all, due to the fact that it's immediate mode. It redoes layout from scratch every frame.
Aren't (or at least weren't) most computer games "immediate mode" too, and far more demanding than any web page?
Which isn't a problem if you're layout algorithm is fast/simple. If it's not, then it's a bigger issue.
I don't quite understand what you meant your comment to be indicative of. That nobody else would consider it useful? That you personally see no value in reference implementations at all?
>Dear imgui's layout model doesn't scale at all, due to the fact that it's immediate mode. It redoes layout from scratch every frame.
Could you detail the UI are you thinking of where IMGUI is inefficient but HTML/CSS isn't? Not asking for a formal spec, just a general usecase..
My problem with CSS/HTML is that productivity scales inversely when using them.
XUL is dead now, HTML+CSS won.
> everyone understands it and can work immediately with it.
I know which I'd rather offer as my toolkit of choice for a project on which I wanted lots of people to contribute code to!
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.
For instance I wanted to be able to display PDFs directly in VSCode. I went to look for a plugin, and there was one. People simply used "pdf.js" to integrate PDF support in VSCode. Because it is web based it should have been straightforward to do. Doing the same with native technology would have took several weeks of coding, and it wouldn't have been cross-platform.
Imagine all the web-based open-source tools that could potentially be integrated in these editors. Integrating a SVG editor in native text editors would be a nightmare. With web-based text editor you can potentially just incorporate an existing tool like [1].
There are lot of other examples like this: Live markdown preview, mini-map, color-picker, integrated VSCode debug panel, …
It is also quite easy to add visual stuff. For instance adding a vertical bar at 80 characters in the background is quite easy to do with web technologies. On the other side emacs has still not managed yet to make the html-mode work nicely with this "fill-column-indicator". It is also probable that it would be much more easy to integrate web services (trello, github, …) directly within VSCode.
At the end people wanting performances have already quite a lot of choice in native text editors (vim, emacs, sublime…), and people who prefer functionalities can go with web-based text editors (atom, vscode, …)
[1] https://svg-edit.github.io/svgedit/releases/svg-edit-2.8.1/s...
Actually, it would take one hour because you would use Poppler, and it would be cross-platform. It would also be faster than pdf.js.
I don't really know poppler. If there are Poppler bindings for the language you are developing in, I believe you that this is possible. This is only one use case though, I'm not sure you will find native libraries in your language for all features that VSCode can offer almost for free, like live markdown preview for instance.
Exactly. Web developers live in a bubble, and because they don't know much about native alternatives, they assume they don't exist.
Note: I'm a web developer and I don't know poppler.
You could have done that 20 years ago with COM components already. There was a thriving ecosystem where you could get a component for just about everything.
Similar technologies were available on other platforms than Windows, like Bonobo (Gnome), Kparts (KDE), and whatever Mac had.
It's a bit of a shame that component frameworks have gotten such a bad reputation (for complexity and insecurity), I think they are very misunderstood.
You know where else you could do the exact same thing AND have a 10x faster and 10x more memory/battery efficient editor?
If a native editor just gave you a webview that can run JS extensions...
Except for the startup time --- with which I can live with --- I never felt a difference in speed between native text editors ans VSCode. There is one, but I don't notice it. Human are much more slower than computers, so as long as it is not taking more time that I need to notice it, I don't care.
Nowadays my computer has enough memory so I can afford to not care about the 116M that VSCode is currently using, especially in regard to what my browser consumes, and in regards of the wide range of features it offers.
Battery could be problematic indeed, but before looking at my text editor, I would probably first switch from KDE to i3, and then use a lightweight web browser. This would impact it much more than my text editor.
> If a native editor just gave you a webview that can run JS extensions...
But then you start loosing all the benefits of faster/memory/battery points you mentioned.
Anyway, I'll happily try something like this if you develop it ;-)
This item is about VS Code consuming 13 % CPU when idle, which is bigger than the difference in idle CPU between KDE and i3 (if you don't have fancy widgets, it's about ~nil).
Try editing anything larger than a simple program file (from a large JSON to a CSV as devs often do) and you'll do. Try hex editing a large binary. And many other tasks.
I would suggest you to try VSCode for curiosity, if you have not done it yet. You could be surprised. Maybe it is not the right tool for you, but it is quite well made, and compared to atom, bracket or other web-based text editor, it feels like a supersonic jet.
I wrote a PDF viewer in Java(FX) in about one evening using PDFbox. There are also PDF components for practically any other desktop app framework you care to name, most of them older and more mature than pdf.js
The fact that so many devs express amazement at things considered utterly routine for decades is one of the reasons the entire web dev community is so often treated as a joke.
HTML has very few redeeming features as an app platform. It's way past time it gets killed by something better.
But I do believe there are more people comfortable with web technologies these days.
As far as I can tell I'm actually CPU-limited, because I noticed no real difference from when I had 50 mbps internet. This is on a quad-core Macbook Pro that boosts up to 3.5 GHz...
You not only have to build the code that supports all this, you also have to create and document an API and/or markup format to build all this out, plus document all your internal integration points.
If you want other developers to really take it up and build plugins, you have to make it easy to get into, so that means not just documentation, but great documentation, plus tutorials, examples and tooling to help.
You get a big chunk of that for free when you use HTML/CSS/JS.
Fire up VS Code, go to Help > Toggle Developer Tools, and poke around for a few minutes. Imagine the amount of time it would take to build a similar experience to just this one aspect if you were doing this from scratch.
Seesaw [0] - A nice-ish way of using Swong in Clojure.
Iup [1] - One of the friendliest GUIs I've used, hands down. Just feels like Scheme.
However, I'd expect that QML and X-Expressions could go hand in hand to make something much closer, with a bit more flexibility.
Don't do it from scratch then. You can use GtkInspector to poke around with any GTK+ application, by pressing Ctrl+Shift+I.[1]
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.
> 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
Note: I don't use VS Code or any other JS editor, I use emacs. But I can definitely appreciate the major benefits of the architecture.
both projects are open source if you care to verify
its a simple checkpoint and pretty much every actively developing project does this nowadays.
The whole experience is important. For many, it's more important than the individual 'feature' of being light on resources.
I currently ignore the fact that VS Code is 'heavy' as text editors go, because it's so much lighter than e.g. Visual Studio, leaving me much more RAM free for some of the code I'm running to gobble up and use for its own ends.
I'd prefer lighter 'weight' - in terms of RAM and CPU usage - but I'm not tempted back to Sublime yet.
BTW I'm a vi person, so I'm using vi keybindings in VS, VS Code, Sublime - and anywhere else I can do so. I love Vim's speed, but I can't Get Stuff Done in it like I can in more modern editors. I mastered the keys, not the inbuilt windowing system, scripting language, etc.
I really believe that if you find these vim plugins useful you don't really use vim all that deeply. that's not a criticism, just an observation.
Anecdotally I was able to create the cursor problem by minimizing/showing the VSCode window while viewing CPU usage DESC in task manager, but the effect was only ~2% usage for me (i7 processor).
If one invisible (from a UX perspective) bug is VSCode's big performance problem then I'll gladly let it eat away at 2% of my CPU until it's fixed.
I once wrote a visual PostScript debugger for NeWS, which I primarily used for debugging itself. [1]
[1] http://www.donhopkins.com/drupal/node/97
The PSIBER Space Deck is a programming tool that lets you graphically display, manipulate, and navigate the many PostScript data structures, programs, and processes living in the virtual memory space of NeWS.
The Network extensible Window System (NeWS) is a multitasking object oriented PostScript programming environment. NeWS programs and data structures make up the window system kernel, the user interface toolkit, and even entire applications.
The PSIBER Space Deck is one such application, written entirely in PostScript, the result of an experiment in using a graphical programming environment to construct an interactive visual user interface to itself.
One situation, I open 5k LOC file, scroll to the middle and bam colors are there everything was instant. In VSCode I open same file, slight delay, opens the tab, I click on middle of side codetree, slight delay, and few seconds for colors to draw. This is just one example. And there are those slight delays all over the place that I don't have with sublime, emacs or vim.
Especially with large files, but just in general. Speed is the main reason I can't stay using Atom for more than a few hours. It's awful.
VS Code is snappier than Sublime Text ffs...
Now if I was coming from a larger, probably Java, IDE? Yeah, I can see that Atom would look great.
Just wasn't for me. Glad you like it tho!
Sublime had the edge in a couple of cases, but when opening large files (esp JS bundles) it crawled. Took over a minute to open one.
Same file in VSCode - maybe a couple of seconds. Maybe.
Is for me. Not by a lot, and not in every case, but overall? Is for me.
There are a huge number of plugins for VS code. It's built to be plugin-centric - most functionality is a plugin.
...indexing...
...as I was saying...
Performance & bugs/quirks. I'd much rather have performance.
I mean, Emacs had jokes about being bloated decades before Javascript (and Java, another contender for these jokes) even existed. :)
I don't think running Elisp in Emacs takes away from it being "native." At least insofar as there are no popular text editors (that I know of!) which expect you to compile your plugins and macros to native code. They all have interpreters of one kind or another. What Emacs doesn't have, though, is an inner platform effect: Emacs is the platform, there isn't a second one underneath (no browser engine).
If you use a Common Lisp based editor like Clozure CL, Allegro CL and LispWorks have, they don't use a C-based byte code interpreted. The Lisp code is compiled directly to native code. Which makes editor extensions running in natively compiled Lisp code.
The advantage of the c-based byte code engine is compact code and improved portability - since the C compiler will already be provided with most platforms, whereas a native Lisp compiler is typically not something provided by a platform (CPU/OS/...) vendor...
If forced, I would say that Emacs-the-platform is native, and Emacs the system of Editor MACroS is not, since the macros run on the Emacs platform. But it seems kind of pedantic.
The number of lines of Elisp my Emacs uses (counting plugins, but also built-ins) is actually more than twice the number of lines of C.
It's not that "Emacs contains an interpreter", rather it's "Emacs has all these features written in Elisp [...a looong list here...] Oh, and it also has an interpreter to execute it all".
Some features like memory management (garbage collection) are layered on top of the OS.
The UI is not 'native' - it's based on a portable substrate written in C/Lisp, which works both on WIMP and terminal systems.
The user interaction is not native (commands, buffers, undo, preference dialogs, window/frames, ...).
etc.etc.
Let's just agree to disagree. We are talking past each other at this point. Best regards!
Because compiling code to the native instruction set shouldn't affect the semantics: so why should that be the only yard-stick for "native", right?
What is semantically relevant is: how much of the platform is exposed to the programs directly, versus through abstractions.
Suppose a language like Emacs Lisp or Java or whatever has only thin wrappers around POSIX through which applications interact with the platform. Then those programs are quasi-native POSIX programs, really. They are doing things like fork, waitpid, dup2 and whatever almost directly. And suppose that in the Windows version of that language, programs use functions that mimic CreateProcess or WaitForSingleObject. Then, regardless of the language being interpreted, it's really a native programming language.
As such I simply found emacs an odd choice as an example.
BTW: Notepad++ uses .dlls as plugins. (Which doesn't neccessarily make it a better editor than emacs :) )
Having said all that, I don't think that "non-native" is a pejorative. I use Emacs, but would switch to a "non-native" editor if there were a good reason. I use IDEA (native or not? you decide!) when working on big Java projects, and Emacs for everything else, because Emacs affords me a lot of power that I find lacking in other editors. "Nativity" isn't really part of the equation, it's really about functionality.
As such GNU Emacs is just as 'non-native' as a JVM-based editor.
Example: the calculator of GNU Emacs. https://www.gnu.org/software/emacs/manual/html_mono/calc.htm...
:)
They all support plugins and extensions, they are all super efficient in CPU usage, etc.
The thing is they aren't new, and because they are all C/C++ codebases developers wanting to add new features to text editors don't want to touch C++98 / ANSI C code from two decades ago.
Then you want to start talking about a C++17 / Go / Rust / etc text editor, but that is starting from scratch, and when you consider the time investment to develop the infrastructure of a text editor today vs just using Electron, the time investment makes less sense for hobbyist devs doing this stuff in their free time.
...is exactly the same. No matter what gui toolkit you use, you still need to develop the infrastructure. Electron doesn't know how to handle keyboard and mouse events, it doesn't have a text buffer implemented, has no understanding of different text encodings, how to parse different languages, and draw different colored text accordingly, or format it, etc.
As I understand it, sublime has tight enough integration with python, such that python can do literally everything you would ever need
I felt the same until I actually tried it out. That changed my mind: now I'll take any platform that those developers & contributors choose for their cross-platform products. Because this for an Electron app, this is a rock-solid 'old-school' (as in, fully as neat smooth helpful-yet-staying-out-of-the-way and somehow "ergonomic" as it was ever since at least oh late 90s, v6 or so) "Visual Studio experience". After a few years of sitting listlessly in front of subjectively inferior editors, I'm prepared & willing to give this Electron stuff more time to further mature improve and speed up. There's no intrinsic reason it can't get there. Lots of seemingly native apps are just live Lua/Python interpreters under the hood with widget bindings in place of a DOM. In that case, well-engineered JavaScript (terribly time-consuming to produce & pretty rare out there for those who like to rely blindly on a huge pile of unscrutinized 3rd-party snippets/script um-I-mean "repos" --- but not impossible) can fully deliver the same, in principle.
Seeing how VScode took off, that could even propel MS to invest unprecedented energies & talent into rounding up the JS "rich client app" performance story further. Who knows.
I don't need x-plat UIs, I just need a good UI toolkit period, and that's why I'm looking real hard at Electron for future desktop work.
I find many of the frustrations people have with desktop Cocoa come from the bizarre need to reinvent the wheel with a custom UI theme. If you stop fighting the system and instead go with a native look with well chosen accents, life is much easier. Native can look great with a little attention to detail.
Half the responses in this thread are people defending the stupid idea of "let's just use js everywhere, just because we can and fuck better suited tools".
Js is not the be all and end all of tools, just because it is used a lot in web doesn't mean it is the best (or appropriate) tool for other spaces.
It sort of seems like js/js ecosystem is built around hacky solutions to things, so I guess it makes sense that the community doesn't seem to see any issue with shoehorning in their language of choice into entirely inappropriate spaces.
Actually there are such editors. I use vim instead of vscode or atom. And I think my installation of vim is slower then vscode because of some plugin that I've not found yet.
Applications like vscode very useful because they help to find performance and other bugs in browsers. Same way as browser improved when gmail and sites like this appeared.
I would support appearance of IDEs, large games, VR, image and video editors in browsers as they help improve web platform.
If you don't like it, just use other option. It could be faster, but may be not. Not sure that vscode is slower then visual studio for most tasks.
They're sexy, they are powerful (extensions for everything), portable, and extremely easy to extend thanks to Javascript being pervasive. I don't know for certain but I'd also assume writing an Electron app is easier than writing a similar app in a lower level language.
Is it really that hard to grasp? Performance has to be perceptible by the average person for it to affect user base. I prefer WebStorm but I've had absolutely no issues using VSCode on my laptop - which feels even faster than WebStorm.
Every dark theme I can find makes the background dark gray, not black. I actually looked into what it would take to make a new color theme and I simply don't understand all the steps, and definitely don't want to deal with the hassle. It very quickly goes off into the weeds of TextMate themes (huh? Why are we referencing a Mac editor? Yeah, I know it's a de facto standard, but really?), editing XML (complete with hex codes for colors) and installing something called "Yo Code". Dude, I just want to change one friggin' color!
In every native app I've ever used, I can just go into the Options and make the background black, period.
Just because it's a programmer's editor shouldn't mean you need to be a programmer to make the simplest configuration.
Better in what way? The market has voted with their downloads, they don't agree that the problems with Electron apps are as bad as you feel that they are.
And I still see native editors used more (for example latest StackOverflow survey, showed that Notepad++, Vim and Sublime combined are used much much more than VScode and Atom combined). I don't want't my editor to crush mid session, or have to write bunch of gulp files and npm commands to do one simple modification.
This all boils down to the art of "it's good enough". Take game development for an example. You could write an engine from scratch using Vulkan APIs and all that jazz and run at 144fps@4k on a toaster. Or, you know, you could trade off the performance and settle for just using Unity and optimizing wherever possible. It's not as fast, but as long as the user is not frustrated by it, who cares? You just saved a lot of development time. Tradeoffs, tradeoffs.
Same thing applies here. The VSCode team did a damn good job of keeping performance just about over the "good enough" threshold of most of its users, <flamebait>unlike other Electron based applications</flamebait>. Of course, that threshold varies based on the user and his machine, but outright dismissing VSCode based solely on the assumption that editors cannot be written in html+js is simply short-sighted.
I say this as an Emacs user.
I would, but it's still swapping back into RAM.
(For real though: yes, I use it all day)
That matters when I just want to do quick edits.
Vscode takes 3.
To prove this, this command:
time emacs -Q --eval "(kill-emacs)"
My normal Emacs, just as yours, needs ~12 seconds to start up. But I made it this way by explicitly enabling and requiring things. I could, with some effort, get the time down to 5-8 seconds (byte-compilation and gathering autoloads in one place), and even back to around a second if I was desperate enough to try dumping the image of a running Emacs to disk (I did it once and succeeded, although the process wasn't pretty). I don't do this because I don't care that much, but the option is there.
Admittedly this is a corporate laptop with all their virus crap running, so no editor is fast. But emacs in particular has very bad startup times for me.
But I definitely don't ever recall it being 8 seconds, that feels like either an exaggeration or someone working on a potato.
Haha, no. It depends on what you use Emacs for. Remember the old joke about Emacs being a great OS? The reality is that Emacs is a great computing environment for almost anything that deals with text and even for some completely unrelated things. If you want a cross-platform GUI then Emacs Lisp may be one of the choices available.
This caused "plugins" - Elisp applications - to flourish and over the years a lot of code was written. Long story short, I have ~640000 (not a typo) lines of Elisp in my ~/.emacs.d/ alone, not counting the built-in Elisp libraries. It takes time to load that much code, even if it's byte-compiled beforehand.
The 1-2 second startup was slow enough that I couldn't even stay with the Emacs evil mode.
There's plenty of competition in this area, so if electron-based text editors have enough downsides, people will use something native (as your comment indicates). If that wasn't the case, and we could only choose from electron text editors, then we would have a problem.
I think we should look at performance and resource usage as features on the same level as other features. Those things have to be balanced against whatever else the tool is bringing to the table.
I used Atom for a while. But as my projects got bigger, I got to the point where I was bothered by its slowness, crashes, and choking on large files (not even that large, honestly). I find sublime much better in these areas, so I switched. Looks like a healthy ecosystem to me!
Maybe I don't have any 250MB files to open?
If VSCode doesn't fit your use case, don't use it. There are innumerable alternatives. But what purpose does it serve to tell the rest of us (who like it) that it sucks?
You also appear to be falling into the developers are not users trap.
but hey, at least you can write code on a toaster oven, eh?
All joking aside -- I use VS Code on a 7 year old laptop, and it doesn't lag, or stutter at all. Performance is just fine. There comes a point where the hardware greatly outstrips the requirements to the point where it doesn't matter if the resources being used seem 'too much' for what it does.
> or example latest StackOverflow survey, showed that Notepad++, Vim and Sublime combined are used much much more than VScode and Atom combined
By this metric Notepad++ and Visual Studio (not Code) are the best editors because they topped out of every category (except Vim for Sysadmin / DevOps). If you look at the "Desktop Developers" tab, Visual Studio Code is actually in 3rd place behind Visual Studio and Notepad++. With Vim and Sublime a few rows down and Atom even further.
There's no way in hell Visual Studio (not Code) is faster than Vim, but how come it dominates it in all but one categories?
1 post found.
Oh, this comment.
I agree. However, as someone who has used Visual Studio (the one that costs $$$, not VSCode) which is a native application (AFAIK --- it probably has some .NET and web components too), I can attest to the fact that even native applications can be extremely resource-consuming and slow.
There are plenty of native-application (or JVM/CLR) text editors and IDEs, too. For lots of usage patterns, the browser-engine-based ones have acceptable performance, and the number of people with expertise building for web contributes to the speed of development on those editors and their plugins.
But, sure, if you don't like Electron-based editors, there are plenty of other actively-developed editors for you to choose from.
There's a beautiful poetry to being able to do web dev inside a web application.
I still have Sublime text for when I need to view/edit files with tens of thousands of lines, since Atom chokes on large files, but otherwise I have zero regrets :) I'm as productive in Atom, and it's a more pleasant experience.
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.
So I guess it makes sense to optimize for maintainability i this case, i.e. not having one codebase per native OS.
The real reason to me though seems that it's just the easiest way to make a cross-platform UI. And in this web powered world, everyone knows how to code html/css, so why relearn a bunch of new tools?
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.
I use VS Code pretty much exclusively these days myself, so I'm not picking on it by any means.
[0]: https://github.com/jhallen/joes-sandbox/tree/master/editor-p...
I don't care if it's written on to of a browser or in assembly. I just know it's the best text editor I've used so far.
Java Swing. Never again.
edit: Do people downvoting even know what it's like building cross platform desktop applications using Java Swing? It's fucking awful, and that's a fact. Even the end result UI design look & feel is butt ugly. Sure you can spice things up with JavaFX but why? Do you not realize how masochistic it was back then vs now with thin web browser clients? Can't believe people are still thumping Java Swing in 2017.
Also, for Java there's JavaFX (a de-facto standard UI toolkit for Java), which is very nice to work with.
The ancient history of the web, clearly, is different, but the modern web stack, both in terms of specs (WHATWG HTML/W3C HTML5 and related standards) and modern browsers are very much engineered for applications, not just classic documents, as a primary use case.
Yet, what they fail to realize is they are comparing a webpage to an application. An application contains information about the state it's in. Handling the application state has always remained complex and it has been two way coupling to the presentation layer making life more difficult.
The latter is why Javascript is perceived to be "over engineered" by people viewing it nothing short of "fairy dust on ugly document pages" which is absolutely incorrect way of viewing application development.
I used to be the biggest Javascript skeptic but once I realized the intent behind React/Redux/Vue.js, it changed my perspective and have started treating it with more weight and respect.
Once that paradigm shift happened in my perception, I found it a lot easier to navigate and endure the fragmented tooling and endless variations of npm modules.
Because I realized that it's going to get better eventually and it's here to stay. Young people aren't learning Java & using Maven on Eclipse or Netbeans anymore. They are on Atom or Visual Code, writing Javascript.
Javascript is essential knowledge, along with AWS. Software engineering has changed in the past 20 years like it or not.
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
I've done web UI dev. I've also written code using GTK, Qt, Windows, Swing and JavaFX. A good modern UI toolkit like JavaFX or Qt blows the web stack out of the water on almost every metric. Developer productivity, correctness, speed ... you name it.
> webapps are essentially a pile of ugly hacks on top of a document rendering engine
That's your own opinion. You claimed Java Swing & FX was the correct way and that thin clients like Electron is wrong. I disagree.
If Swing was meant to do UI then it's probably the most awful and inefficient way to do it.
If Web was not meant to do UI but it's the fastest and more efficient to work with than Java.
It's a matter of opinion but with starkly different development experiences. Sure, you can build using Java Swing/FX but you are going to get a completely different demographic and developer culture...one that is still ingrained in the era it was released.
With JavaFX where you can customize it using CSS it looks nice, and you don't need to use a scripting language to do it.
Here's a easy way to get a job done but people refuse to do it because of philosophical/ideological indoctrination. ex. the world is made of objects therefore our languages and how we build software should now mirror it.
(I do prefer the webstack over Swing)
Only when developed by those devs that never bothered to read books like "Filthy Rich Clients".
>Even the end result UI design look & feel is butt ugly
You know what else is butt ugly? Programmer art and UI.
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.
I don't want people without education building my IDEs and other software I might rely on.
The VS Code team have done a great job, and this bug will die. But, I'd say it's more in spite of the platform, than because of it.
When using QT for a highly modular editor be prepared to code QT components from the lowest level. It's not like you take a QT widget and modify it on a simple way. Trust me.
If you think it is easy to code editors look e.g. at the people who write letters and their custom editor tool: Microsoft Word. Now look at the many competitors this program had and how many behave super speedy on all plattforms.
The real problem is this new generation of "developers" that only know Javascript. When all you have is a hammer...
Wouldn't it be better to make native application, especially for code editors, where developers spend most of their time, where every noticeable lag and glitches are not appreciated.
Edit: Many people here think that I am attacking this web based kind of technology, which I am not, and sorry for not being clear enough, but why chose something so high up the stack for dev tool?
Edit2: For non-believers in nested comments, look -> https://github.com/jhallen/joes-sandbox/tree/master/editor-p...