Really weird closing remarks at the end. The bigness of VSCode is because of the HTML- and CSS-related stuff, not the JS part, which relatively speaking can be tiny (especially if you're willing to stick with ES6 or thereabouts). Compare: Electron vs QuickJS.
The number one reason for not-JS in 2024 is because you can slough off the entire cohort and set of development practices that have calcified around _NPM_ which is about the same reason you'd have wanted to shed the baggage of "Java" in 2004—the mainstream is a magnet for low-quality output held to low standards.
> However, I also think we're lacking text focused environments for smaller scale programs, the equivalent of shell scripts or BASIC programs.
I actually think Emacs is the perfect environment for this. Not only that, but Emacs can go on an even smaller scale: keyboard macros. For example, I've performed keyboard macros to update data with a combination of Emacs HTTP request modes and org-mode. And this is all doable because of Emacs' text orientation.
I think there is a socioeconomic problem regarding the wholly text-based environment:
It's too good for the user so it can't exist!
If you have it there are no problems left for anyone to profit upon.
Something like this is nirvana for me:
* The email arrives in the client (which is my text editor/IDE/whatever)
* There is a macro or hotkey which transforms it into a piece of text that is a representation of a JIRA ticket (yes it's tragic that I have to use JIRA)
* I review, hit save and the JIRA ticket is updated/created
* There is another macro which transforms it into a Git commit, Slack message, etc.
But the world is not like this, hours of our work day are wasted manually copy/pasting, massaging and reformatting our information between different walled gardens and different user interfaces, imposing new cognitive load every time.
Let me just have a set of templates in my text editor which do this transformation, I review it and hit save.
Emacs is the only application which has any meaningful traction and approaches this type of scenario: a generalized collection of buffers where your computer is just pushing text around for you and interacting with other bits of software to persist those changes in different ways (generally easier if text is the interface for those applications too). I think it's no coincidence that Emacs comes from GNU.
If all these things are just text in my main environment, there aren't many problems left that people can sell me. Import/export of proprietary file formats is a classic way to lock people into an ecosystem. SaaS APIs are a more modern one. If all this is just text files editable by me, if the interface is universal, the lock-in fails.
Give me text I can transform in my powerful editor. For a power user at least, everything else just gets in the way.
This is a place where I think LLMs might develop some legs by the way. Most applications need to accept text or at least keystrokes from the user sooner or later. LLMs seem to be pretty great at transforming text between two formats/vocabularies/whatever - maybe one working for me can do an end-run around the walls that proprietary systems erect, and make it easy to perform these transformations I'm talking about. Maybe your operating system vendor sees this as being the next step in the arms race between the different companies competing for your attention.
Really weird closing remarks at the end. The bigness of VSCode is because of the HTML- and CSS-related stuff, not the JS part, which relatively speaking can be tiny (especially if you're willing to stick with ES6 or thereabouts). Compare: Electron vs QuickJS.
The number one reason for not-JS in 2024 is because you can slough off the entire cohort and set of development practices that have calcified around _NPM_ which is about the same reason you'd have wanted to shed the baggage of "Java" in 2004—the mainstream is a magnet for low-quality output held to low standards.
> However, I also think we're lacking text focused environments for smaller scale programs, the equivalent of shell scripts or BASIC programs.
I actually think Emacs is the perfect environment for this. Not only that, but Emacs can go on an even smaller scale: keyboard macros. For example, I've performed keyboard macros to update data with a combination of Emacs HTTP request modes and org-mode. And this is all doable because of Emacs' text orientation.
I think there is a socioeconomic problem regarding the wholly text-based environment:
It's too good for the user so it can't exist!
If you have it there are no problems left for anyone to profit upon.
Something like this is nirvana for me:
* The email arrives in the client (which is my text editor/IDE/whatever)
* There is a macro or hotkey which transforms it into a piece of text that is a representation of a JIRA ticket (yes it's tragic that I have to use JIRA)
* I review, hit save and the JIRA ticket is updated/created
* There is another macro which transforms it into a Git commit, Slack message, etc.
But the world is not like this, hours of our work day are wasted manually copy/pasting, massaging and reformatting our information between different walled gardens and different user interfaces, imposing new cognitive load every time.
Let me just have a set of templates in my text editor which do this transformation, I review it and hit save.
Emacs is the only application which has any meaningful traction and approaches this type of scenario: a generalized collection of buffers where your computer is just pushing text around for you and interacting with other bits of software to persist those changes in different ways (generally easier if text is the interface for those applications too). I think it's no coincidence that Emacs comes from GNU.
If all these things are just text in my main environment, there aren't many problems left that people can sell me. Import/export of proprietary file formats is a classic way to lock people into an ecosystem. SaaS APIs are a more modern one. If all this is just text files editable by me, if the interface is universal, the lock-in fails.
Give me text I can transform in my powerful editor. For a power user at least, everything else just gets in the way.
This is a place where I think LLMs might develop some legs by the way. Most applications need to accept text or at least keystrokes from the user sooner or later. LLMs seem to be pretty great at transforming text between two formats/vocabularies/whatever - maybe one working for me can do an end-run around the walls that proprietary systems erect, and make it easy to perform these transformations I'm talking about. Maybe your operating system vendor sees this as being the next step in the arms race between the different companies competing for your attention.
It’s not missing. Acme is still around, albeit certainly not in a very palatable form to modern tastes and platforms.
Anvil editor is a great acme replacement.
http://anvil-editor.net/tutorials/editor-layout/
[dead]