devtools   5920

« earlier    

Using DevTools to Improve the UX Design to Development Process
Code is just another medium with which we can experiment and build beautiful solutions. So, we're going to look at a couple of ways designers can experiment with code, even with a light understanding of it. What we're covering here may be obvious to developers, but there are plenty of designers out there who have never experimented with code and will be seeing these for the first time. So, it's for them (and maybe a refresher for you) that we look at the following browser tools.
fridayfrontend  cssbasics  design  devtools  html  css 
yesterday by spaceninja
The End of the Editor Wars » Linux Magazine
Moreover, even if you assume a broad margin of error, the pollings aren't even close. With all the various text editors available today, Vi and Vim continue to be the choice of over a third of users, while Emacs well back in the pack, no longer a competitor for the most popular text editor.
I believe Vim is actually more popular, but it's hard to find any real data on it. The best source I've seen is the annual StackOverflow developer survey where 15.2% of developers used Vim compared to a mere 3.2% for Emacs.

Oddly enough, the report noted that "Data scientists and machine learning developers are about 3 times more likely to use Emacs than any other type of developer," which is not necessarily what I would have expected.

[ed. NB: Vim still dominates overall.]

Time To End The vi/Emacs Debate:

Vim, Emacs and their forever war. Does it even matter any more?:
Like an episode of “Silicon Valley”, a discussion of Emacs vs. Vim used to have a polarizing effect that would guarantee a stimulating conversation, regardless of an engineer’s actual alignment. But nowadays, diehard Emacs and Vim users are getting much harder to find. Maybe I’m in the wrong orbit, but looking around today, I see that engineers are equally or even more likely to choose any one of a number of great (for any given definition of ‘great’) modern editors or IDEs such as Sublime Text, Visual Studio Code, Atom, IntelliJ (… or one of its siblings), Brackets, Visual Studio or Xcode, to name a few. It’s not surprising really — many top engineers weren’t even born when these editors were at version 1.0, and GUIs (for better or worse) hadn’t been invented.


… both forums have high traffic and up-to-the-minute comment and discussion threads. Some of the available statistics paint a reasonably healthy picture — Stackoverflow’s 2016 developer survey ranks Vim 4th out of 24 with 26.1% of respondents in the development environments category claiming to use it. Emacs came 15th with 5.2%. In combination, over 30% is, actually, quite impressive considering they’ve been around for several decades.

What’s odd, however, is that if you ask someone — say a random developer — to express a preference, the likelihood is that they will favor for one or the other even if they have used neither in anger. Maybe the meme has spread so widely that all responses are now predominantly ritualistic, and represent something more fundamental than peoples’ mere preference for an editor? There’s a rather obvious political hypothesis waiting to be made — that Emacs is the leftist, socialist, centralized state, while Vim represents the right and the free market, specialization and capitalism red in tooth and claw.

How is Emacs/Vim used in companies like Google, Facebook, or Quora? Are there any libraries or tools they share in public?:
In Google there's a fair amount of vim and emacs. I would say at least every other engineer uses one or another.

Among Software Engineers, emacs seems to be more popular, about 2:1. Among Site Reliability Engineers, vim is more popular, about 9:1.
People use both at Facebook, with (in my opinion) slightly better tooling for Emacs than Vim. We share a master.emacs and master.vimrc file, which contains the bare essentials (like syntactic highlighting for the Hack language). We also share a Ctags file that's updated nightly with a cron script.

Beyond the essentials, there's a group for Emacs users at Facebook that provides tips, tricks, and major-modes created by people at Facebook. That's where Adam Hupp first developed his excellent mural-mode (ahupp/mural), which does for Ctags what iDo did for file finding and buffer switching.
For emacs, it was very informal at Google. There wasn't a huge community of Emacs users at Google, so there wasn't much more than a wiki and a couple language styles matching Google's style guides.,%2Fm%2F01yp0m
And it is still that. It’s just that emacs is no longer unique, and neither is Lisp.

Dynamically typed scripting languages with garbage collection are a dime a dozen now. Anybody in their right mind developing an extensible text editor today would just use python, ruby, lua, or JavaScript as the extension language and get all the power of Lisp combined with vibrant user communities and millions of lines of ready-made libraries that Stallman and Steele could only dream of in the 70s.

In fact, in many ways emacs and elisp have fallen behind: 40 years after Lambda, the Ultimate Imperative, elisp is still dynamically scoped, and it still doesn’t support multithreading — when I try to use dired to list the files on a slow NFS mount, the entire editor hangs just as thoroughly as it might have in the 1980s. And when I say “doesn’t support multithreading,” I don’t mean there is some other clever trick for continuing to do work while waiting on a system call, like asynchronous callbacks or something. There’s start-process which forks a whole new process, and that’s about it. It’s a concurrency model straight out of 1980s UNIX land.

But being essentially just a decent text editor has robbed emacs of much of its competitive advantage. In a world where every developer tool is scriptable with languages and libraries an order of magnitude more powerful than cranky old elisp, the reason to use emacs is not that it lets a programmer hit a button and evaluate the current expression interactively (which must have been absolutely amazing at one point in the past).

more general comparison, not just popularity:
Differences between Emacs and Vim:

Technical Interview Performance by Editor/OS/Language:
[ed.: I'm guessing this is confounded to all hell.]

The #1 most common editor we see used in interviews is Sublime Text, with Vim close behind.

Emacs represents a fairly small market share today at just about a quarter the userbase of Vim in our interviews. This nicely matches the 4:1 ratio of Google Search Trends for the two editors.


Vim takes the prize here, but PyCharm and Emacs are close behind. We’ve found that users of these editors tend to pass our interview at an above-average rate.

On the other end of the spectrum is Eclipse: it appears that someone using either Vim or Emacs is more than twice as likely to pass our technical interview as an Eclipse user.


In this case, we find that the average Ruby, Swift, and C# users tend to be stronger, with Python and Javascript in the middle of the pack.


Here’s what happens after we select engineers to work with and send them to onsites:

[Python does best.]

There are no wild outliers here, but let’s look at the C++ segment. While C++ programmers have the most challenging time passing Triplebyte’s technical interview on average, the ones we choose to work with tend to have a relatively easier time getting offers at each onsite.

The Rise of Microsoft Visual Studio Code:
This chart shows the rates at which each editor's users pass our interview compared to the mean pass rate for all candidates. First, notice the preeminence of Emacs and Vim! Engineers who use these editors pass our interview at significantly higher rates than other engineers. And the effect size is not small. Emacs users pass our interview at a rate 50% higher than other engineers. What could explain this phenomenon? One possible explanation is that Vim and Emacs are old school. You might expect their users to have more experience and, thus, to do better. However, notice that VS Code is the third best editor—and it is brand new. This undercuts that narrative a bit (and makes VS Code look even more dominant).

Do Emacs and Vim users have some other characteristic that makes them more likely to succeed during interviews? Perhaps they tend to be more willing to invest time and effort customizing a complex editor in the short-term in order to get returns from a more powerful tool in the long-term?


Java and C# do have relatively low pass rates, although notice that Eclipse has a lower pass rate than Java (-21.4% vs. -16.7), so we cannot fully explain its poor performance as Java dragging it down.

Also, what's going on with Go? Go programmers are great! To dig deeper into these questions, I looked at editor usage by language:


Another finding from this chart is the difference between VS Code and Sublime. VS Code is primarily used for JavaScript development (61%) but less frequently for Python development (22%). With Sublime, the numbers are basically reversed (51% Python and 30% JavaScript). It's interesting that VS Code users pass interviews at a higher rate than Sublime engineers, even though they predominately use a language with a lower success rate (JavaSript).

To wrap things up, I sliced the data by experience level and location. Here you can see language usage by experience level:


Then there's editor usage by experience level:


Take all of this with a grain of salt. I want to end by saying that we don't think any of this is causative. That is, I don't recommend that you start using Emacs and Go (or stop using… [more]
news  linux  oss  tech  editors  devtools  tools  comparison  ranking  flux-stasis  trends  ubiquity  unix  increase-decrease  multi  q-n-a  qra  data  poll  stackex  sv  facebook  google  integration-extension  org:med  politics  stereotypes  coalitions  decentralized  left-wing  right-wing  chart  scale  time-series  distribution  top-n  list  discussion  ide  parsimony  intricacy  cost-benefit  tradeoffs  confounding  analysis  crosstab  pls  python  c(pp)  jvm  microsoft  golang  hmm  correlation  debate  critique 
2 days ago by nhaliday
Meet the Flexbox Inspector | Geddski
Flexbox just got a whole lot easier to work with.
tutorials  devtools  Firefox  share 
14 days ago by incredimike
16 DevTools tips and tricks every CSS developer needs to know
In this article, I’ve compiled a number of CSS-related features and tricks available via developer tools that I think will take your CSS development to a new level. Some of these tips aren’t specifically only for CSS, but I’ll present them in a CSS context. Some are simple tips for workflow and debugging, while others are new features that have rolled out in recent years. Most are based on Chrome’s DevTools, but I’ve also included a few Firefox tips.
fridayfrontend  cssbasics  devtools 
15 days ago by spaceninja
Dev Tips - Developer Tips by Umar Hansa
A developer tip, in the form of a gif, in your inbox each week - Made by Umar Hansa (@umaar). - Subscribe to Dev Tips to get these in your inbox
devtools  chrome 
16 days ago by regrant79

« earlier    

related tags

addons  advice  aggregator  analysis  analytics  animation  aphorism  app  apple  assembly  aws  best-practices  bestpractices  big-picture  blog  blowhards  books  breakpoints  browser  build-packaging  c(pp)  caching  calculator  caltech  carmack  causation  chart  cheatsheet  checker  checking  checklists  chrome  coalitions  code-dive  codereviews  collection  color  community  comparison  compilers  composition-decomposition  confounding  console.log  console  contrast  cool  correlation  cost-benefit  critique  crosstab  cs  css  cssbasics  culture  dan-luu  data-science  data  database  dataviz  dbs  debate  debug  debugging  decentralized  design  desktop  dev  developer  development  discussion  distribution  divide-and-conquer  documentation  editors  embedded  engineering  error  evidence-based  examples  exocortex  expert-experience  explanation  extension  facebook  files  firefox  flex  flexbox  flexibility  flux-stasis  formal-methods  forum  fridayfrontend  frontend  gallic  git  go  golang  google  gotchas  graph-theory  graphs  grid  guide  hacker  hardware  haskell  hci  heuristic  hg  history  hmm  hn  homepage  howto  html  ide  images  impact  impetus  increase-decrease  input-output  inspector  integration-extension  interface  intricacy  intuit  ios  javascript  js  jvm  k14s  k8s  left-wing  letters  libraries  links  linting  linux  list  llvm  local-global  local  lol  machine-learning  memory-management  metrics  microsoft  multi  neurons  news  nibble  nitty-gritty  nmap  notetaking  objektbuch  ocaml-sml  oly-programming  oly  open-closed  org:med  oss  osx  package  papers  parsimony  paste  path-dependence  pdf  performance  pls  plt  politics  poll  post  presentation  pro-rata  productivity  programming  project  pullrequest  python  q-n-a  qra  quality  r  random  ranking  rant  react-dev-tools  react-hooks  react  recommendations  reference  reflection  repo  resources  retrofit  rhetoric  right-wing  rigidity  rigor  rmarkdown  rmd  robots  ruby  rust  saas  scala  scale  scholar  sci-comp  screenshot  search  security  selenium  shapes  share  software  span-cover  stackex  state  stereotypes  stories  stream  structure  study  summary  sv  sync  systems  tech  techtariat  terminal  testing  thinking  time-series  time  timestamp  tips  tipsandtricks  tools  top-n  traces  tradeoffs  trends  tricks  tutorial  tutorials  types  ubiquity  unit  unix  utility  utils  ux  validation  vcs  video  vignettes  visualization  vscode  web  webdesign  webdev  webdevel  webdevelopment  white-paper  wiki  windows  workflow  working-stiff  worrydream  wpd  wsl  xray  yak-shaving  zxp  🖥 

Copy this bookmark: