effect of editor/ide on javascript programming-style

Felipe Nascimento de Moura felipenmoura at gmail.com
Sat Jun 29 14:09:29 UTC 2019


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).
>>>>> [image: vim-editor-min.png]
>>>>>
>>>>> _______________________________________________
>>>>> 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/20190629/0a870a6c/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vim-editor-min.png
Type: image/png
Size: 37924 bytes
Desc: not available
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20190629/0a870a6c/attachment-0001.png>


More information about the es-discuss mailing list