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
