effect of editor/ide on javascript programming-style

Charter ggadwa at charter.net
Sat Jun 29 04:39:42 UTC 2019


My anecdotal data point is I use Netbeans to build my javascript 3D engine, all in modules (where each module is a single class where the class definition is the default export.). This works really well for me, the only problem being the regular nature of the language problems.  Hundreds of files, in both the core and demo project and I’ve never found it unwieldy.  IMHO, modules and classes have allowed me a painless path for a project with hundreds of files.  I wouldn’t go back.

In case anybody is interested, the demo shooter is here (requires newest chrome at this point:) http://www.klinksoftware.com/arcade/wsjs/demo/html/index.html <http://www.klinksoftware.com/arcade/wsjs/demo/html/index.html>

All the code is up on GitHub.  It’s a pretty large project.

[>] Brian

> On Jun 28, 2019, at 3: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <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 <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).
> <vim-editor-min.png>
> 
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
> https://mail.mozilla.org/listinfo/es-discuss <https://mail.mozilla.org/listinfo/es-discuss>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
> https://mail.mozilla.org/listinfo/es-discuss <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/819b17c5/attachment-0001.html>


More information about the es-discuss mailing list