How I'm still not using GUIs in 2019: A guide to the terminal - <AUTHOR> https://www.lucasfcosta.com/2019/02/10/terminal-guide-2019.html <comment><USER3> "Not every machine has VSCode, Sublime or Atom installed, but every machine has a terminal."

I love that the article goes from this sentence immediately to:

"These are the main programs I use to make my terminal a complete development environment:"

And proceeds to list 5 different programs, some of which are only available on macOS.

Brilliant.

Edit: One of which are only available*. My point isn't that there isn't a place for GUI and terminal, it's that "not every machine has x and y software" is a fruitless argument.

<comment><USER4> Using the terminal at least makes you proficient with the lowest common denominator of tools.

I know I can SSH into any random machine, and edit a config with the copy of vi/vim it has, even if it doesn't have my fancy plugins.

And if I get a new machine, all I have to do is install my tools via Apt/Brew/etc, clone my dotfiles repo, and run an install script.

<comment><USER5> > I know I can SSH into any random machine, and edit a config with the copy of > vi/vim it has, even if it doesn't have my fancy plugins.

The android phone I'm currently messing around with had neither vi nor vim...

Yes, knowing the lowest common denominator is great. But doesn't make a great dev environment. OP is describing how to set up a customized one for exactly that reason.

<comment> yjftsjthsd-h Eh...it's not out of the box, but either busybox or termux will fix that in 30 seconds. The lowest common denominator is extremely portable.

</comment></comment></comment></comment><comment><USER6> I'm a game developer mainly writing/reading/debugging C++ on a codebase that's well over a million lines of code. As with most game-dev I'm developing almost entirely using Visual Studio, and I can't imagine trying to navigate code using a terminal based editor.

Maybe it's just because this is what I'm used to, however I just don't see how some of the tools would even be displayed in a terminal (parallel stacks window, for example) without some horrible ascii node graph.

GUI's are definitely more than just bloat. Possibly not for what the author us developing, but there is definitely a use for IDEs/GUIs.

<comment><USER7> What kind of navigation are you relying on that could not possibly work faster on a terminal?

Horrible ascii graphs look horrible, but they are arguably more functional in that you can navigate them with your keyboard.

<comment><USER8> Navigation is rarely the limiting factor in development speed. I'd take better auto completion / integrated tools over faster navigation every day.

<comment><USER9> I hope that language servers fully take off. This way, Vim and Emacs can gain semantic autocomplete & navigation. To be clear: it's not that they _can 't_ have that in principle, it's just that engines for semantic operations are difficult and expensive to write, so they were made primarily by IDE companies - and until recently, it meant they were tied to those IDEs.

With that, the only remaining thing in which IDEs are a better choice than vim or Emacs is debugging. I wish for decent and fully featured debugging TUIs.

<comment><USER10> I've never been a big debugger user, but I thought if you like LSP, you might be interested in Microsoft's analogous debugger protocol:

[https://code.visualstudio.com/api/extension- guides/debugger-...](https://code.visualstudio.com/api/extension- guides/debugger-extension)

I imagine Emacs, vim, and friends could implement their own frontends for this, much as has been happening with LSP.

<comment><USER9> Wow, thanks!

And it turns out, Emacs and vim _do_ implement their own frontends for this - [0], [1]. My wish just literally came true!

[0] - [https://github.com/emacs-lsp/dap-mode](https://github.com/emacs- lsp/dap-mode)

[1] - [https://github.com/puremourning/vimspector](https://github.com/puremourning/vimspector)

<comment><USER10> Awesome - glad to be of assistance!

</comment></comment></comment></comment></comment></comment></comment><comment><USER11> > _GUIs are bloatware._

This is only true, firstly, when what you're trying to represent can be accurately, completely, and most concisely represented by plain text. That's actually a fairly narrow range, unless you're a programmer. And secondly, it's only true when you're not interested in using common interface conventions to teach your users how to use your program. While that can certainly be done -- the -? and --help parameters spring to mind -- it's much easier when there are UI guidelines [0] that everybody sticks to simply by virtue of how GUIs tend to work (i.e., there are existing common libraries to describe the interface in predictable ways).

If everything you do deals with text (i.e., you're a programmer), and you never or rarely need to use unknown programs, then the terminal is great.

Think about it this way. Exactly what have you had to do to learn how to use web pages? Like, since the 90s when Mosaic would still render most websites. You haven't. It's point, click, scroll, and type. That user interface has worked, essentially unchanged, for nearly 30 years. You've gone to brand new websites, potentially written by people who don't speak your language, and you've been able to use the site because there's a shared convention that everybody uses. And _everybody_ does use it. There are _4.2 billion_ users of the world wide web [1], and the interface works for essentially everyone. That's an extremely impressive feat for interface design.

Meanwhile, nearly 50 years after vi was first introduced, it's still notoriously difficult to learn -- even the basics. You might argue that programming is more complicated than browsing the web, but realistically, _editing a text document_ is about as basic a task that you can have on a computer.

[0]: [https://docs.microsoft.com/en- us/windows/desktop/appuistart/...](https://docs.microsoft.com/en- us/windows/desktop/appuistart/designing-a-user-interface) [1]: [https://internetworldstats.com/stats.htm](https://internetworldstats.com/stats.htm)

<comment><USER9> > _This is only true, firstly, when what you 're trying to represent can be > accurately, completely, and most concisely represented by plain text. That's > actually a fairly narrow range, unless you're a programmer._

You would be surprised. I encourage you to visit the lands of Emacs at some time. The reason Emacs feels like an OS is because it turns out that _quite a lot_ of tasks can be accurately, completely and concisely represented as text on a 2D grid, and doing so enables interoperability features that are close to impossible to achieve with GUIs.

> _And secondly, it 's only true when you're not interested in using common > interface conventions to teach your users how to use your program._

Well, the difference between a tool and an educational toy is that the former is optimized for productivity, not ease of learning. I'm not saying that productive interfaces need to require a PhD to use; there are ways to make user-friendly advanced UIs - but reducing functionality for the sake of just easing the learning curve is optimizing for popularity, not utility.

> _it 's much easier when there are UI guidelines [0] that everybody sticks to > simply by virtue of how GUIs tend to work (i.e., there are existing common > libraries to describe the interface in predictable ways)._

Which no one gives a flying fuck about these days, because everything is web driven now, and the no.1 rule of webapps is that everyone invents their own variations of GUI, inconsistent with every other variation, and lacking any interoperability.

> _Exactly what have you had to do to learn how to use web pages? Like, since > the 90s when Mosaic would still render most websites. You haven 't. It's > point, click, scroll, and type._

I think you're confusing lack of functionality with lack of learning need. You have to learn to operate almost every website anew. There's just so little you can do on a modern website with modern browser, that it doesn't feel like a chore. Scroll, point, click. Oh, "weather forecast", click. Select city. Click. Select date. Click. They're not even optimized for consumption - <USER2> for ad exposure. Your typical experience with CLI/TUI is with tools optimized for providing value to the user. You may need to spend some more time up front figuring things out, but as a reward, you get much faster repeated access, better data, better control over format, _only_ data you need and zero noise. Is this for everyone? No. You do something once every year, point&click is fine. Stuff you do regularly? Web is wasting your life.

> _You 've gone to brand new websites, potentially written by people who don't > speak your language, and you've been able to use the site because there's a > shared convention that everybody uses._

That shared convention - "use mouse to click on stuff" \- is about as deep as the convention of "pressing buttons on keyboard types letters in". It doesn't make you comprehend websites. It only limits the scope of your initial confusion to "I don't need a keyboard for this (unless there are forms)".

> _nearly 50 years after vi was first introduced, it 's still notoriously > difficult to learn_

It's not difficult. It's just people have been trained to have a strong aversion to learning, where it comes to computers. Everything must be easier to use than your hair dryer, or it's garbage.

To anyone who believes this, that vim is hard to learn: I ask you to do this challenge. Fire up vimtutor, spend 10 minutes on it, report back whether it's still hard.

\--

I may sound confrontational here, but it's really just out of care. Truth be told, love of GUIs and the web, and allergy to CLI and TUIs is just reducing your own power in using computers. If one has better things to do, that's fair. But if one's spending a lot of time doing stuff on a computer, it's worth learning to do it well.

<comment><USER12> > To anyone who believes this, that vim is hard to learn: I ask you to do this > challenge. Fire up vimtutor, spend 10 minutes on it, report back whether > it's still hard.

I'm learning right now - as in, I started on Sunday. It's not hard to learn, but it's hard to use effectively. I could edit code twice as fast if I reverted to my standard keybindings, but I'm waiting for muscle memory to build.

Learning isn't hard, but building muscle memory is a tonne of work. It's like learning to touch type all over again.

<comment><USER13> Yes, the more your resist that urge, the faster that muscle memory will develop. It's even faster if you take a second to think of the most keyboard efficient way to do things with vi-keybindings and doing that, resisting the urge to use simpler keybindings. For example, `a` instead of `li`, or `A` instead of `lllllllllllla`.

Another important point is that one should never try to move around in INSERT mode. If you do, you're limiting yourself to moving around with the arrow keys and also are grouping multiple edits that you may want to undo piece by piece with u. If you need to move around, change to NORMAL mode and then move.

Yes, it's normal to hit Escape a lot. Personally, I like to have CapsLock act as Escape with `setxkbmap -option caps:escape`. If I ever really want to write something in all caps, it's always seemed faster to hold Shift with my left pinky.

> It's like learning to touch type all over again.

A very apt way to put it. Touch typing is like learning a language for your fingers. You do it once for your language (e.g. English), and now you're doing it for vi NORMAL mode, which is basically a language for text editing and navigation.

Like TeMPOraL said though, if you feel the frustration getting to you, you can just relax however much you want, and take things at the pace most comfortable to you.

</comment></comment></comment></comment><comment><USER14> I always find the benefits of portability to be a rather funny one: It's always immediately followed by 800 lines of dotfiles that do an incredible amount of customization.

The IDE vs. vim/emacs purist debate is always crazy to me. There are some places where IDE's are almost certainly better: Java in a large project in IntelliJ has to be 100x better than in Vim. For new languages or languages where there isn't substantial IDE integration, it's probably 5x better in Vim/Emacs with a nice configuration.

<comment><USER15> Just wait for the vim guy who will be like "but muh java plugins make it more efficient then IntelliJ"...

I think i am more productive in an IDE, faster. Sure if you have this insane VI/EMACS setup that you have tuned for years. Good for you, you probably are a fucking wiz.

My standard right now is a terminal & IDE combo. Working in the cloud era as a data person, you need to be comfortable with terminal & vi/emacs (vi for me but whatevs) as it makes life a ton easier. I hate watching co-workers do terminal shit and write code. Seriously guys if you invest a little time into VI pretty soon you are flying around your code. People literally watch my screen and are like WTF are you doing. I feel like a surgeon with precise incisions, cuts, tweaks. Compare this to spamming down arrow 30 times and then right arrow 80 times to get to a character in your editor...

<comment><USER9> > _Sure if you have this insane VI /EMACS setup that you have tuned for years. > Good for you, you probably are a fucking wiz._

To share a glimpse of the mindset of us on the editors side: that insane Emacs setup I've been tuning for years enables me to be "a fucking wiz" not just with Lisp. The very same setup lets me work efficiently with Python, Shell, configs, SQL databases, HTML+CSS+JS, running a personal Wiki, organizing tasks, tracking time spent on those tasks, billing customers for that time, reading/writing mail, and a bunch of other things. We love our editors because of compound interest - we get to reapply the same tricks to almost every task done on a computer (and we complain loudly when we can't shoehorn a task into editor-oriented workflow :)).

That said, I'll still grant you're better off with IntelliJ IDEA for Java. For the time being, at least. I'm having high hopes for language servers trend - they're the bridge that could enable vim and Emacs to reach feature parity in all the places they're currently deficient compared to IDEs.

<comment><USER16> > The very same setup lets me work efficiently with Python, Shell, configs, > SQL databases, HTML+CSS+JS, running a personal Wiki, organizing tasks, > tracking time spent on those tasks, billing customers for that time, > reading/writing mail, and a bunch of other things. We love our editors > because of compound interest.

I think that's really the takeaway here. Spending time in your environment allows you to accumulate skills that let you solve pretty much any text based problem you can think of.

Whether that's using emacs with elisp or vim with shell scripts and Unix tools isn't important. It's having that playground of an environment to solve arbitrary problems.

</comment></comment></comment></comment><comment><USER17> > GUIs are bloatware.

Why stop there? Most terminal editors are bloatware!

 _" When I use an editor, I don't want eight extra KILOBYTES of worthless help screens and cursor positioning code! I just want an EDitor!! Not a 'viitor'. Not a 'emacsitor'. Those aren't even WORDS!!!!"_[0]

GUI and terminals both have their place. There is no single combination of software that perfectly covers everyone's use cases. By all means, share details about the environment that works best for you, but blanket statements like that just create controversy.

Besides, modern terminals are really just GUIs designed to use the keyboard as the only peripheral. You don't necessarily need a REPL interface to support that use case.

[0]: [https://www.gnu.org/fun/jokes/ed- msg.html](https://www.gnu.org/fun/jokes/ed-msg.html)

</comment><comment><USER18> For me, things like VIM where you first have to configure the hell out of it are a pain. Every time you're on some other machine, all your customization is gone. So after switching machines a bazillion times over the years, making the same little tweaks over and over, I've learned to deal with the default config. What I didn't expect: It made me a lot more productive in the long run.

<comment><USER19> This is why defaults matter. People sometimes downplay changes with "well, you can just tweak it if you don't like it", but in the long run tweaking the install every time is effort. Especially when you're working on non-internet connected machines. It's why I get annoyed when for example Ubuntu stops shipping the ability to burn DVDs on the install disk.

<comment><USER20> The default vim config is pretty weird: incremental search is off by default for some reason, I think it still defaults to using tabs for indentation, it doesn't change the working directory to the current file's.

<comment><USER21> Incremental Search - This can be incredibly slow on large files and/or network mounted files. It can also interact with line wrapping and highlight search to slow vim to a crawl. So I think it makes sense to leave it off.

Tabs - That's the way god intended it. Stop trying to force your indentation width on me.

Stable working directory - This is how every text editor I'm aware of works. I can see use cases where you might want to change it manually or automatically, but I don't want to have to guess which directory I'm in every time I open a file.

Even some seeming no brainers like turning syntax highlighting on can be terrible because it doesn't work well with dark backgrounds or other random colour schemes.

</comment></comment></comment></comment><comment><USER22> Title is a bit misleading. Not sure this is "I'm not using GUIs" but rather "I'm using a terminal-based dev environment". I was hoping to find some nice terminal-based tools for browsing and e-mail and all the other annoying real- life things I need to use

<comment><USER23> I use eww to browse simple web pages when programming, and notmuch-el to read my email. For git I use Magit, and for Slack I use emacs-slack. As you might imagine, that all runs within emacs rather than vim.

In my own case, emacs is running in a GUI frame most of the time, but I often use terminal-displayed frames as well.

<comment><USER9> > _but I often use terminal-displayed frames as well._

Fun trick: if you run your terminal in 256 colors, the resulting terminal frame is nigh-indistinguishable from GUI Emacs for like 95% of the tasks. This works amazing over SSH, and allows me to work on heavy applications with full productivity even on a bus, with el-cheapo netbook and a mobile connection.

(I really need to write a blog post about this.)

</comment></comment></comment><comment><USER24> What are the chances that teletype simulation is the best possible way to interact with computers? This is what command line emulates:

[https://www.youtube.com/watch?v=AIWZ_pbLYqQ](https://www.youtube.com/watch?v=AIWZ_pbLYqQ)

Yes, this was _way_ better than punch-cards. But it was incremental and used completely arbitrary technology simply because it was available from somewhere else.

UI as a concept was poisoned by Windows and its shitty derivatives.

Like, there is _no_ real reason you can't compose stuff when using GUIs. In fact, it should be easier than pipelining commands.

There is no real reason the keyboard should be crippled by working in a GUI. It should be _easier_ to learn commands. (But have you noticed that we still don't have dedicated keys for cut, copy, pate, undo and redo? The most common operations present in almost all applications. But we have a Windows key and caps lock.)

Despite what people think, UI is still mostly unexplored territory with tons of potential for improvement.

BTW, my favorite code editor isn't an IDE. It's LINQPad, because it gives me immediate feedback without much noise. Going from it back to REPLs feels like a downgrade.

<comment><USER25> "still don't have"? For many years we _did_. "no longer have" is more correct.

* [http://xahlee.info/kbd/i/kb/sun_keyboard_left.jpg](http://xahlee.info/kbd/i/kb/sun_keyboard_left.jpg)

<comment><USER24> You're right, I should have said "still don't have on PC". I believe Xerox Star also had all those keys and then some.

This might not seem like a big deal for some. But there are two important points to consider:

1\. A lot of inexperienced user still go to mouse menu for copy-paste. This is horrible, but kind of natural, since a lot of UIs don't teach shortcuts.

2\. Cut/Copy/Paste/Undo/Redo should be treated as fundamental building blocks of user interaction, not some "shortcut" that happens to do a thing. They aren't even UI-specific. You can do all of them in a command line app (although the semantics would much poorer).

When I saw the demo of Xerox Star on YouTube I was both enlightened and depressed by the current state of things. Most people have no idea that icons were supposed to be objects and that interacting with them was supposed to be a way to send and direct messages to and between them.

<comment><USER25> I hope that the people who remember the OS/2 Workplace Shell have some idea. (-:

</comment></comment></comment></comment><comment><USER26> Used Atom and other IDEs for 5 years. 3 years ago switched to vim + tmux and love it. I'm very productive with my setup and I can't imaging going back.

I also love that I can git clone my dotfiles + an install script and I have my full dev environment on any machine in 2 minutes.

</comment><comment><USER27> You can always run a terminal alongside your IDE, you know! The IDE-type approach is generally very convenient, making your day go past that bit more smoothly, and the terminal is good for all sorts of things that are just a faff to do with a GUI.

(Interop is straightforward: just save from the IDE, operate on the file from the command line, then reload.)

This probably won't be to all tastes, but I've been happy working like this for years.

<comment><USER28> Before Android Studio, I found eclipse to be a laggy, buggy, slow-moving mess, but still I relied on it heavily for a variety of functions.

I started using your solution out of necessity, but with a little bit of context switching muscle memory found it to actually be a wonderful way to code.

</comment></comment><comment><USER29> I kind of wish this article was deeper on what benefits the OP was seeing from the plugins or what have you. I just was left hoping for something more from something that claimed to be a 'guide to the terminal' which usually is much more in depth to a particular workflow and you can usually glean one or two things you can add for yourself.

I'm from emacs land, and so generally using terminal over the emacs+GTK has a lot of limitations (ex: can't display or embed images, no drag and drop, copy and paste usually integrates better with the rest of the applications you are using when selecting regions of textual data). On top of that emacs comes with tiling for free where normally you would have to tmux+vim.

</comment><comment><USER30> > To avoid the annoying seconds in which vIM would freeze during tasks like > syntax-checks, neovim lets you run jobs asynchronously.

Vim 8 also has asynchronous tasks, as well as a builtin terminal emulator. So there is not much of a reason to use Neovim (except Lua scripts, maybe?).

<comment><USER31> It's faster, which I discovered after switching to it for Javascript/Typescript development. Also has better autocomplete plugins. Vim plugins just don't seem to have taken advantage of the async features yet.

<comment><USER32> Most of the nvim autocomplete plugins work on vim too.

<comment><USER31> Not for TypeScript, and not as fast (in my experience).

</comment></comment></comment></comment><comment><USER33> I like command-lines. I don't like TUIs.

Here's the litmus test for whether a program truly belongs there: Would it shit the bed if its stdout was a printer?

<comment><USER9> So you edit with ed? :). Also anything wrapped inside tmux would definitely defecate if hooked up to printer.

Some jobs are interactive. TUIs ain't bad for those.

<comment><USER34> That got to me brainstorming what someone might do if they were trying to write a modern line editor, targeting developers writing in... maybe not Java, but perhaps Go.

It doesn't seem like anyone has tried to build anything like that before. Most recent seems to be Rob Pike's sam from the 1980s, which (at one time in the 2000s at least) was the professed favored programming tool by Brian Kernighan and Bjarne Stroustrup.

<comment><USER35> I have an intuition that any line editor would find its limits quite fast for most existing code. (After having used ed a bit on regular files I came across, it's often both surprisingly useful and surprisingly obtuse compared with Vim.) Now, maybe a semantic structured language would find an amazing CLI editor. I'm vaguely thinking something like a lisp, or something with tagged structures. I guess the goal would be repurposing Vim's text objects to generic programming structures. That's as much as I can muster right now!

</comment></comment></comment></comment><comment><USER36> One of the most important take-aways of this article: you do not need tons of plugins! I see this very often in motivated and bright developers who want to start using `vim`. They copy a humongous config file, install tons of plugins, and suddenly, something breaks or does not work as expected. In my opinion, it is much better to start from scratch.

(besides, I have noticed a tendency in myself that is basically 'yak shaving for vim': the more plugins you have, the more you have to work on their configuration in order to make sure that they all work as expected...while this _feels_ very productive, it is actually the opposite of productivity)

</comment><comment><AUTHOR> Hello everyone, thanks for all your feedback!

Regarding IDEs and bloatware: here's a more detailed explanation of that argument

[https://lucasfcosta.com/2018/08/05/In-Praise-of- Plaintext.ht...](https://lucasfcosta.com/2018/08/05/In-Praise-of- Plaintext.html)

They're not _always_ bloatware, they have meaningful use cases, I just don't think most of them are in the domain of software engineering specifically.

I'll take some time to go through comments in more detail at another time and address them in the post if they're relevant to the context.

Thanks again for all the amazing feedback.

</comment><comment><USER37> This is why I'm creating a command-line alternative to Photoshop.

<comment><USER28> I once worked as part of a team which had graphics people who were allergic to the command line.

Of course there are some things for which Gimp/Photoshop is really necessary, but it turns out that there is a massive amount of image manipulation that is better done on the command line than within Photoshop. The people who were dependent on Photoshop would take endless hours completing the same tasks which can be done in seconds using the command line.

</comment></comment><comment><USER38> I love using nvim as my daily editor, but one thing I get from posts like this are that the authors rarely have to develop any kind of UI themselves, this author states they work in JS, but it looks like it's backend node work.

I'd be interested to hear of any other stories from developers that use both terminal for almost everything but also have to have a web browser open for development.

The best I do is have my browser and my terminal open 50/50 on one screen, but this isn't ideal, just a compromise.

</comment><comment><USER39> I'm one of the few people who agree with you. I'll bet I can do most things in vim faster than intellicode or whatever the new hotness is.

<comment><USER40> Java in intellij+ideavim is much faster than in (n)vim, and that comes from someone who has been using vim for nearly a decade. Intellij is just too good.

<comment><USER39> Been using Vim for about the same length of time... And the times I have used those emulators they just haven't been the same. Does the emulator support VimScript? Macros? Plugins? async jobs like vim8?

The terminal is my IDE I can open a file with a couple of keystrokes, run bash scripts from inside of my editor and just as easily be back navigating the terminal.

Maybe I'm missing something, but I don't see how intellij improves any of this stuff. I'd rather memorize compose-able bash commands, than intellij keystrokes.

<comment><USER41> What IntelliJ gives you is code generation and automatic refactoring to make writing Java less tedious. That being said, the tradeoff is increased resource usage.

<comment><USER42> > That being said, the tradeoff is increased resource usage.

Which for most developers in a corporate or small business environment is 100% worth it. Not ever corporate developer has a nice enough computer to run an IDE, but I bet that at least 95% do.

</comment></comment></comment></comment></comment><comment><USER43> For people using neovim, I've been impressed by this completion engine:

[https://github.com/neoclide/coc.nvim](https://github.com/neoclide/coc.nvim)

It uses Language Server Protocol and goes quite deep pulling completions, and can, eg, render function documentation into floating windows (not yet merged into neovim)

</comment><comment><USER44> Personally I reall like VScode debugger, and pretty much centered my workflow around it.

Sure, is really usefull to learn the ropes when work from terminal, because sometimes you will need to remote into a server.

Or even, as happened before, people will give me a shit machine to work from. I was prograing in C/C++ in payment terminals (you know, credit card machines), and they give me an old dell with only 4gb to work with.

The default environment was in Eclipse IDE, that usually fell bloated, and was even worst in this pc. So I just installed vim, make a fell changes in the .vimrc and I was read to go.

I fell things: I don`t really care about the whole h,j,k,l on vim. I see no problemas in using the arrow keys. Maybe this was a problem like 20 years ago, but now keyboards pretty much will always have the arrows, and they will work just fine. If you use a keyboard with the arrow keys, I really think you like to complicate things. Sorry, nothing personal.

</comment><comment><USER16> I think the biggest win for primarily using a terminal based environment isn't because Vim or other terminal editors lets you write or edit code that much faster.

Using command line tools and writing little scripts that you can easily integrate into Vim or another terminal editor really helps you solve your own problems that help make you faster at doing what you're doing. It really opens you up to thinking about how to solve problems in new ways.

Things that might require writing a custom VSCode plugin where you simply default to "fuck that" become chaining together 5 Unix commands and setting up a Vim key bind to solve the problem in 15 minutes to do something that will benefit the next 5 years of editing code or whatever you're writing.

<comment><USER45> Of course, you can bind terminal commands to keys in VSCode (or virtually any other environment) just as easily.

Personally I think these terminal vs. IDE discussions always revolve around straw man arguments and mythical divides. I can chain 5 unix commands together and use my IDE to navigate through code with my mouse. I don't have to choose one or the other and then feel superior about excluding a whole branch of technology.

<comment><USER16> > Of course, you can bind terminal commands to keys in VSCode (or virtually > any other environment) just as easily.

But what if those terminal commands need to interact with your editor?

How would you set up a simple VSCode key bind to take the currently selected text, run a shell script using the selected text as input and then replace your selected text with the output of the shell script?

With Vim, this kind of mentality is baked into how you work with the editor. Even as someone who is very new to Vim (about a month) it only took a minute of Googling to figure it out.

After having used Sublime Text for about half a decade, followed by VSCode for a year I never even thought to do something like that either. I just took the easy way out of thinking "yeah I'm not going to make a custom plugin for this, I'll just settle for some worse implementation that someone else wrote that does 75% of what I want". But just weeks after using Vim, I'm finding myself adding all of these little customizations that are specific to things I do every day. It feels like my editor is working for me, not the other way around.

> I can chain 5 unix commands together and use my IDE to navigate through code > with my mouse

I use the mouse in terminal Vim too. I don't really care about what purists have to say. For certain things I find using the mouse easier, so I use it.

<comment><USER45> This is what I mean about straw men and mythical divides.

Yes, there is a plugin to VSCode to do exactly that. But it doesn't matter. Different software has different features and all features are possible depending on what you care about. Vim is Vim. Vim doesn't have features because of some GUI vs. command line distinction -- it just has different features because it's a different product. Nothing stops a GUI IDE like VSCode from having those same features. And nothing stops you from using GUI windows and mouse in a desktop version of Vim.

<comment><USER16> > Yes, there is a plugin to VSCode to do exactly that.

Which plugin does that? Link?

<comment><USER45> [https://marketplace.visualstudio.com/items?itemName=yhirose....](https://marketplace.visualstudio.com/items?itemName=yhirose.FilterText)

</comment></comment></comment></comment></comment></comment><comment><USER46> I generally agree with Lucas' sentiments re GUIs and in his other article "In Praise of Plain Text."

But I currently select portions of text with a mouse by highlighting it, and then execute programs that accept that selection as input.

I no longer am limited to entire text that would be written to StdOut or piped or redirected and so could be treated as complete text files.

I can currently select and execute programs in a GUI in just 2 steps, using a mouse.

Admittedly, I integrated the <program to execute> into the GUI, but it was relatively simple.

To do this in Linux it looks like I would need to run a port of Plan9's Acme or the Wily editor.

The port of Plan9 is way more than I need, so I will look at Wily.

Maybe there are some other Linux editors that will do what my GUI currently does?

<comment><USER46> Answering my own question, Geany has "Sending text through custom commands" and ability to add custom commands via "Send Selection to->Set Custom Commands"

But it looks like this just replaces the selected text so it may be more for formatting.

I prefer a new window to open so the selected text isn't altered.

I know I can program vEdit+ to do this, but that is not Linux.

<comment><USER46> You need to look at TUIs (Text User Interfaces).

</comment></comment></comment><comment><USER47> This dead argument seems to re-animate itself once a year or so. But my question is this: Why not learn both the IDE of your choice and how to use your terminal/vim? No need to arbitrarily limit your own knowledge and abilities. It just makes you stronger.

</comment><comment><USER48> I want to give vim or emacs a real shot someday. I only really know the basic stuff and am fine with it. But I feel like I really need very good integration with the programming languages I work with like Go and Python.

Besides that, I'm looking forward to see when xi-editor [1] finally becomes a stable alternative to VS Code among others.

[1]: [https://github.com/xi-editor/xi-editor](https://github.com/xi-editor/xi- editor)

</comment><comment><USER49> I bloody wish there were a really good TUI toolkit for Python, something like Visual Basic for DOS but with a bigger selection of more advanced widgets.

<comment><USER50> What about ncurses?

<comment><USER49> As far as I know it neither does window management nor provides widgets (perhaps it can as Wikipedia says it's "added the form and menu libraries written by Juergen Pfeifer" in 1.8.8 (M1995) yet there is not a single example doing this with curses in Python), it just makes it slightly easier to build your own TUI toolkit on top of it rather than without it.

I know about 3 Python TUI libraries available to the date: urwid, npyscreen and picotui (the first 2 using curses and the 3-rd one not using it), neither of them is anything nearly as good as any of the GUI framework I've ever tried.

What I consider the best UI frameworks I've ever tried are WPF, WinForms, JavaFX and Swing - if there was something nearly as convenient to use in Python (or any other reasonably high level language, e.g. I don't mind JVM, Common Lisp or Ruby) but rendering itself via curses I would hardly ever use GUI as there would hardly be many valid reasons to besides watching/editing pictures and videos.

Perhaps if there were a good text-mode web browser featuring full support of modern JavaScript (which I believe is not really much work to implement for a person with experience in the area as they wouldn't have to code the entire JavaScript engine from scratch, all it probably takes is to attach V8 engine libraries properly and/or implement the entire browser on Node, the problem is this hardly has market value) we could use React, Angular or something. Many of the console-dwelling hackers will probably consider this kind of thinking profanity yet it's a fact most of the people (including those who could prefer TUIs) don't have time to debug C code and implement low-level stuff.

</comment></comment></comment><comment><USER51> Not specifically related to the article but related to the theme of the article. I have a web-based dashboard that I created using a ruby gem called Dashing that was created by Shopify but since discontinued. I'd like to use a terminal based dashboard instead. Any suggestions?

I came across WTF but don't know Go or see any documentation about building custom modules.

</comment><comment><USER52> I am sure the author is a power user of his tools. I tried to use Vim for more than a simple text editor for few days. I realised that it would very hard to replicate the productivity of a special purpose IDE(IntelliJ in my case) using Vim. tmux is great but if you are used to multiple windows or tabs that is fine as well.

<comment><USER53> After years of using Vim I gave up on the idea of using it as an IDE. It's really powerful for editing (navigation, searching, etc) but I am too dumb to do any debugging with it (xdebug, gdb, etc.). Too many panes, not enough memory slots for shortcuts.

So I tend to use IDE with good support for Vim key bindings.

So VSCode these days and waiting for a good neo vim based IDE.

</comment></comment><comment><USER54> The world moved from CLIs to GUIs. Guis have not only persisted, they've improved. If someone insists on using a CLI and nothing else, after all these years of the world having moved to GUIs, I wonder what prejudice is behind it.

How, reasonably, can all these tools beat a thing like Visual Studio? Must limit job opportinities too...?

<comment><USER55> Some tasks are better suited to the command line. Others are better in the terminal.

Package installation lies right in the middle for me. If I know exactly what I want sudo apt-get install is the quickest and easiest. If I am not sure exactly what I want its easier to browse around using synaptic.

I can do more complex greps on the command line than most GUI tools will allow me to use.

<comment><USER56> I tend to use apt-cache search a lot if I know generally what I want but don't know the exact package name. It lets you use regular expressions when searching and you can restrict it to just the package names by giving it the --names-only switch.

If I'm actually wanting to install a game of some type, but don't know what I want to try out, then I'll load up synaptic.

</comment></comment></comment><comment><USER57> I mean .. use whatever you feel comfortable with, make sure you understand what you're doing, the terminal is the closest interface to the OS.

I personally use it a lot but this arguments have been going on over (and over)+ again. And it won't be the last time :-)

.

</comment><comment><USER58> The good development environments now-adays allow you to do everything from the keyboard and not click on anything. PyCharm being a good example.

</comment><comment><USER59> Even your terminal emulator is a GUI app itself. Don't say you are not using GUI app unless you boot to a command line interface directly.

</comment><comment><USER60> I'm not being funny but why do people prefer writing out lines of command line text versus right click and select in two clicks?

<comment><USER28> For many people, writing out the command text is faster. Fantastically faster, when you take advantage of the efficiency improvements like tab completion, readline hotkeys, aliases, scripts, etc.

And you don't lose time from whatever you do before and after, by taking your fingers off the keyboard.

<comment><USER60> With wireless mice you can move your hand nearer than they keyboard and even with tab completion navigation between files is hard compared to just a couple of clicks?

<comment><USER28> No no, the problem isn't reaching across the desktop. The problem is literally taking your fingers off of home row. It's fine if you're in a phase of your activity where you're moving slowly, contemplatively. But if there's a series of tasks that we want to accomplish and we already know what they are, lifting your fingers off of home row will slow us down! Wireless vs wired mice have nothing to do with this.

As far as what is considered to be hard, it depends on the individual.

For many of us that spend a great deal of time on the command line, many multi-step activities, including those related to file manipulation, become like a single action. Consider the difference between touch typing and hunting and pecking. To an experienced secretary, the phrase "to whom it may concern" can become a single action, executed by the fingers without any thought whatsoever, while for an inexperienced typist that's 20 individual actions. Similarly, a whole series of file manipulations, git actions, SSH actions, become hardwired into our muscle memory and we don't even think about the steps. We just decide that we're going to do something, and let our fingers take care of it. This is much easier and faster then manipulating a GUI with a mouse.

<comment><USER60> I would like to see data on this, any studies done?

<comment><USER28> A healthy skeptic doesn't demand data for claims like "touch typing is faster than hunt-and-peck".

<comment><USER60> A healthy skeptic? Lol what? Anyone who feels they have a point should be able to back it up with sources or data

<comment><USER28> No. Reality is not established by publication. You can, and should, observe some things for yourself.

It is obvious that touch typing is faster than hunting and pecking for most people who:

\- have 10 fingers

\- have invested sufficient effort to learn touch typing

To demand sources for this is disingenuous.

<comment><USER60> I can observe the sun is hot, but doesn't mean I can tell what temperature it is. I think without data of timings across different applications and uses, it's hard to prove either side. I am open to both sides having the possibility of being quicker

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER61> Take a look at fish shell if you are in the terminal. It can almost read your mind.

</comment><comment><USER62> I got the feeling that articles like that are multiplying? And many of them are using a Mac. Up until now I haven't seen anyone having a good setup with text-browser, office-suite (not ide I mean libreoffi e for the tty), image viewer (and I know there are quiet a few), pdf viewer,...

So imho it's a bit clickbaity calling this setup (which had nothing new as far as I' m concernt) "still not using guis".

Maybe the dot files got something interesting...

Edit: Nope they didn't in fact hey are a joke a few alias, neovim, zsh and tmux (mac specific stuff like brew I didn't look at) one "useful" thing thought albeit not for me where the reference to xkcd 530 :)

</comment><comment><USER63> What's with capitalizing it vIM? Website, man page, :help, none of those have it capitalized that way.

<comment><USER13> Weird, right? You'd think it was a typo, but it was a very consistent typo. Maybe they did it lowercase, then they `s/vim/vIM/`, hitting CapsLock and Shift at the same time when they wrote that.

</comment></comment><comment><USER64> Dah, What's the point?

</comment><comment><USER65> terminals unfortunately are a complete no-go for "all" Asian languages.

to my knowledge right now no terminal emulator properly handles

* cjk- specially so called double width chars

* Indic- dependant vowels

* west asia- rtl

that's the entire breadth of Asia for you who cannot use terminals if hey want to write a letter in their own language.

<comment><USER66> With urxvt and hassle to install the correct font, it is doable to edit cjk using vim. Though it is less usable than using English, since you have to go back and forth to input cjk for input, and switch back to English for navigation and vim tricks. Some binding like f[some cjk work] becomes pointless since you are effectively typing f + (ctrl + shift) + (cjk word input) + (Ctrl + Space). You would rather use nano for extensive editing cjk. However, one or two words in cjk in some codebase is okay and not that bad.

</comment></comment><comment><USER67> Narcissism of small differences. Pointless blogspam. Also, Neovim is much closer to visual studio than it is to something like nano or whatever.</comment>


The Worst Amazon Horror Story I Have Ever Heard - <AUTHOR> http://www.startupnation.com/start-your-business/plan-your-business/amazon-fba-program/

<comment><USER2> [http://webcache.googleusercontent.com/search?q=cache:voRF_fx...](http://webcache.googleusercontent.com/search?q=cache:voRF_fxJYJIJ:www.fbamastery.com/the- worst-amazon-horror-story-i-have-ever-heard/+&cd=1&hl=en&ct=clnk&gl=us)

</comment><comment><USER3> Previous HN discussion (~10 months ago): [https://news.ycombinator.com/item?id=6751710](https://news.ycombinator.com/item?id=6751710)

</comment><comment><USER4> Should be changed to [http://www.startupnation.com/start-your-business/plan- your-b...](http://www.startupnation.com/start-your-business/plan-your- business/amazon-fba-program/)

<comment><USER5> And have a giant ad thrown at your face first thing? No thanks, webcache is fine.

<comment><USER4> This is blogspam, unrelated to the site being down.

</comment></comment></comment><comment><USER6> The fixed position form on the left hand side lays over the content unless your browser is really wide. Basically makes the content unreadable on mobile.

</comment><comment><USER7> I think the server melted.

</comment><comment><USER8> unreadable

</comment><comment><USER9> Url changed from [http://www.fbamastery.com/the-worst-amazon-horror-story-i- ha...](http://www.fbamastery.com/the-worst-amazon-horror-story-i-have-ever- heard/), which copied this one. Post buried as duplicate. Thanks iancarroll and mileswu.

</comment><comment><USER10> This is utterly bogus.

According to the article he really did sell a counterfeit item.

Presumably accidentally, and perhaps the punishment does not fit the crime, but he can't claim complete innocence here.

And this demonstrates that he doesn't understand how amazon works:

> When we sent out all of our items to the FBA program, they all went to 2 > different Amazon warehouses. Now that I'm receiving them back, guess what? > So far, the new sealed product has arrived back from 9 different warehouses. > Yep, they're sending back someone else's new sealed items to me.

NO! Amazon has a program where they internally distribute items to warehouses all over the US to increase shipping speed. It does not mean they are shipping someone else's items back to you.

<comment><USER11> What about the part where he doesn't even sell new, sealed items and the offending product that caused such huge punishment, was precisely the type of items he doesn't even sell?

<comment><USER10> Read it again. He didn't say that.

Look I know I'm getting downmodded, but I've read these types of things before and people _always_ spin things to their benefit, but it's usually possible to see thought it. And here it's easier than usual.

Amazon clearly said: "No commingling." His response? Amazon must be in cahoots with the studio. No, there is a much simpler explanation: He messed up and sold a counterfeit item.

It was clearly a mistake and he should have apologized for the error and pledged to check even better instead of claiming no error.

</comment></comment></comment><comment><USER12> Color me naieve here.....

Some signed some kind of agreement with amazon, has tens of thousands of items in their warehouses, and is running a business where amazon is basically responsible for everything.

Amazon decides to drop them.

The reasoning sounds unfair, but this business is unable or unwilling to pay for lawyers, and didn't consider what would happen in the event the relationship ended and there was still stock in the warehouse?

That sounds like a failure on the part of the seller to me.

<comment><USER13> Well, there's also the part where comingling may have made them out to be the seller of someone else's counterfeit product.

But yeah, you can't run a real business if you can't pay for things like lawyers.

<comment><USER10> According to the article there was no commingling - he just suspected there was, but there wasn't.

<comment><USER13> Amazon claimed that, yes, but it was also called into question.</comment></comment></comment></comment>


Ask HN: Startups in Europe - <AUTHOR>

What are startups like in Europe? Are they as common as they are here in the United States? Where is the Palo Alto of Europe? Please feel free to include other information one might find useful! <comment><USER2> Startups are getting more support in Europe. There are a number of good accelerators: Techstars has affiliates in Europe. Startupbootcamp is creating a network of Accelerators in Denmark, Ireland, Spain and others. Hackfwd is mentioned in another post. I work with LeCamping.org in Paris.

European governments see that startups create jobs. France (believe it or not) has a whole range of support services and cash for innovative startups.

It is still harder to form a company, open a bank account and get going. In America it takes a credit card and an hour. In France and England it takes more time and effort.

Another believe it or not - salaries for engineers are lower in France than America. Education is great and there are a large number of people that want to work for a startup.

There is no Palo Alto of Europe - Yet. Many locations are trying to win that race. Overall there are many opportunities.

</comment><comment><USER3> I would say startups in Europe feel more like a sub-culture than an appreciated part of the eco-system: they are common but the local media is not picking them up as much as in the US.

To get you started, you could look at SeedCamp (<http://seedcamp.com>) or TechCrunch's European site (<http://eu.techcrunch.com>).

Once you go through the articles and posts there, you might start to believe that Berlin is the epicenter of attention right now. However, the culture to embrace failure as well as the VC money aren't there (yet?).

</comment><comment><USER4> Check HackFwd <http://hackfwd.com/> .</comment>


Major sites running unauthenticated JavaScript on their payment pages - <AUTHOR> https://shkspr.mobi/blog/2018/11/major-sites-running-unauthenticated-javascript-on-their-payment-pages/ <comment><USER2> I ALWAYS run 3rd party JavaScript on my payments page. That's what Stripe is, after all.

In this blog post the author identifies probably 1 questionable third party resource. As scary as it sounds it's not exactly easy to just compromise major JS providers and start stealing cc data. It's possible but instances of it happening are extremely rare.

Knowing what you're loading is more important than not loading anything. It's not realistic to expect no third party js in today's world, and even versioning+SRI has issues because it solves one problem by creating a new one.

<comment><USER3> I think they point they're trying to make is that there's no guarantee the script you get isn't hacked unless you use SRI. The focus isn't on third-party javascript, but un-secured javascript.

</comment></comment><comment><USER4> It would be a good idea for Chrome to display an alert similar to the non- HTTPS resource loading if integrity checks are not present for externally loaded scripts.

The danger of serving external JS without integrity check its is very similar to having non-HTTPS connections in your website.

<comment><USER5> Why particularly for Chrome?

<comment><USER6> Are you implying there are other browsers?

/s

The wonderful web as we used to know it has devolved into a pretty sad thing (and web-developers with it).

</comment></comment></comment><comment><USER7> > What's especially annoying about this, is that the CDNJS website has a "one- > click copy" for SRI.

Actually, from the screenshot it's clearly "two-click" and "one-click" provides a link without SRI. Obviously the vast majority of people in a rush are going to use the "one-click" option, secure or not.

There's no reason why the SRI option shouldn't be default on CDNJS when the URL is specifying a specific version. Don't trust consumers to be competent, help them out with good UI patterns. We should be advocating default = secure here.

<comment><USER8> > We should be advocating default = secure here.

Leaving no room for them to screw it up is always a good option. I know (some) Junior (or really any) devs don't always consider security at all, so they will take the quickest option even if it's wrong or insecure, so long as it "works".

<comment><USER9> Particularly with management breathing down their necks to deliver.

</comment></comment></comment><comment><USER10> One problem with SRI and locking down your version of a third party JavaScript library is you won't get security updates the third party makes to that library until you manually update your link. Another issue is third parties don't offer versioned links at all so SRI will prevent the link from loading when the library code is updated.

What's the best solution to this? Expecting every website owner to manually review and approve each library version update has problems too and you have to be realistic in accepting most website owners aren't going to be constantly reviewing their libraries.

Why is there no mechanism to allow a JavaScript bundle to be signed so we can be more confident the original developer made the modification like we do in other ecosystems?

Are there ways you could add more sandboxing to scripts to limit their potential damage? Iframes let you do this (i.e. so scripts can't modify or read the outer page) to an extent for some scenarios.

<comment><AUTHOR> The majority of those scripts are version controlled already. They're explicitly using V1.0.3 or whatever.

So responsible site owners are already testing and approving version changes.

<comment><USER11> Indeed, to comply with PCI-DSS v3.2.1, requirement 6.1 you must "Establish a process to identify security vulnerabilities, using reputable outside sources for security vulnerability information", and requirement 6.2 you must "Ensure that all system components and software are protected from known vulnerabilities by installing applicable vendor supplied security patches."

So you need to have an inventory of all vendor supplied software and hardware, monitor for security advisories from those vendors, and have an adequate change management process to respond to those advisories in a timely fashion.

All of that needs to be auditable.

</comment></comment></comment><comment><USER12> > If you absolutely have to load someone else's code, check to see if it has > been altered.

Third party JavaScript code can be altered for legitimate reasons. e.g. adding new features, refactoring, security fixes, etc. In order to prevent a site which uses SRI from breaking every time a 3rd party makes an update to a js file, 3rd parties should _version_ their JavaScript resources with a version number in the URL. This, of course, places the added burden on the site that uses the 3rd party JavaScript resource. They need to update the version number in the URL and update the SRI every time the 3rd party releases an update. And this should be a manual process because automating it would defeat the whole point of SRI.

<comment><USER13> Why not just copy the file, inspect it, and serve it from your own servers?

<comment><USER12> It's because that can break the site due to the browser's sandbox permissions model. Scripts are only allowed to make ajax calls to their origin servers. Also, serving a 3rd party script from the 1st party's domain gives the 3rd party permission to make ajax calls to the 1st party domain, which may open up security holes.

<comment><USER14> What? You must be talking about some opt-in sandboxing.

What about the millions of sites that load jQuery from a CDN and then use $.ajax() to make requests to their home domain?

</comment></comment></comment></comment><comment><USER15> Everything great and bad about JavaScript can be explained by a simple facet of human behavior and one simple principle of technology.

JavaScript has a low barrier of entry, which means you don't have to be incredibly competent to write code or get hired to write code. It also means a novice with incredible potential could eventually learn to build great things in the language.

An interesting phenomenon of human behavior is that people cannot practice charity and profit simultaneously (altruism versus egoism). It is a forced dichotomy. You have to choose and there is no middle ground. This forced choice is present even when the environment, incentives, and stimulus allow for both. This is long observed in scientific philosophy, but there is also a fair amount of behavioral health research on this as well.

These factors could explain, even when normalizing for hours of practice, why open source practitioners may develop more skill and interest than developers limiting their practice to employment contributions. It might also explain why code in commonly despised fields, such as online advertising or e-commerce checkout platforms, are so incredibly awful and negligent.

<comment><USER16> > _An interesting phenomenon of human behavior is that people cannot practice > charity and profit simultaneously (altruism versus egoism). It is a forced > dichotomy. You have to choose and there is no middle ground. This forced > choice is present even when the environment, incentives, and stimulus allow > for both. This is long observed in scientific philosophy, but there is also > a fair amount of behavioral health research on this as well._

This may be common but it's not an absolute. There _is_ a middle ground, you _can_ profit without exploiting anyone, for the definition "use [someone or something] in an unfair or selfish way". The trick is to exploit using the definition "make full use of and derive benefit from", and making full use of anyone's talents and skills always includes improving their morale, which is mutually exclusive with being a selfish or greedy company.

<comment><USER15> > There is a middle ground, you can profit without exploiting anyone

That is not a middle ground. It is one of two classes of motivations. Profit does not imply exploitation, manipulation, or any form of dishonesty.

</comment></comment></comment><comment><USER17> The method for the BA hack was _not_ from javascript hosted externally. See [https://medium.com/asecuritysite-when-bob-met-alice/the- brit...](https://medium.com/asecuritysite-when-bob-met-alice/the-british- airways-hack-javascript-weakness-pin-pointed-through-time-lining-dd0c2dbc7b50)

<comment><USER18> Yep, was going to say exactly this.

All the SRI, CSP, etc is great, but if you can't control your own site you're screwed regardless.

</comment></comment><comment><USER19> I suspect this is common enough that a list of who DOES use SRI would be shorter.

</comment><comment><USER20> I'm disappointed by the response he got which said

 _" This appears to be more of a risk acceptance rather than a vulnerability."_

I understand that some risk is acceptable but surely that is proportional to the cost of removing the risk and in this case that cost is so small.

<comment><USER21> I agree that it should be fixed but we can't know that the cost is going to be small. Some websites are generated via dozens of layers of abtractions and maybe there's no options to add the sri without going deep inside some messy frameworks and changing several of these layers.

</comment></comment><comment><USER22> Is there a good browser plugin that tracks changes to sources of js files? That way you could mark certain sources as trusted, but whenever they change, they would be blocked until you mark them as trusted again.

<comment><USER23> But how is it going to know the authentic source?

<comment><USER24> The source doesn't matter, only the content. If the hash of the file matches the hash you've already approved for jquery-3.3, then the file is (unless someone's found a collision in the hashing algorithm that hasn't been disclosed) jquery-3.3.

<comment><USER25> I think what they meant is how do you identify the authentic content the first time around?

<comment><USER26> By manually reviewing the said file or by trusting a central authority of some sort.

</comment></comment></comment></comment></comment><comment><USER27> First, the WHATWG is better to finally settle on the hash standard, and produce a final normal standard document. But it being WhatWG, will not do that.

Second, do not ever use 3rd party code served on payment pages, or, even better, have a wholely JS free payment page.

Third, that fact alone that people are using all kinds of js frameworks for super duper critical code, tells of how little concern is given to security there.

Fourth, PciDSS, where are you when we need you? Weren't it already against the rules to allow loading of code from third parties on payment pages???

<comment><USER28> > Fourth, PciDSS, where are you when we need you? Weren't it already against > the rules to allow third party code on payment pages???

No.

You're required to get audited, document certain decisions, and follow some pretty high label 101 level security requirements. You can absolutely use third party libraries on payment pages (source: we do and are PCI certified).

<comment><USER27> Really, so, you are truly allowed to serve code from random CDNs??? That's really something. I never could've imagined that.

<comment><USER28> PCI is a specific set of requirements. We've met those requirements and our certified auditor agrees.

Which specific part of PCI do you feel third party libraries violates?

<comment><USER27> I don't know, but I always had that feeling. Given that they are so paranoid with payment terminals, I thought that online payment pages will be no different.

<comment><USER28> The requirements for payment terminals are extremely lapse. That's why there's the meme about Windows XP restart screens.

Several recent breakins at major retailers have been directly against payment terminals.

</comment></comment></comment></comment></comment></comment><comment><USER29> It's for reasons like this that I recommend uMatrix for Firefox [0] and Chrome [1]. It's default function is to block scripts that don't belong to the root domain of the site you're visiting, and you can whitelist 3rd-Party domains by asset type on the fly from a dialogue.

It's really handy for eliminating dodgy dependencies, and it doesn't break half as many sites as NoScript.

[0] [https://addons.mozilla.org/en- US/firefox/addon/umatrix/](https://addons.mozilla.org/en- US/firefox/addon/umatrix/) [1] [https://chrome.google.com/webstore/detail/umatrix/ogfcmafjal...](https://chrome.google.com/webstore/detail/umatrix/ogfcmafjalglgifnmanfmnieipoejdcf)

<comment><USER30> uMatrix is great because it doesn't just block scripts. You can block iframes, images, etc... You can also turn off stuff like webworkers. It's not perfect (I've noticed a few holes around how it manages cookies, for example), but it's _really_ good.

Removing scripts is nice, but if you're trying to prevent obscure attacks[0] or even common tracking techniques from 3rd-party sites, it's not enough. People look at Javascript like it's the primary insecurity on the web; in reality any time you can conditionally make a request to a server for any reason from anywhere, that's a vulnerability.

So with uMatrix you don't just get the ability to say, "don't run scripts", you get the ability to conditionally and granularly blacklist/whitelist domains themselves.

[0]: [https://www.mike-gualtieri.com/posts/stealing-data-with- css-...](https://www.mike-gualtieri.com/posts/stealing-data-with-css-attack- and-defense)

</comment></comment><comment><USER31> Before SPA, one could restrict 3rd party scripts from being alive on the payment page.

With the rise of SPAs, it seems there's going to be more and more 3rd party scripts unintentionally running on payment pages.

</comment><comment><USER32> [https://caniuse.com/#feat=subresource- integrity](https://caniuse.com/#feat=subresource-integrity) :(

Why it's not supported on "iOS Safari"...

</comment><comment><USER33> So much for the pen test and the code review conducted by the PCI auditor. I guess I'm the only idiot who actually follows the guidelines....

</comment><comment><USER34> So in other words, if you're running ads or A/B testing scripts on your payment page, you're open to security issues without much in the way of a fix. It's easy to say to use hashes and resource integrity, but some things are loaded from third party servers and change on the fly/dynamically...

</comment><comment><USER35> SSL is just half the solution when there is enough attack surface available through JavaScript. Users should have the ability to encrypt data within the browser (before any JS kicks in) only to be read by owners of a trusted domain.

Keygen was the way to go; there's some hope with FIDO.

</comment><comment><USER36> I am so old school, but I only use local installation of 3rd party tools and libraries. That means I have to update them, but that also means that no hidden update will break my site or worse, introduce vulnerabilities.

</comment><comment><USER37> How do people here feel about a website including 3rd party JavaScript from their payment processor or bank on the payment page? This article mentions Adyen JavaScript being included, but that seems fine here?

<comment><AUTHOR> As I said, it is probably fine. But it does introduce yet another small risk. Perhaps the best solution is to just send a user to the payment provider rather than keeping them on your site.

<comment><USER37> What are the repercussions if Adyen was hacked in this case? Would they be able to steal session cookies for the user's account on Spotify? Something else malicious?

</comment></comment></comment><comment><USER38> > The Guardian

> Despite being a tofu-knitting member of the bourgeoisie, I am yet to > subscribe to teh Gruan. If I did, I'd risk their affiliate tracker going > rogue and stealing my organic credit card details.

<comment><AUTHOR> I know what I'm about!

</comment></comment><comment><USER39> > Google supports SRI - but doesn't mention it anywhere on their Hosted > Libraries site.

It's not Google/CDN part to support SRI - its the browser itself

</comment><comment><USER40> I don't think you need SRI if you already have SCP with hash?

SCP covers dynamically loaded scripts also, which should provide more security than SRI.

<comment><USER41> I think you meant CSP (Content Security Policy), not SCP

<comment><USER40> Yeah I mean CSP - [https://developer.mozilla.org/en- US/docs/Web/HTTP/CSP](https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP)

Specifically script-src: [https://developer.mozilla.org/en- US/docs/Web/HTTP/Headers/Co...](https://developer.mozilla.org/en- US/docs/Web/HTTP/Headers/Content-Security-Policy/script-src)

To many acronyms, my mind was probably thinking about SICP - [https://mitpress.mit.edu/sites/default/files/sicp/index.html](https://mitpress.mit.edu/sites/default/files/sicp/index.html)

</comment></comment></comment><comment><USER42> I love these type of findings. Good job!

</comment><comment><USER43> > "SRI has been available for two years and it still isn't being used enough."

Two years is relatively fresh. There's probably a significant amount of customers with browsers that don't support this.

Can't we just implement a simple poor-man's SRI ourselves? Download the 3rd- party script, hash it, check hash, proceed to exec() if all is well? This should be supported by much older browsers.

<comment><USER44> Actually, IE and iOS Safari are lagging but other major browsers seem to have support for SRI for quite some time: [https://caniuse.com/#search=sri](https://caniuse.com/#search=sri)

</comment></comment><comment><USER45> I wonder if SRI management could be done at the browser/plugin/unblock level? Ie block the loading of a script if the content hash different from the last time it was loaded.

</comment><comment><USER46> iDeal redirects you to the bank's site. Seems safer to run your payments through them.</comment>