effect of editor/ide on javascript programming-style

# kai zhu (3 months ago)

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 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 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]

# Jordan Harband (3 months ago)

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 underinvest in frontend dev, but obviously everyone has different opinions on that - and it's not relevant to this discussion list.

# kai zhu (3 months ago)

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.

# Andy Earnshaw (3 months ago)

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.

# kai zhu (3 months ago)

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.

# Charter (3 months ago)

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:) www.klinksoftware.com/arcade/wsjs/demo/html/index.html, www.klinksoftware.com/arcade/wsjs/demo/html/index.html

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

[>] Brian

# Felipe Nascimento de Moura (3 months ago)

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 developers.google.com/experts/people/felipe-moura, Founder of

BrazilJS braziljs.org and Nasc nasc.io.

Website: felipenmoura.com / nasc.io Twitter: @felipenmoura twitter.com/felipenmoura

Facebook: fb.com/felipenmoura LinkedIn: goo.gl/qGmq

Changing the world is the least I expect from myself!

# kai zhu (2 months ago)

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.