effect of editor/ide on javascript programming-style

kai zhu kaizhu256 at gmail.com
Thu Jul 4 18:26:26 UTC 2019

vim is arguably the best tool for editing large, self-contained, "rollup"
files like bootstrap.css, jquery.datatables.js, highcharts.js, jslint.js,
etc.  it (and emacs) are the few mainstream editors i'm aware of with
search-as-you-type and bookmark-location functionalities, enabling
sub-second traversal of large text-files.

having 1-5 js-devs develop a web-product consisting of a dozen,
self-contained, "rollup" css/js files is generally more cost-effective than
having 20+ js-devs working on a hundred, fragmented css/js files. in the
former there's:
1. less loss of critical-knowledge about file/module-dependencies and
transpiling/tooling-config-settings when team-members leave the project
2. less siloing/loss-of-big-picture, where you end up micromanaging
"general-purpose" code rather than the UX-workflow code
3. reduced painpoint of operational-deployment, since much of the
"webpacking" is already baked

/* off-topic */
also, in the unlikely scenario a product evolves to legitimately require
20+ js-devs, it would have developed custom, in-house tooling/frameworks
along the way.  a logical-step for many companies is to market their
in-house tooling as "general-purpose" tooling for javascript
product-development.  some of these tools do meet the small-scope,
general-purpose needs of typical 1-5 js-dev web-projects (e.g.
twitter-bootstrap), but most are over-scoped and terribly cost-ineffective.

On Sat, Jun 29, 2019 at 9:10 AM Felipe Nascimento de Moura <
felipenmoura at gmail.com> wrote:

> Really?! That actually surprises me!
> I haven't used vim to develop for quite a while, but always saw it as a
> reference in performance.
> For instance, I'm right now with 5 different VSCode windows opened (each
> one with a different workspace, for each project I'm currently working on),
> and each of those windows have around 20+ opened tabs. I also like
> splitting the screen of some of those windows in 4 depending on the
> project. I see no problem at all either opening a new file, nor switching
> between them.
> I see some lagging, though, when I open a huge json file, or a csv file
> that is too long. That's actually why I like keeping files small.
> I'm saying this because you feel like these experiences could change the
> developer behaviour. Made me think how my behaviour actually changed to
> USING multiple smaller files instead of bigger ones.
> [ ]s
> *--*
> *Felipe N. Moura*
> Web Developer, Google Developer Expert
> <https://developers.google.com/experts/people/felipe-moura>, Founder of
> BrazilJS <https://braziljs.org/> and Nasc <http://nasc.io/>.
> Website:  http://felipenmoura.com / http://nasc.io/
> Twitter:    @felipenmoura <http://twitter.com/felipenmoura>
> Facebook: http://fb.com/felipenmoura
> LinkedIn: http://goo.gl/qGmq
> ---------------------------------
> *Changing  the  world*  is the least I expect from  myself!
> On Fri, Jun 28, 2019 at 4:03 PM kai zhu <kaizhu256 at gmail.com> wrote:
>> 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 <andyearnshaw at 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, <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.
>>>> "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 <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:
>>>>>> 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).
>>>>>> _______________________________________________
>>>>>> es-discuss mailing list
>>>>>> es-discuss at mozilla.org
>>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>> _______________________________________________
>>>> es-discuss mailing list
>>>> es-discuss at mozilla.org
>>>> https://mail.mozilla.org/listinfo/es-discuss
>>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20190704/1bcc8a5f/attachment.html>

More information about the es-discuss mailing list