- In the Git view, select a modified file, select some lines of code you modified, cmd shift P, Git: Stage Selected Ranges. I dropped my dedicated Git GUI since I know this trick.
- If you spend a lot of time coding in React, and have half of your files named index.js, do yourself a favor, go in the settings and add "workbench.editor.labelFormat": "short" (display the name of the file's folder in all the tabs)
- You can preview markdown files natively (button at the top right corner).
I keep hearing good things about VSCode. If I weren't essentially married to emacs I'd definitely try it out. I'm not sure I'd recommend emacs to everyone at this point, though I think it remains a really solid choice of editor/OS for people willing to get over the learning curve and put up with a bit of clunkiness.
Re the git stuff though- one place that I'm pretty sure emacs is the uncontested champ is in git integration via magit. I'd be inclined to recommend using emacs as their git interface even to people who want to use a different interface for everything else. It is that good, and IMHO the only git porcelain that is strictly better than the standard git porcelain.
I started playing with emacs 24 years ago, then spent 20 years as a devoted vim user with a two year work-enforced gap in Eclipse. I tried spacemacs in evil mode about four years back and stayed for magit. I tried VSCode a few weeks ago to see what the fuss was about and had my Eclipse PTSD triggered. Magit, mu4e, elfeed, eww, multiterm, restclient.el, tramp, [edit]org-mode![/edit], the list of replacements for bloated "native"- and surveilling web-apps keeps growing. I mentor an up-and-coming developer who has learned more– about git, the filesystem, shells –in four weeks of using spacemacs than the 23 months of using Atom and VSCode. I know emacs in evil mode makes me smarter and more productive, and I'm seeing anecdotal corroborating evidence in my community.
There's an old joke: "Emacs is a great OS, but it lacks a decent text editor." Only vi users are allowed to tell that joke with a straight face, IMHO.
Evil-mode solves that, and just as magit is better than git evil-mode seems, to me, better than vi. Emacs is better than ever (though you do need to use auto-formatting for languages like JS that change a lot- there is no emacs mode that has kept up with ES whatever. Luckily emacs makes it easy to use formatters like prettier on a per-buffer basis.)
I am using vim for years now, and I haven't written more than 50 lines of vimscript apart from the bundles. Most of the thing that I have written is just maps, some configuration for other bundles, and some copied better defaults. I still don't get it when people say they heavily use elisp. Can anyone give example of a highly custom thing that you do in emacs/vim/any other editor, for which there is no famous bundle available.
The question is not elisp v. vimscript but rather the power of not having to switch contexts. To write code for a locally-hosted RESTful API I used Chrome to read the API docs, Postman to make the calls, iTerm2 to start/restart the server and read the logs, and a text editor to make changes. I replaced that flow with eww, restclient.el (amazing!), multiterm, and an editor buffer. No changing of context, conserve about ~1GB RAM in Chrome instances, full-screen if I want it, and everything is text (I'm looking at you, Postman).
On the "highly custom" level, I have a work-in-progress script that takes a URL, sends it to a Splash server, and returns the rendered HTML to eww for viewing. This is great for annoying SPAs like the article that spawned this conversation.
My current goal is to swap out my development MBP with an eInk tablet and bluetooth keyboard. Success will be measured as a function of productivity and weather-/water-/environment-proofing of the device; the goal is productivity in full sunlight and/or under water. Emacs will have a central role in that. Just need to find an eInk device with adequate screen refresh rate and Bluetooth support....
I'm using Org Mode to write my thesis and, although most of the functionality I use comes from vanilla org mode, I do need to write some Elisp to get the LaTeX export working properly, and to knit different projects together into a single one.
As another example, it took me less than 30 lines of Elisp to get Apple Music incremental searching from within Emacs. A highly custom thing that I don't get elsewhere.
I think you've assumed the wrong premise. At least for me. It's not the highly customised things, it's the accumulation of the small things that are either missing, inconvenient, slightly annoying or somewhat different to your needs.
Every package developer makes choices about how their package works (and built-in behaviour too), but sometimes that clashes with what you want, or is somehow inadequate.
It's those small conveniences that have a disproportionate impact.
I'm not saying you can't do similar in vim or there aren't other ways to achieve the same goal, I'm saying that over time, those minor improvements have a huge impact.
Here's 2 examples:
1) Splitting a window horizontally by default splits 50:50 but on a 16:9 monitor I usually want the new buffer (right) to be smaller than my current buffer (left). So I override the defaults.
2) I use paredit for lisp based languages, but (as far as I'm aware) there's no built in-command to copy (or paste) the s-expression surrounding the cursor's current position.
I often find myself wanting to do exactly that e.g. in a let or a cond form in Racket. So I wrote a couple of small functions to do just that, bound them to keyboard shortcuts and I've now made a minor extension that fits exactly what I want to do. Since lisp is based on s-expressions it turns out this extension to someone else's package is incredibly versatile and useful.... TO ME!
(let [<CURSOR>(x (some-function with args)]
I press my chosen key-combination and it becomes
(let [(x (some-function with args)]
[<CURSOR>(x (some-function with args)]
In vim, when you're in visual selection mode, you can type `ib` (inner block) to select the innermost parenthesized block's interior or `ab` to include the parentheses. If you type these commands multiple times, the selection widens to the next, next, next ... enclosure.
There are other similar commands in the category, like a" for selecting the interior of a double-quoted literal and such.
They are documented under ":help visual-operators".
I wholeheartedly agree: Magit is that good, really. The way I see it, it reduces the burden associated with carrying the required git mental model in your mind, by giving you easier points of entry into its complexity. I owe all the slightly more advanced things I now routinely do with git (which would probably be seen as pretty basic by a lot of people though) to Magit, without question.
Yep- I was reminded of how much I like magit by this thread so I just made a $100.00 donation to its development. I hope it inspires other people to at least give magit a try (if I'll donate that much it must be good, right?)
Yep- I'm actually a pretty old hand when it comes to git, and I know most of what git can do, but... I'm lazy, so when I use git at the command line I do caveman git. Magit lets me remain lazy and do subtle git things,
I'd say it's uncontested if you like using emacs. Because - for me - it's awful. Mostly because I find using vim or emacs awful and only use either of them when I absolutely can't avoid it.
But that said - it does it's job very well and magit is certainly excellent software for those that are interested in that interface.
No... I mean I hear you about not liking emacs/vim/evil-emacs. I happen to like evil-emacs, but I can see why other people would prefer VSCode. That's a matter of taste, and I won't tell people to switch.
But when it comes to magit I'm not so sure. I'm inclined to think that magit is _strictly_ better than any other git interface, so much so that even if you don't like emacs you should suck it up and use magit as your git porcelain, even if you use a different editor for everything else. Magit is that good- I just gave $100.00 to the project, and I never donate to open source stuff. It is that good.
Again - having used Magit because I heard the same effusive praise - it’s goddamn awful if you don’t like using emacs.
I don’t mean “it’s not my preferred git client”. I mean “I’d rather use almost anything else”.
Why? Because it requires emacs interface, concepts, and controls. And unless you’re ok with those it’s not better at all. In fact it’s _strictly_ worse.
That said: if you like emacs I think you’re correct, it’s almost certainly the best there is.
I think it's genetic. Whatever allele is responsible for emacs affinity, some people have it. It never ceases to amaze me how early in their studies they latch onto emacs and start doing increasing amounts of their computing through it.
Others, such as myself, suffer it only when compelled by an instructor.
IMO it certainly takes some learning curve to get up to speed with the keybindings and concepts. In the beginning anybody would struggle but after the learning efforts you'd find it to be much more productive than the other editors.
My favorite is multi-selection mode. It's not the same as "Column Mode" you find in other IDEs but try it and you will never want another editor again:
(Option)Alt-Cmd + Down or Up arrow key
From there, you can use arrow keys as normal, but instead of controlling one carrot, you control all the ones you created. So if I use the shortcut key to move to the next word, they all do, same with end of line, or what have you. In the past I had to use regex in my editors to extract quoted text in each line... now I just use multi-select. Each carrot can also be created with the mouse in the Selection menu.
Edit: Apparently it's a feature lifted from Sublime and in other IDEs - thanks!
This exists in most editors I've used (intellij is alt + shift + click or double tap alt, if I recall). I don't know how people program without this feature - they should teach this shit in school.
Multicursor is amazing.
One thing it's been great for:
I have code like:
byte b1 = array[0];
And I want to do this for 16 bytes. Control + D to duplicate 15x. Double tap control, hit up 15 times - now there's a cursor at every row. Hold control, hit right (jump by word), index to end of 'b1' on each line. Ctrl + shift + a, 'increment duplicates' - now every line is 1, 2, 3, 4... 16. `ctrl + right` my way to the index key and do the same thing.
I think loop unrolling is super cool. We're typically trained in programming to try to eliminate the kind of reuse that unrolling typically looks like, but when applied properly it can work really well. I guess that applies to most tools, though.
What actually brought it to mind was a hardware class where we were instantiating a bunch of the same module but didn't have a programmatic way to do it with our tooling. So...sorta like loop unrolling :)
All of the languages I can think of rely on the compiler backend for loop unrolling, which means it isn't a guarantee. You might want this if you need to guarantee the unroll.
But I wasn't doing this for a loop unroll.
I had a fixed size array that I wanted to serialize/ deserialize to/ from capnproto - there are no fixed size arrays in capnproto, so I wrote a message that just had b1, b2, b3... b16, and then some code to pull it out into a statically sized array. It allowed me to pull a bunch of bytes into a much larger statically allocated array without any allocation or bounds checking.
I don't know how people program without this feature
You must do some kind of programming I've not encountered in my many years. While my editor of choice can do this, I would have no idea how, because a feature like "increment duplicates" is needed so infrequently that I would never remember the shortcut.
It's one of those things that is incredibly useful. Of course it's possible to survive without it, but it's like saying "I don't know how people program without Copy and Paste". It helps.
Copy and paste is something that I use many times a day, even when I'm not programming. Needing to do the same edits over multiple lines doesn't happen often in my code.
There are appropriate plugins available for my editor, but I've never felt the need to install them.
Don't write in some insane boilerplate-driven programming language in the first place. Anyone proliferating this kind of duplication (whether with multi-cursors or shell here docs or any other way) should be flogged.
I've got to agree. It's one of those things that could save me a minute of manual editing every once in a long while, but I feel like there have to be lower-hanging fruit, in terms of increasing my editing speed.
Yea, I have the mac bindings, and for me it's opt-click to add a cursor, and ctrl-g to select next duplicate of whatever I select. You can even do stuff like "move left 1 word" or "move to begin/end of line" and all cursors follow the same behavior, possibly with different movement-distances. Utterly trivial refactorings in any language (including english), and always feels far easier to understand / predict than Vim's record-and-replay (as useful as it is), especially since you can see the results in every instance as you type.
I've been using it in editors since well before VSCode existed. It's very nearly a requirement for me to use an editor now.
I haven't tried this feature on VS Code, but isn't the record and replay macros feature in Emacs(normally bound to F3 and F4) a simpler(and more general, since seemingly it can record arbitrary text transformations) approach to achieve a similar effect?
I'm not sure where this feature originated, but it's been a core feature of Sublime for as long as I've used it, and is also broadly available in other editors. Definitely not a VS Code-specific thing, though it's still great!
I doubt it's where it originated, but I was using multi-select/multi-caret editing in jEdit before Sublime came around.
That and arbitrary window splitting (split any pane horizontally or vertically) are two features I really miss when they're not present. The latter's surprisingly hard to find; Sublime and VS Code don't do it (Atom does).
Editors like n++ have column editing, but Sublime takes it to a different level. It's most generalized, it's multi-cursor.
You can for example put your cursor on a word, spam ctrl+d (of press alt+f3) to select all instances of that word, and start editing them all at ones, no matter where they are. They don't have to be perfectly in a column. You can also copy X items from anywhere, and if you have X cursors again somewhere else and paste, they'll each go in their respective slot.
I believe it is the same functionality as in Sublime, IntelliJ, Eclipse and others. It's a total lifesaver when editing bulk stuff, like a lot of constants and what not! One of my must-haves in an IDE.
In Emacs this feature is called multiple-cursors: http://emacsrocks.com/e13.html – Emacs got it after Sublime. But I find I typically get things done faster with keyboard macros, or maybe I'm just too stuck in my ways :)
Sometimes I have 2 alternatives for a piece of code, one commented out and the other not, and I'd like to toggle between the two. With multicursor I just select both and hit `ctrl-/` to toggle them on and off.
I've had issues in IDEs where they have shitty implementations of multicursor that break that example.
I recently discovered a vscode extension literally called "Insert Cursor at Beginning of Each Line Selected".
Super handy when you want multiple cursors to line up at the start of every line (by default vscode will wrap the cursor around to the end of the longer lines if you try to move around with the arrow keys).
It saves a whole keypress (because you need to go into multicursor mode first, then press Home / Ctrl+A to get to the beginning of the line.
Additionally, there is a case where if you don't select the last line until the end, you end up in a state where the last cursor is already at the beginning. If you press "Home" now, you end up having that last cursor at the beginning of the line - and the other ones at the indentation level (see https://github.com/Microsoft/vscode/issues/14919#issuecommen...)
(Disclaimer: Author of the mentioned plugin, so I am heavily biased against my own workflow and saving-keypresses-obsession :P)
My favorite is when you have a git merge conflict - just open the file in VSCode and you can visually merge it. I can't explain the feeling of joy I had when I discovered this - and this keeps happening over and over with VSCode.
I've noticed this too: builds are faster on Linux (I assume because of the longstanding perf issues with directory traversal on Windows), and some of the GUI elements on Windows are blurry, apparently because of Chromium issues with High DPI that are outside Microsoft's control. I imagine some manager at Microsoft rips his hair out over this, but their loss is our gain.
I meant the suggested addons on that page, not VS Code per se.
I'm also using it as my main editor on my Windows box at home where don't do serious development.
My only real annoyance is that I seem to run into multiple addons that can't be properly installed for one reason or another and sometimes "Ignore this" doesn't work and then the popup gets stuck and you can't see the top three lines...
Apart from that it's been really nice for Rust, Go, and Python.
Yeah I just noticed. Just reinstalled the 64bit version instead of the 32bit one. (Apparently it's one of those applications that act a bit wonky if you're using multiple users on Windows.. it wasn't in the start menu and the Binary was in AppData, so I thought I'd need to reinstall it - but first I had to uninstall the old one.. same with Discord...)
I like the idea of using VS Code for my C and C++ work but last time I looked at it I lost interest looking at the length of the setup page for tasks.json and all that to get a C++ build toolchain configured. Is this still the case? Why can it not be more automatic like pretty much every other editor for supporting GCC or cl.exe?
What is your setup? Is it system wide or do you configure it manually for each project/workspace/folder?
Not sure. When it comes to C++, I haven't used VS Code a ton. I think last I tried, it didn't really have much integration with my build configuration, and mostly I had to hand-configure the flags via VS Code configuration. Jetbrains CLion is probably advisable if you want good Intellisense on a large CMake project.
If you're like me who prefers having million tabs open you'll find vscode to be much easier on memory usage with multiple project windows open. Also the extensions are nice although i do not know how good they are versus intellij.
Maybe it's a workflow fail on my part when using VSCode but I like IntelliJ's multi-project handling very much (it mainly boils down to: one window per project, and if you relaunch it it will remember your open projects/windows, but also a few other small things.)
I'm an evangelizing convert to Prettier. I was hesitant about it until I tried it, but... I am sold on it now. Prettier has costs- there are cases where I'd like to format things based on semantics not syntax, to show intent, and Prettier can't read my mind (feature request: make Prettier read my mind.)
But the costs are more than offset by the benefits. I didn't realize how much of a cognitive burden thinking about formatting was until I stopped thinking about it, and it turns out that using formatting to signal intent is perilous when people don't agree on how formatting signals intent.
I'm pushing to have Prettier used across all our JS code- there is some resistance to the idea of running it across a several hundred k line non-prettified codebase and some resistance to the idea of using it at all. And this causes problems. Prettier is best when you use it for everything.
But I'm pretty sure we'll eventually just move to prettification. It seems like the right thing to me, and I'm generally right ;). Anyway, thanks for Prettier- I am not actually a huge JS fan despite mostly writing it professionally, but Prettier does away with some of my complaints about JS, and just generally makes my life easier.
Well deserved! I was amazed at how much of a game changer a automatic code formatter was. Saves me a ton of time.
I do prefer adding a .prettierrc to projects, though, instead of inside vscode options (user or project) like what is suggested here. That way my teammates and I can use the same settings, even if they don't use vscode.
Prettier is the greatest thing since sliced bread for the frontend world. Seriously - not having to think about formatting (esp. breaking lines!!) is a huge boon to development
One thing I really miss in VSCode is Sublime-like search result display in a new tab that shows the result and surrounding lines.
The "panel" search results view VSCode has now is far from perfect.
It used to be that normal mode was an underline cursor and insert mode was a vertical cursor, but now that I guess vertical cursors are everywhere, Sublime switches between a vertical cursor for normal mode and an underline cursor for insert mode. A bit of a drag, but I don't use insert much at all.
One thing I'd like from the past is a blinking block cursor.
As a vim guy, and I say this because I think it makes more sense in vim, I think you mean insert mode (the “normal” mode) and replace mode (the “insert” mode). The fact that the insert is used to toggle out of the default insertion behaviour seems to add confusion.
I do maybe 10% of the time as it saves a few keystrokes if you are renaming stuff. I would be annoyed if it went away. But definitely not as useful as it was 40 years ago.
But "keystroke" is a very strange metric. In terms of speed, it's often much faster to just ctrl+a and rewrite it from scratch. The mental gymnastic in trying to compute in your head the difference of characters is definitely non-trivial. It only really works if the thing you're replacing has the exact same number of characters in it.
Can you explain the exact scenario you use it in, I honestly can't think of a scenario where insert is useful.
Are you trying to tell me that the computes I do in my own head aren’t efficient? That’s pretty funny as I even have a tough time measuring that.
It’s hard to come up with exact examples because it’s actually subconscious and as automatic as touch typing for me. Thinking back, when I’m on one line with the cursor maybe halfway through, I’ll hit down arrow, alt arrow to the word I want to rename, hit insert, type over it, hit insert. I think I did it when trying to clarify some documentation. I’ll be on the lookout in the near future, but unlikely to report back here unless it happens to happen really soon.
The opposite, I'm saying that your brain might be way more efficient than mine if you can pull that off, because whenever I try to use insert mode, I have a brainfart and get way confused.
See, at least that's not as bad, since you're basically going Capslock -> letter -> capslock, so it's easy to get your brain used to that. With insert mode, you need to think as fast as you type about how many letters you're overwriting.
I've been using computers for over twenty years, and I'm still yet to use the insert key on purpose. My AutoHotkey profile actually suppresses the keypress entirely, along with some media keys.
tbh I wish editors would get rid of "log breakpoints". Teach people to use the conditional breakpoint and just enter `console.log(...)` instead, it's overwhelmingly more powerful. A specialized "log breakpoint" doesn't teach them that it's just code. (I've run into quite a few programmers who have known about log breakpoints for years, used them fairly heavily, but never knew you could do things in conditional breakpoints)
Want to collect all values of something as your code runs? conditional breakpoint: `x = (x || []).append(val)` and then print it whenever you feel like it. Log breakpoint? spit it out each time and... browse by hand? hope nothing's logged in between? bah.
I've never even seen log breakpoints before but is it really just a wrapper for inserting console.log()? That seems... kinda useless. From the video, it doesn't even look like it's that easy to clean-up once you're done with them (though maybe there's a remove-all function)
>Teach people to use the conditional breakpoint and just enter `console.log(...)` instead, it's overwhelmingly more powerful.
If you're going to print things for insight at breakpoint time, wouldn't it make more sense to just use watch expressions?
"stop the world and view expression(X)" is time-consuming when you're trying to discover patterns that you can later be more selective about (e.g. to turn them into a conditional breakpoint). With logs you can pretty trivially spit out thousands of them and eyeball / grep / etc however you need, which could take hours if you had to stop each time, and didn't have specialized tools to help you search for needles in the haystack.
But very frequently yes, all you need is a breakpoint and an expression, and hit "continue" a few times. I absolutely do that when I can.
---
As to "just a wrapper for console.log", yes. It's a bit of an infection, though I'm not seeing as many as I used to, so maybe we're fighting it off. but e.g.:
even Chrome [1] and MDN [2] refer to conditional breakpoints, but only mention "will stop when condition is true", not "by the way you can mutate state in here, call funcs, anything you like".
It's oddly crippling to not know this kind of stuff. Ever had a bug, and you wanted to see how it would behave if var X was the right value? You can just override it in a conditional breakpoint and "fix" the bug without rebuilding, to see what happens.
In many languages, a debugger is very nearly a REPL. Wish Java would have a REPL? Sure, a simple CLI command would be nice, but I've done "live" coding of android apps for years. Just add a periodic callback to the main thread with a disabled breakpoint - once there, modify your views in the expression editor, and your app - on your phone - updates in the very next view tick. There are limitations, like (kinda) not being able to import new things, but they're not hard to work within and the time savings can be immense.
Don't give people saws until they spend years chopping down trees with axes. Or maybe they should start out by punching them down, we weren't born with axes you know, and you won't understand a saw until you feel the wood fibers buckling under your knuckles.
No. This stance is complete nonsense. People who don't want to learn how things work won't learn either way, but an IDE can at least make them safer and more productive. For people who do, an IDE can magnify your abilities quite a lot. All of which is true for any (decent[1]) tool in any field.
I recently switched to JetBrains products. Their IDEs are much smarter. Infinitely better than VS Code, Sublime and whatnot. It's the closest thing to pair coding!
I'm also partial to WebStorm. Local history feature of Eclipse derivates has saved me enough times to make it a core pre-requisite when considering another IDE. Fwiw, VS Code has better typescript support.
Not OP but for me it's just a preference like a color scheme is to anybody else. It is visually appealing and helps to distinguish different aspects of some context specific things.
I get that it's not for everybody but being so against it is something I really do not understand.
Why use color schemes or different fonts at all then?
What use cases do you have to regularly count characters eyeballing it? The characters are still distinct and equal width in the code and the line length doesn't shift, so it's just a visual thing...
I'd love to have a package for that too. On Sublime I use sFTP and it works really well. You can either load files directly from an sftp connection, or map a directory, and every time you modify a file, it gets synced automatically.
Will it ever get encoding autodetect? That's one of the big reasons I've stayed on Notepad++. VS Code clearly does detect the encoding, because when you go to change it it suggests the right one, but it doesn't load correctly.
I would be thrilled if 99.9% of my input files were UTF-8, but I'm not the one writing them. SJIS remains in widespread use in Japanese companies and tons of legacy codebases do not work with UTF-8. If you're lucky there's a config flag for UTF-16.
My favourite "features": the ecosystem and the development speed.
It keeps getting better and better and better month by month and it now even knows how to fix small stupid mistakes like a missing this. when trying to access a field in ts etc.
Is there a way to have intellisense sense work with python dictionaries? It seems like intellisense for json would be a similar issue as nested dictionary representations in json, but I can’t find anything that does this and don’t want to use another class just for faster coding.
You'd need access to the runtime environment in order to do that.
That said I wish somebody would make an IDE that would tightly integrate IPython so I could get IDE autocompletion in a paused test. I spend way too much time writing code in IPython prompts and copying it back.
You can check design time for any strings placed in source. Which is really what I want. I don’t need intellisense for stuff populated at runtime as much.
I don't know how is it now, but I've used it for a couple of months for web dev on my mac and switched to Atom when noticed my cpu was 70%+ of usage all the time. I suspected it was because of the typescript plugin, but honestly I don't care Atom doesn't do that and I'm happy with it.
I had, but this was several version back, couldn't find any info of what was failing and also waited a major version update before doing the switch. Switching editors always causes stress. That's why it's hard to gain users back once you made a mistake on this (very competitive) field. I would only try VS Code again if Atom messes up, no matter what new micro site Microsoft PR puts online.
Edit-to-add: with your downvote you are invited to explain why/if I'm wrong.
I'm a back-end developer, but, when I wanted to indent that HTML in order to post it, I switched over to the instance of vscode that I virtually always having running in order to use its pretty printer.
There certainly should be a static page version. Especially since there is barely any interactive element to this, it's essentially just a list of links
It is certainly an interesting choice to use a fully fledged SPA framework to render a static page. And since it runs on Azure App Services, I'd say server side rendering should be possible.
It’s a page aimed at web devs, evangelizing an editor written in JS. If you want to read it, turn on JS. If you turn off a key component of the modern web, you should expect that things will break, and not complain about it.
Yeah, this could be a static HTML/CSS site but that's the state of the modern web for better or worse. Markup rendered by a framework like React/Vue and bundled up with Webpack. It's just easier to build that way.
Please know that no one really cares. You must realise you cannot expect to consume our applications but only on your own terms. Theres no contract saying you should ONLY serve HTML on the web.
I can't speak for gp, but the reason I whitelist Javascript is because the dozens of third party scripts pages load provide no benefits to me as a user and only waste my bandwidth and cpu while risking my security and privacy. Sometimes the first-party scripts do something useful and I enable them.
That a simple document with embedded videos "needs" js to load at all is sheer lunacy. The modern web is a massive house of cards. I don't want to be uncivil but I find it very hard to understand how anyone thinks they're doing good work after they create a simple (and useful!) web document that requires javascript to load.
If you're using Javascript to make a web application, fine, clearly there's no reasonable alternative. But if you need Javascript to produce a web document, what are you doing? I wonder how much more electricity is being consumed annually processing utterly pointless Javascript.
One of the increasingly popular uses of JS is to save bandwidth. Using JS, you can ask the browser if the user is on a metered connection or an unlimited one, what their estimated bandwidth capacity is, what their real resolution is, and load appropriate assets (or conditionally load content). With JS disabled, a user on a pay-per-kilobyte 360x640 cellphone is going to get assets deemed acceptable on the manager's 1440p desktop. There are already quite a few websites where disabling JS more than doubles your bandwidth usage -- and sites that are only even usable in third world countries because of JS like this -- and that's going to increase as screen and media quality grow.
Not to mention the huge accessibility benefits that can come from changing the way a site behaves (not just visually but in terms of things like tab and focus behaviour or separating components out) for disabled users. Doing that reliably and effectively for all content on all devices is much easier if you can identify the needs before downloading the content which means JS-loaded content and so it can come down to deciding whether to annoy NoScript users or disabled users.
That doubtless provides some reasonable bandwidth savings on certain media sites, but I'm pretty sure the whitelisting approach is going to come out far, far ahead in general, as most ads don't load and some Javascript assets are themselves megabytes in size.
Also, IME, disabled users hate javascript. But my experience is limited to a few vision impaired folks.
Why, if your goal is to save bandwidth, would you have the system default to loading the biggest assets when you can't ascertain these things, instead of loading the smallest ones?
That said, given my experience of running the web with NoScript, I'd be surprised if those sites that double the usage when they can't detect these things come anywhere close to eating up all the bandwidth I'm saving by not loading auto-playing video ads.
In general, one should serve HTML on the web unless you're doing something that requires JavaScript. JS is a big security/privacy risk. At the moment, I keep JS and CSS off by default on my main browsing profile, overriding it with umatrix when a site requires it and it looks useful enough to bother.
That's bezerk. You should turn off the CPU in your computer, too, and just use the screen and keyboard. The CPU is where all the security breaches happen.
That's like saying that you shouldn't bother eating healthily because if you're really concerned about heart disease you should just have heart removal surgery.
In general, one should consider the audience of the content, not NoScript users, in this case.
> JS is a big security/privacy risk.
No, 3rd party JS (and 3rd party cookies, JS regardless) allow you to be tracked. And ad-blockers deal with that. Blocking 1st party JS is of tenuous benefit w.r.t security/privacy.
Sometimes "3rd party" JS is served from within the page. Also many sites are hacked and will cloak the JS depending on how you visit the site. It's especially common with hacked WordPress sites.
Create a block (red) rule for `script` in global scope. I wrote is a guide for this, "How to block 1st party scripts everywhere by default" (link below)
In the top left of the matrix, click on the `.com` part of the domain. I think that will change the scope to all sites rather than the current domain. Then block the JS column. It should then be blocked by default when you go to new sites.
I popped over to a different browser to take a peek. That's not an "application". It's static page with some embedded YouTube videos, and some hyperlinks. It just happens to be one where it takes about 5 seconds (on my computer) before the hyperlinks become clickable, for some reason.
I do agree that there is no contract saying you should only serve HTML on the web. But still, you can do better than this.
Last time when nobody cared about a broken nest of security holes in the center of the Web, a small minority had organised a campaign to annoy people with complaints.
I mean Mozilla's campaign asking users to send complaints to each and every webmaster writing IE5-only sites. It somewhat worked.
Unfortunate that you're being downvoted because the slow start time of VS code is honestly such a big blocker that it outweighs most of these features for me. I just can't wait 10 seconds every single time I want to take a note.
I am on a fairly RAM constrained workstation (4GB) so I have no choice but to close it when I'm not using it. Otherwise I'll spend just as long swapping as I would opening a new instance.
The biggest consumer of RAM for me is chrome, not windows, and it is basically essential to my development process to have it open all the time. So I worry an OS change would not produce an appreciable enough performance improvement to justify changing my whole workflow over.
I've seen some people make the argument that they want to use their editor for quick edits to single files, which is a fine use-case. However, VS Code is really not designed to be optimized for that case. It's really about editing code (hence the name) as opposed to quick edits to configs, etc.
It's usually best if one knows a few different tools designed for different scenarios. Right tool for the job.
At the same time though, it is purposely not positioned to replace a full-blown IDE. So what is the use case that it's optimized for? Why does it offer to add an "open with code" context menu item to every file if it's not expected that you'll be using it for quick edits on individual files?
It's not so much a professional issue as a personal one. When I get an idea and want to start taking some notes, a 10 second delay is more than enough time for me to get side-tracked by the details. So I skip VS code and open notepad instead, in the interest of getting the idea out as soon as possible. And as the complexity of the project starts to increase to the point where VS code's more advanced functionality might actually come in useful, there just never seems to be a good time to stop what I'm doing and change editors.
Mechanical disks are basically free in this day and age, so that's still a pretty significant savings over an SSD which is more like the price of a mechanical disk 10 years ago. You could cheap out and do a small SSD/large HDD combination, but I find that having an excessively small system drive is nothing but headaches, especially for software development where you are frequently installing different toolchains, etc. Until I can afford an SSD that is comfortably in excess of my storage requirements, then I'll stick with the HDD.
I've been using both lately. VSCode for when I'm working on a project and the editor ends up staying open all day. I also often have to work with large files, so I use Sublime to pop them open and make a quick change.
Well, ST3 does 70% of what VSCode does, at 1/10th the memory and much faster, and it's written by a single person.
Besides, they're still writing in a typed "language" (ts), so it's not like the dynamic language nature of JS that allows the VSCode base code to be developed incredibly quickly.
What really allows them to develop it incredibly quickly is the plugin API -- which allows tons of npm stuff to be ported and tons of JS programmers to create plugins for VS Code. A native statically typed based core would allow for that too. In fact the VSCode team already have moved some VSCode processing to C++ libs exactly for speed (and of course node itself is C++).
Using DOM for the drawing is faster (for a convenience perspective, not execution speed) yes, but with MS resources they could have made a streamlined equivalent that's much faster, more memory efficient, and doesn't have all the baggage of a web rendering engine. In fact, they have several native alternatives lying around they could make cross platform.
As it is, VSCode will ever have the burden of rendering to the DOM.
Wouldn't it just be Visual Studio then? We would get updates once a year instead of once a month. There are less C++ devs than JS devs. The size of the community that could contribute would shrink also.
> Wouldn't it just be Visual Studio then? We would get updates once a year instead of once a month.
For what it's worth, the Visual Studio team now releases minor updates roughly every six weeks (including bug fixes and new features), and service updates almost weekly [1]. They also rely quite heavily on user feature requests [2].
No, but it would "just be" an open source, MS backed, version of Sublime or TextMate. The concept of Visual Studio is different.
>We would get updates once a year instead of once a month.
The language the core is in is irrelevant as to whenever we would see updates. That's a concern of the release process.
>There are less C++ devs than JS devs.
Not really important, as most of the contributors are MS guys anyway. In fact a single person has made Sublime Text, an editor that offers most of what VSCode offers, with 1/100 the budget and manpower. If only it was Open Source too, or had a few more devs...
Do we really argue why the DOM and a full blown browser engine might not be the best option for a programmer's editor?
How low have we fallen from what programmers were concerned with memory use, and speed, and the right tool for the right job, and so on, and even Emacs was considered bloated...
Speed seems perfectly fine to me. Two seconds startup time, everything else is pretty much instant. And it's faster than some C++ IDEs, e.g. searching and opening a file with ctrl+e is close to instant most of the time (just some occasional longer search times), whereas ctrl+, in Visual Studio is almost useless because of how long it takes until it displays files.
sure, but would we even be here talking about VS Code if it had been written in those languages? Would the extension community have grown as quickly? Would Microsoft have continued investment in the product if it hadn't?
I'm not saying that it wouldn't have been as successful, but we're here, now, and it is. It's a great product regardless of the fact that it's written with HTML/CSS/JS.
I like VS Code and Atom, so please understand my criticism here doesn't come out of hate or disdain.
Vim has a pretty huge community of plugins, and with NeoVim that plugin development has greatly accelerated. Intero, Fireplace, Vim FSharp (which works on regular Vim as well), and NeoComplete are excellent, and make NeoVim competitive with a lot of IDEs in my mind.
Part of the reason I don't use VS Code is that I really don't feel the need to run an instance of Chrome just to edit text. On my Mac, after loading a relatively large FSharp file, with FSAutocomplete (which is not known to be particularly efficient software), in NeoVim, it's taking so little CPU on the NVim side that it doesn't even register in Activity Monitor or `ps`. The same file loaded in latest version of VS Code (downloaded about thirty minutes ago) with the Ionide plugin is taking about 8% of the total CPU power.
With computers as powerful and wonderful as they are nowadays, I think you could make a solid argument of "Who the hell cares?", but in my mind, we have been editing text with full screen editors since the 80s, and had interactive IDEs since the 90s. If we could do this efficiently since the 90's, why should we opt for an inefficient solution now, especially if the efficient solutions are competitive?
Again, I'm saying this out of love. I use VS Code or Atom occasionally when I want to edit Markdown or HTML, and I think they are solid editors, especially considering that they are free. I understand that they are there to more to offer an open source and competitive solution to something like Sublime Text, and not to win-over the command-line-editor crowd, and at that I think they succeed. I just wish that an efficient framework like Qt, which has JS support, had caught on instead, since I think it would be a lot more efficient.
It's just a guess, but I think the main reason to run VSC in a browser is that they can later also let in run in a browser, without install. You will develop, store, and run your code on Azure, without any local installation.
(I don't know if that is a great vision, but it is a good rationale to use Web tech for IDE development)
I know this is like a "you can get something as good as Dropbox by just running an FTP server" thing that you see on HN occasionally, but if I wanted that, I conceivably could just run a VM on Azure/AWS/Digital Ocean and SSH in for development with NeoVim. I guess the interface wouldn't be as streamlined though.
>sure, but would we even be here talking about VS Code if it had been written in those languages? Would the extension community have grown as quickly?
Why not? Didn't hurt ST or TextMate much (though them being closed source did). And we still use Vim, written in C, 40+ years on, and it has tons of plugins...
>Would Microsoft have continued investment in the product if it hadn't?
MS developed Monaco for over a decade, with very little adoption, so why not?
- In the Git view, select a modified file, select some lines of code you modified, cmd shift P, Git: Stage Selected Ranges. I dropped my dedicated Git GUI since I know this trick.
- If you spend a lot of time coding in React, and have half of your files named index.js, do yourself a favor, go in the settings and add "workbench.editor.labelFormat": "short" (display the name of the file's folder in all the tabs)
- You can preview markdown files natively (button at the top right corner).
- Real time collaborative development: https://marketplace.visualstudio.com/items?itemName=MS-vsliv...
Re the git stuff though- one place that I'm pretty sure emacs is the uncontested champ is in git integration via magit. I'd be inclined to recommend using emacs as their git interface even to people who want to use a different interface for everything else. It is that good, and IMHO the only git porcelain that is strictly better than the standard git porcelain.
Evil-mode solves that, and just as magit is better than git evil-mode seems, to me, better than vi. Emacs is better than ever (though you do need to use auto-formatting for languages like JS that change a lot- there is no emacs mode that has kept up with ES whatever. Luckily emacs makes it easy to use formatters like prettier on a per-buffer basis.)
Emacs users can tell that joke, but they have deliver it with a wry smile. Evil-mode users can tell that joke with a knowing laugh.
On the "highly custom" level, I have a work-in-progress script that takes a URL, sends it to a Splash server, and returns the rendered HTML to eww for viewing. This is great for annoying SPAs like the article that spawned this conversation.
My current goal is to swap out my development MBP with an eInk tablet and bluetooth keyboard. Success will be measured as a function of productivity and weather-/water-/environment-proofing of the device; the goal is productivity in full sunlight and/or under water. Emacs will have a central role in that. Just need to find an eInk device with adequate screen refresh rate and Bluetooth support....
vim $DOCUMENTATION_URL (curls the page and opens in vim)
vim-rest-console
:terminal (new!..ish. Works great.)
Every package developer makes choices about how their package works (and built-in behaviour too), but sometimes that clashes with what you want, or is somehow inadequate.
It's those small conveniences that have a disproportionate impact.
I'm not saying you can't do similar in vim or there aren't other ways to achieve the same goal, I'm saying that over time, those minor improvements have a huge impact.
Here's 2 examples:
1) Splitting a window horizontally by default splits 50:50 but on a 16:9 monitor I usually want the new buffer (right) to be smaller than my current buffer (left). So I override the defaults.
2) I use paredit for lisp based languages, but (as far as I'm aware) there's no built in-command to copy (or paste) the s-expression surrounding the cursor's current position.
I often find myself wanting to do exactly that e.g. in a let or a cond form in Racket. So I wrote a couple of small functions to do just that, bound them to keyboard shortcuts and I've now made a minor extension that fits exactly what I want to do. Since lisp is based on s-expressions it turns out this extension to someone else's package is incredibly versatile and useful.... TO ME!
I press my chosen key-combination and it becomes ready to edit the new s-expressionThere are other similar commands in the category, like a" for selecting the interior of a double-quoted literal and such.
They are documented under ":help visual-operators".
But that said - it does it's job very well and magit is certainly excellent software for those that are interested in that interface.
But when it comes to magit I'm not so sure. I'm inclined to think that magit is _strictly_ better than any other git interface, so much so that even if you don't like emacs you should suck it up and use magit as your git porcelain, even if you use a different editor for everything else. Magit is that good- I just gave $100.00 to the project, and I never donate to open source stuff. It is that good.
I don’t mean “it’s not my preferred git client”. I mean “I’d rather use almost anything else”.
Why? Because it requires emacs interface, concepts, and controls. And unless you’re ok with those it’s not better at all. In fact it’s _strictly_ worse.
That said: if you like emacs I think you’re correct, it’s almost certainly the best there is.
Others, such as myself, suffer it only when compelled by an instructor.
(Option)Alt-Cmd + Down or Up arrow key
From there, you can use arrow keys as normal, but instead of controlling one carrot, you control all the ones you created. So if I use the shortcut key to move to the next word, they all do, same with end of line, or what have you. In the past I had to use regex in my editors to extract quoted text in each line... now I just use multi-select. Each carrot can also be created with the mouse in the Selection menu.
Edit: Apparently it's a feature lifted from Sublime and in other IDEs - thanks!
Multicursor is amazing.
One thing it's been great for:
I have code like:
byte b1 = array[0];
And I want to do this for 16 bytes. Control + D to duplicate 15x. Double tap control, hit up 15 times - now there's a cursor at every row. Hold control, hit right (jump by word), index to end of 'b1' on each line. Ctrl + shift + a, 'increment duplicates' - now every line is 1, 2, 3, 4... 16. `ctrl + right` my way to the index key and do the same thing.
It's awesome.
edit: I just found 'duplicate and increment' :o
But I wasn't doing this for a loop unroll.
I had a fixed size array that I wanted to serialize/ deserialize to/ from capnproto - there are no fixed size arrays in capnproto, so I wrote a message that just had b1, b2, b3... b16, and then some code to pull it out into a statically sized array. It allowed me to pull a bunch of bytes into a much larger statically allocated array without any allocation or bounds checking.
You must do some kind of programming I've not encountered in my many years. While my editor of choice can do this, I would have no idea how, because a feature like "increment duplicates" is needed so infrequently that I would never remember the shortcut.
There are appropriate plugins available for my editor, but I've never felt the need to install them.
Formatting is another.
Boilerplate code, for example today I had to implemented code like this:
I had 6 node types. Using multiple cursors I:* Implemented it once
* Duplicated it 5x
* Copied the names of the types I needed to impl for
* Attached a cursor to each impl
* Used ctrl + left/ right to word-jump, and past in the appropriate area
Now it's not like this saved me more than a minute or two, but this sort of thing is extremely common in my experience, across languages.
Poof! The above is replaced with the following:
Don't write in some insane boilerplate-driven programming language in the first place. Anyone proliferating this kind of duplication (whether with multi-cursors or shell here docs or any other way) should be flogged.I've been using it in editors since well before VSCode existed. It's very nearly a requirement for me to use an editor now.
For your example, this is the kmacro I ended up with:
(after you've created a macro, you can get the above by doing M-x kmacro-edit-macro.)This is nothing new; I was doing this in Vim 20 years ago.
That and arbitrary window splitting (split any pane horizontally or vertically) are two features I really miss when they're not present. The latter's surprisingly hard to find; Sublime and VS Code don't do it (Atom does).
You can for example put your cursor on a word, spam ctrl+d (of press alt+f3) to select all instances of that word, and start editing them all at ones, no matter where they are. They don't have to be perfectly in a column. You can also copy X items from anywhere, and if you have X cursors again somewhere else and paste, they'll each go in their respective slot.
Alt + Shift + A
I've had issues in IDEs where they have shitty implementations of multicursor that break that example.
Super handy when you want multiple cursors to line up at the start of every line (by default vscode will wrap the cursor around to the end of the longer lines if you try to move around with the arrow keys).
There's about 20 other extensions I routinely use, which I documented at https://nickjanetakis.com/blog/switching-to-vscode-from-subl....
Additionally, there is a case where if you don't select the last line until the end, you end up in a state where the last cursor is already at the beginning. If you press "Home" now, you end up having that last cursor at the beginning of the line - and the other ones at the indentation level (see https://github.com/Microsoft/vscode/issues/14919#issuecommen...)
(Disclaimer: Author of the mentioned plugin, so I am heavily biased against my own workflow and saving-keypresses-obsession :P)
Pressing home doesn't always put you at the true beginning of the line. It will put you at the first non-whitespace character.
It only took using a keyboard for about 22 years to learn pressing home more than once has benefits.
Thanks!
https://visualstudio.uservoice.com/forums/121579-visual-stud...
Still found 2 useful things for me, Parens colorizer and settings sync via Github Gist.
I'm also using it as my main editor on my Windows box at home where don't do serious development.
My only real annoyance is that I seem to run into multiple addons that can't be properly installed for one reason or another and sometimes "Ignore this" doesn't work and then the popup gets stuck and you can't see the top three lines...
Apart from that it's been really nice for Rust, Go, and Python.
The newest version has smaller popups on the bottom-right of the window, and that was a nice surprise for me.
What is your setup? Is it system wide or do you configure it manually for each project/workspace/folder?
https://about.sourcegraph.com/docs/integrations/editor-plugi...
I'm early on in evaluating ElixirLS and vscode-elixir but have run into some issues with both.
(And FWIW, I have used Jetbrains products before I used VS Code.)
But the costs are more than offset by the benefits. I didn't realize how much of a cognitive burden thinking about formatting was until I stopped thinking about it, and it turns out that using formatting to signal intent is perilous when people don't agree on how formatting signals intent.
I'm pushing to have Prettier used across all our JS code- there is some resistance to the idea of running it across a several hundred k line non-prettified codebase and some resistance to the idea of using it at all. And this causes problems. Prettier is best when you use it for everything.
But I'm pretty sure we'll eventually just move to prettification. It seems like the right thing to me, and I'm generally right ;). Anyway, thanks for Prettier- I am not actually a huge JS fan despite mostly writing it professionally, but Prettier does away with some of my complaints about JS, and just generally makes my life easier.
I do prefer adding a .prettierrc to projects, though, instead of inside vscode options (user or project) like what is suggested here. That way my teammates and I can use the same settings, even if they don't use vscode.
Thank you
The cognitive load it costs to worry and fret about code formatting....
(thank you)
Add this to your settings:
``` "search.location": "panel", ```
Not perfect, but it's a start.
https://marketplace.visualstudio.com/items?itemName=adammara...
I've always wished this key at least had an LED indicator along with Caps Lock.
One thing I'd like from the past is a blinking block cursor.
Can you explain the exact scenario you use it in, I honestly can't think of a scenario where insert is useful.
It’s hard to come up with exact examples because it’s actually subconscious and as automatic as touch typing for me. Thinking back, when I’m on one line with the cursor maybe halfway through, I’ll hit down arrow, alt arrow to the word I want to rename, hit insert, type over it, hit insert. I think I did it when trying to clarify some documentation. I’ll be on the lookout in the near future, but unlikely to report back here unless it happens to happen really soon.
It hasn't been updated in over a year, but I've yet to have any issues with it.
Want to collect all values of something as your code runs? conditional breakpoint: `x = (x || []).append(val)` and then print it whenever you feel like it. Log breakpoint? spit it out each time and... browse by hand? hope nothing's logged in between? bah.
>Teach people to use the conditional breakpoint and just enter `console.log(...)` instead, it's overwhelmingly more powerful.
If you're going to print things for insight at breakpoint time, wouldn't it make more sense to just use watch expressions?
But very frequently yes, all you need is a breakpoint and an expression, and hit "continue" a few times. I absolutely do that when I can.
---
As to "just a wrapper for console.log", yes. It's a bit of an infection, though I'm not seeing as many as I used to, so maybe we're fighting it off. but e.g.:
jetbrains has stuff like "evaluate and log": https://www.jetbrains.com/help/phpstorm/configuring-breakpoi...
Visual Studio has "condition" and "action" options for breakpoints: https://msdn.microsoft.com/en-us/library/5557y8b4.aspx one of which is "log a message": http://www.visualmicro.com/page/User-Guide.aspx?doc=Working-... (mindlessly copying this UI, because what VS does is Good™ (it generally is!), used to be more common from what I can remember)
even Chrome [1] and MDN [2] refer to conditional breakpoints, but only mention "will stop when condition is true", not "by the way you can mutate state in here, call funcs, anything you like".
[1]: https://developers.google.com/web/tools/chrome-devtools/java...
[2]: https://developer.mozilla.org/en-US/docs/Tools/Debugger/How_...
---
It's oddly crippling to not know this kind of stuff. Ever had a bug, and you wanted to see how it would behave if var X was the right value? You can just override it in a conditional breakpoint and "fix" the bug without rebuilding, to see what happens.
Thankfully there are at least a handful of people who have realized this, despite docs essentially never calling it out: https://davidwalsh.name/debugging-conditional-breakpoints
In many languages, a debugger is very nearly a REPL. Wish Java would have a REPL? Sure, a simple CLI command would be nice, but I've done "live" coding of android apps for years. Just add a periodic callback to the main thread with a disabled breakpoint - once there, modify your views in the expression editor, and your app - on your phone - updates in the very next view tick. There are limitations, like (kinda) not being able to import new things, but they're not hard to work within and the time savings can be immense.
No. This stance is complete nonsense. People who don't want to learn how things work won't learn either way, but an IDE can at least make them safer and more productive. For people who do, an IDE can magnify your abilities quite a lot. All of which is true for any (decent[1]) tool in any field.
[1] here, have a twitter rant. You're advocating for the Hole Hawg: https://twitter.com/myrrlyn/status/980148201456943104
I get that it's not for everybody but being so against it is something I really do not understand.
Why use color schemes or different fonts at all then?
It's a simple package, but it works very well.
I have got to check out the docker features as well.
I really like VSCode. MS is innovating in UX.
It keeps getting better and better and better month by month and it now even knows how to fix small stupid mistakes like a missing this. when trying to access a field in ts etc.
Well, maybe it’s my extensions that made it slow.
That said I wish somebody would make an IDE that would tightly integrate IPython so I could get IDE autocompletion in a paused test. I spend way too much time writing code in IPython prompts and copying it back.
Edit-to-add: with your downvote you are invited to explain why/if I'm wrong.
A: No.
Long A: Org-mode is plain text. So it org-modes, but not in a meaningful way.
https://github.com/ajtoo/vscode-org-mode
I've used it over Emacs for simple use cases without any real issues, and the project's under very active development.
Front-end developers don't tend to view the web with NoScript. Just like 99% of users don't view the web with NoScript.
I'm a back-end developer, but, when I wanted to indent that HTML in order to post it, I switched over to the instance of vscode that I virtually always having running in order to use its pretty printer.
1 out of 15 examples (the Docker one) don't involve HTML or JS. (And backend JS devs are generally pro-JS so likely aren't using NoScript either).
Do you use NoScript? Maybe you do and you're the <1%, but fact is even if you do, both you and GPP turned it off to view the site already ...
I'd replace the snark with additional details so the author could attempt to reproduce your issue.
"Websites should not unnecessarily require JavaScript."
That a simple document with embedded videos "needs" js to load at all is sheer lunacy. The modern web is a massive house of cards. I don't want to be uncivil but I find it very hard to understand how anyone thinks they're doing good work after they create a simple (and useful!) web document that requires javascript to load.
If you're using Javascript to make a web application, fine, clearly there's no reasonable alternative. But if you need Javascript to produce a web document, what are you doing? I wonder how much more electricity is being consumed annually processing utterly pointless Javascript.
Not to mention the huge accessibility benefits that can come from changing the way a site behaves (not just visually but in terms of things like tab and focus behaviour or separating components out) for disabled users. Doing that reliably and effectively for all content on all devices is much easier if you can identify the needs before downloading the content which means JS-loaded content and so it can come down to deciding whether to annoy NoScript users or disabled users.
Also, IME, disabled users hate javascript. But my experience is limited to a few vision impaired folks.
That said, given my experience of running the web with NoScript, I'd be surprised if those sites that double the usage when they can't detect these things come anywhere close to eating up all the bandwidth I'm saving by not loading auto-playing video ads.
> JS is a big security/privacy risk.
No, 3rd party JS (and 3rd party cookies, JS regardless) allow you to be tracked. And ad-blockers deal with that. Blocking 1st party JS is of tenuous benefit w.r.t security/privacy.
Blocking all JS lets me click on any link fearlessly.
https://github.com/gorhill/uMatrix/wiki/How-to-block-1st-par...
I do agree that there is no contract saying you should only serve HTML on the web. But still, you can do better than this.
I mean Mozilla's campaign asking users to send complaints to each and every webmaster writing IE5-only sites. It somewhat worked.
Can it not be unresponsive if you have a mechanical disk or a weak CPU?
Ooops, I'll stick to Sublime
I used to feel the same way early in my career. Now I don’t feel the need to be in a rush all the time.
It's usually best if one knows a few different tools designed for different scenarios. Right tool for the job.
Well, it is 2018. Mechanical disks?
Nobody is trying to sell VS Code to you.
Besides, they're still writing in a typed "language" (ts), so it's not like the dynamic language nature of JS that allows the VSCode base code to be developed incredibly quickly.
What really allows them to develop it incredibly quickly is the plugin API -- which allows tons of npm stuff to be ported and tons of JS programmers to create plugins for VS Code. A native statically typed based core would allow for that too. In fact the VSCode team already have moved some VSCode processing to C++ libs exactly for speed (and of course node itself is C++).
Using DOM for the drawing is faster (for a convenience perspective, not execution speed) yes, but with MS resources they could have made a streamlined equivalent that's much faster, more memory efficient, and doesn't have all the baggage of a web rendering engine. In fact, they have several native alternatives lying around they could make cross platform.
As it is, VSCode will ever have the burden of rendering to the DOM.
For what it's worth, the Visual Studio team now releases minor updates roughly every six weeks (including bug fixes and new features), and service updates almost weekly [1]. They also rely quite heavily on user feature requests [2].
[1] https://docs.microsoft.com/en-us/visualstudio/productinfo/vs...
[2] https://visualstudio.uservoice.com/forums/121579-visual-stud...
No, but it would "just be" an open source, MS backed, version of Sublime or TextMate. The concept of Visual Studio is different.
>We would get updates once a year instead of once a month.
The language the core is in is irrelevant as to whenever we would see updates. That's a concern of the release process.
>There are less C++ devs than JS devs.
Not really important, as most of the contributors are MS guys anyway. In fact a single person has made Sublime Text, an editor that offers most of what VSCode offers, with 1/100 the budget and manpower. If only it was Open Source too, or had a few more devs...
How low have we fallen from what programmers were concerned with memory use, and speed, and the right tool for the right job, and so on, and even Emacs was considered bloated...
I'm not saying that it wouldn't have been as successful, but we're here, now, and it is. It's a great product regardless of the fact that it's written with HTML/CSS/JS.
Vim has a pretty huge community of plugins, and with NeoVim that plugin development has greatly accelerated. Intero, Fireplace, Vim FSharp (which works on regular Vim as well), and NeoComplete are excellent, and make NeoVim competitive with a lot of IDEs in my mind.
Part of the reason I don't use VS Code is that I really don't feel the need to run an instance of Chrome just to edit text. On my Mac, after loading a relatively large FSharp file, with FSAutocomplete (which is not known to be particularly efficient software), in NeoVim, it's taking so little CPU on the NVim side that it doesn't even register in Activity Monitor or `ps`. The same file loaded in latest version of VS Code (downloaded about thirty minutes ago) with the Ionide plugin is taking about 8% of the total CPU power.
With computers as powerful and wonderful as they are nowadays, I think you could make a solid argument of "Who the hell cares?", but in my mind, we have been editing text with full screen editors since the 80s, and had interactive IDEs since the 90s. If we could do this efficiently since the 90's, why should we opt for an inefficient solution now, especially if the efficient solutions are competitive?
Again, I'm saying this out of love. I use VS Code or Atom occasionally when I want to edit Markdown or HTML, and I think they are solid editors, especially considering that they are free. I understand that they are there to more to offer an open source and competitive solution to something like Sublime Text, and not to win-over the command-line-editor crowd, and at that I think they succeed. I just wish that an efficient framework like Qt, which has JS support, had caught on instead, since I think it would be a lot more efficient.
(I don't know if that is a great vision, but it is a good rationale to use Web tech for IDE development)
Why not? Didn't hurt ST or TextMate much (though them being closed source did). And we still use Vim, written in C, 40+ years on, and it has tons of plugins...
>Would Microsoft have continued investment in the product if it hadn't?
MS developed Monaco for over a decade, with very little adoption, so why not?