kaizhu256 at gmail.com
Fri Jun 28 19:03:42 UTC 2019
i agree vim is efficient for switching between existing files/buffers. but
*opening* new files is a PITA, which subtly affects programming-behavior of
fragmenting code with multiple files/modules (and more towards
on customizing vim, i think its more productive that you get used to
editing with default settings. it certainly helps in (unix/mac)
coding-interviews and troubleshooting production-machines, where the only
guaranteed editor is [an uncustomized] vim.
On Fri, Jun 28, 2019 at 1:49 PM Andy Earnshaw <andyearnshaw at gmail.com>
> I would agree for Vim in its basic form but have successfully used vim,
> for several years, with the Ctrl+P extension to quickly and efficiently get
> around codebases with many files. It also has a buffer lookup for accessing
> already open files, and other shortcuts like Ctrl+B/Ctrl+6 make switching
> between 2 files for simultaneous editing a breeze, which I found invaluable
> for writing tests alongside the main code.
> Vim gets more productive the more you customise it, but that makes it
> harder to use when you're on a different machine without those
> customisations. Still, most of the time you'll take your config with you. I
> would say that if you feel inefficient at doing something in Vim then it's
> something you can work on.
> On Fri, 28 Jun 2019, 19:30 kai zhu, <kaizhu256 at gmail.com> wrote:
>> 3 frontend-devs is reasonable and maybe ideal -- but reality is most
>> shops can only afford 1 frontend-dev. i remain convinced 5 js-devs is
>> around the practical limit for most products. going over that
>> magic-number, and people become confused about their
>> areas-of-responsibility -- allowing mediocrity/siloing to flourish from
>> lack of accountability.
>> collaboration are solutions-in-search-of-a-problem. they should remain as
>> in-house solutions for the unique problems faced by
>> google/facebook/salesforce/etc, and are inappropriate/overengineered for
>> general-purpose product-development.
>> On Fri, Jun 28, 2019 at 12:58 PM Jordan Harband <ljharb at gmail.com> wrote:
>>> As much as I like vim, this seems like more of an argument against using
>>> vim than anything for the language - also it's not "usually" just 1
>>> frontend developer; altho that may be your experience. I often like to say
>>> it's *never* just one - even if it's you, it's also "you in 6 months", and
>>> that person is really annoyed with you.
>>> As an anecdotal data point, my garage startup which had no funding had 3
>>> JS devs working on our frontend. I would argue it's not very cost effective
>>> to *under*invest in frontend dev, but obviously everyone has different
>>> opinions on that - and it's not relevant to this discussion list.
>>> On Fri, Jun 28, 2019 at 9:59 AM kai zhu <kaizhu256 at gmail.com> wrote:
>>>> Research Methods" in tc39-notes .
>>>> vim has the following file-editing properties:
>>>> 1. poor UX in opening new files
>>>> 2. efficient content-search/jump/traversal of large files
>>>> 3. can display the same file in multiple editing-windows
>>>> applications as a single, large file (which may get broken up if it becomes
>>>> js-file leads me to:
>>>> 1. prefer reusing external-code by copy/pasting it into single-file
>>>> rather than load it as commonjs/es-module
>>>> 2. be selective about what external-code i want to copy/paste --
>>>> generally only self-contained or "rolled-up" ones w/ minimal
>>>> 3. general preference to write self-contained code that easy-to-reuse
>>>> by copy/pasting into a new project .
>>>> self-contained file, is that it leads to merge/commit conflicts when
>>>> multiple devs are working on same file. its valid ... except most
>>>> you can have 20x people working on a product is just that -- hype. there
>>>> are very few real-world products where its cost-effective to have more than
>>>> 5 js-devs working on it.
>>>>  documentation of various [minimal-dependency] self-contained
>>>> functions that can be copy/pasted
>>>> screenshot of me vim-editing multiple locations of one, large
>>>> [image: vim-editor-min.png]
>>>> es-discuss mailing list
>>>> es-discuss at mozilla.org
>> es-discuss mailing list
>> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 37924 bytes
Desc: not available
More information about the es-discuss