i agree vim is efficient for switching between existing files/buffers. but *opening* new files is a PITA, which subtly affects programming-behavior of its users -- towards javascript-programming tending less towards fragmenting code with multiple files/modules (and more towards code-locality).
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 <andyearns...@gmail.com> wrote: > 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
