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 < felipenmo...@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 <kaizhu...@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 <andyearns...@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, <kaizhu...@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 <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). >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>> >>> _______________________________________________ >> 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
