336 karma · joined November 12, 2013
https://hhsnopek.com
Remote: Yes
Willing to relate: Yes (Preferably: Seattle, WA or CO)
Technologies: Javascript, React, Node.js, Static Websites, Progress Web Apps (PWA), Golang, AWS, RESTful APIs
Resume/CV: https://hhsnopek.com/resume.pdf
Email: hhsnopek at gmail dot com (also see resume)
Website: https://hhsnopek.com
Github: https://github.com/hhsnopek
LinkedIn: https://www.linkedin.com/in/hhsnopek
Experience frontend and lead developer, who's well-vised in the full-stack.
Native English Speaker, Available full-time, interview ready, willing to relocate (prefer remote), No contracting.
Edit: ~3-5 cups a day
I was hoping for Apple to switch it up this year with start of their new backend for Safari, rather I don't expect it to turn out as I have wished.
I'm fine with the OP switching editors, I could careless which editor someone is using or switching to, but don't place the blame on plugin performance, plugin bloat, or building an IDE; Vim isn't an all-in-one solution and that's okay, we can push it to be an all-in-one solution.
My constructive criticism is that these problems are in every editor, don't pin it on vim plugins or the amount of plugins you're loading into vim. "releativenumber" is a valid reason to switch editors, but the rest of the reasons are applicable to all editors.
Edit: "switching terminals" -> "switching editors"
If you were already using Alacritty and Neovim, you should expand on why these did not solve your problems as many if not all speed/optimizations can be matched or better than Sublime Text
"Why I'm no longer using vim and now using X" typically result from not digging into Vim enough. All the issues the OP is having have been resolved from either updates to vim, switching terminals, or just understanding vim basics.
NOTE: Plugs can be slow and the OP is correct that some are hacky, but typically there's the Vanilla Vim solution to a problem that takes a little bit of reading and/or finding to solve.
If plugin/loading speed is really an issue then switch to using Alacritty and Neovim, use vim-plug for async & lazy loading plugins. You get truecolor support and you're using your GPU to render everything. If plugin speed is still a problem, learn why they're loading slowly, then dig into why rather than just saying "they're hacky or clunky". Silver search is great, but if you understand how to execute terminal commands from vim (:!) then you can grep everything and remove the need for silver search. I use FZF (https://github.com/junegunn/fzf) which is another fuzzy searcher that's optimized for speed, built with Go.
For those that don't want to put in the time to optimize and learn vim, then by all means switch editors. But don't blame the editor ("I will not use shitty software just because it’s open source.") unless it's truly the root of the problems, explore and find better ways. A key thing to remember as a Vim user is there's always a faster way and your .vimrc will always be different from another's.
Edit: For those interested in my setup (https://github.com/hhsnopek/dotfiles/blob/master/.nvimrc)
Honestly the author just lacked the time and knowledge to go ahead and learn basic bash tools and utilize them.
Then it seems that Go isn't the language for you. With that Go nor any language, unless intended, is suppose to be a one-all solution for every problem. We can accomplish a majority, if not all, problems in a language, but this shouldn't assumed that a language is intended to do so.
I've switched back to iterm2 due to these two issues which can easily be fixed by the maintainer(s)
> Then there's other annoyances, like the alignment of the text, pictures, and other content suddenly shifting about, because the font has changed, or the JS from one CDN finally finished processing and decided that, no, actually, pictures should go over there.
This is because the scripts and css are so large that it takes time for the browser to render all the rules set by that site. This can easily be optimized with the right tools or throwing out dead code, even only fetching code specific to that web page. Most developers just `script` tags into their head as well and this _kills_ loading of pages more than anything (unless your css file is thousands of lines).
CDNs are meant for distributing across the globe, you're hosting your own assets without a CDN in the middle and the site is still slow, you're optimizing in the wrong place.
You're correct with the fact that they are tracking us, but there's a trade off that comes with this that holds tremendous value. If that value of speed isn't a factor or low on your list of priorities then by all means, sever everything.
Similarly my keybindings can be mapped just as I did in my dotfiles (first link). Probably my favorite part is being able to search my terminal instance in vim style with `/` and navigate as I would in any other file