effect of editor/ide on javascript programming-style

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

effect of editor/ide on javascript programming-style

kai zhu
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

[2] documentation of various [minimal-dependency] self-contained functions that can be copy/pasted



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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: effect of editor/ide on javascript programming-style

Jordan Harband
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 <[hidden email]> 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

[2] documentation of various [minimal-dependency] self-contained functions that can be copy/pasted



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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: effect of editor/ide on javascript programming-style

kai zhu
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 <[hidden email]> 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 <[hidden email]> 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

[2] documentation of various [minimal-dependency] self-contained functions that can be copy/pasted



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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: effect of editor/ide on javascript programming-style

Andy Earnshaw-2
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, <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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

[2] documentation of various [minimal-dependency] self-contained functions that can be copy/pasted



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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: effect of editor/ide on javascript programming-style

kai zhu
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 <[hidden email]> 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, <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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

[2] documentation of various [minimal-dependency] self-contained functions that can be copy/pasted



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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: effect of editor/ide on javascript programming-style

Brian Barnes-3
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

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

[>] Brian

On Jun 28, 2019, at 3:03 PM, kai zhu <[hidden email]> 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 <[hidden email]> 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, <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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

[2] documentation of various [minimal-dependency] self-contained functions that can be copy/pasted



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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: effect of editor/ide on javascript programming-style

Felipe Nascimento de Moura
In reply to this post by kai zhu
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 ExpertFounder of BrazilJS and Nasc.

Website:  http://felipenmoura.com / http://nasc.io/ 
Twitter:    @felipenmoura
---------------------------------
Changing  the  world  is the least I expect from  myself!


On Fri, Jun 28, 2019 at 4:03 PM kai zhu <[hidden email]> 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 <[hidden email]> 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, <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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

[2] documentation of various [minimal-dependency] self-contained functions that can be copy/pasted



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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: effect of editor/ide on javascript programming-style

kai zhu
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 <[hidden email]> 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 ExpertFounder of BrazilJS and Nasc.

Website:  http://felipenmoura.com / http://nasc.io/ 
Twitter:    @felipenmoura
---------------------------------
Changing  the  world  is the least I expect from  myself!


On Fri, Jun 28, 2019 at 4:03 PM kai zhu <[hidden email]> 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 <[hidden email]> 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, <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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

[2] documentation of various [minimal-dependency] self-contained functions that can be copy/pasted



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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss