effect of editor/ide on javascript programming-style
# Jordan Harband (5 years 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.
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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20190628/fa9f8e33/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/20190628/fa9f8e33/attachment-0001.png>
# kai zhu (5 years 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.
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 >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20190628/23cc2024/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/20190628/23cc2024/attachment-0001.png>
# Andy Earnshaw (5 years 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.
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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20190628/ed62f32a/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/20190628/ed62f32a/attachment-0001.png>
# kai zhu (5 years 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.
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 >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20190628/2202b989/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/20190628/2202b989/attachment-0001.png>
# Charter (5 years 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
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>
# Felipe Nascimento de Moura (5 years 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!
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>
# kai zhu (5 years 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:
- less loss of critical-knowledge about file/module-dependencies and transpiling/tooling-config-settings when team-members leave the project
- less siloing/loss-of-big-picture, where you end up micromanaging "general-purpose" code rather than the UX-workflow code
- 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.
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>
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:
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:
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]