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, <kaizhu...@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. > > "scalable" javascript tooling/frameworks that allow large-scale > 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 <ljh...@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 <kaizhu...@gmail.com> wrote: >> >>> adding a datapoint on effects of vim-editor on my javascript >>> coding-style. this is to expand on discussion of "JavaScript and Syntax >>> Research Methods" in tc39-notes [1]. >>> >>> 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 >>> >>> because of above properties, i default to writing javascript >>> applications as a single, large file (which may get broken up if it becomes >>> "too" large, e.g. >10k sloc). developing javascript-apps with a single >>> 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 >>> external-dependencies >>> 3. general preference to write self-contained code that easy-to-reuse by >>> copy/pasting into a new project [2]. >>> >>> an argument against writing javascript-applications as a single, >>> self-contained file, is that it leads to merge/commit conflicts when >>> multiple devs are working on same file. its valid ... except most >>> javascript-products are developed by just 1-3 js-devs. for the frontend, >>> its usually just 1 developer. the hype of making javascript "scalable" so >>> 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. >>> >>> [1] JavaScript and Syntax Research Methods >>> >>> https://github.com/rwaldron/tc39-notes/blob/7a4af23d/meetings/2019-06/june-6.md#javascript-and-syntax-research-methods >>> >>> [2] documentation of various [minimal-dependency] self-contained >>> functions that can be copy/pasted >>> >>> https://kaizhu256.github.io/node-utility2/build..beta..travis-ci.org/apidoc.html >>> >>> >>> >>> >>> screenshot of me vim-editing multiple locations of one, large >>> javascript-file (each sub-window is a different location of the same file). >>> [image: vim-editor-min.png] >>> >>> _______________________________________________ >>> es-discuss mailing list >>> es-discuss@mozilla.org >>> https://mail.mozilla.org/listinfo/es-discuss >>> >> _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
