For me and my work using a text editor just isn't a viable option. One - by definition - does more than the other. Two fundamentally different pieces of software. But one will always be a gussies up text editor and the other will be an IDE. If you want some autocomplete and a little automation they're great. I'll take your word for it that Git tools work. Of that you suggested the CLI for two and gave an opinion on one. But I've never had any problems with responsiveness with PhpStorm except when you just open or make certain changes that warrant a re-index of the files. Let's not forget how much slower an IDE is going to be because of everything it tries to do for you. Have you never heard of Fugitive, or SublimeGit? Yes, but it can run automatically before commits and you can open the file directly if one is found. TODO finder? are you serious? As if a simple grep couldn't identify a TODO? Pulls them, adds them libraries, adds them as PSR2 namespaces.
Build-in terminal appears in a pane and the test is ran. When I'm done with a feature I hop over to the terminal and go all the final merges/pushes. You hand-waved them away with the time honored tradition of suggesting somebody use the terminal.
But you offered to find analogs of the features I provided and you didn't. Vagrant, composer, terminal, version control (the list goes on) can all be easily managed via a CLI interface which would likely be faster than interacting with a GUI. You don't know my workflow, what I do, or the environment I do it in so I give you a pass on the minutia. Get method definition from other classes with keyboard shortcut.
#Phpstorm price code#
#Phpstorm price windows#
If there's a question with mine or their code, no developer ever will say "I can't read your code because it's being displayed by VIM", will they? It shouldn't even matter if I use Windows notepad.exe. There's a spec, my collegues work along that spec and I can use their interfaces. I don't see how IDE and/or editor preference could have any impact on that. When you run into a problem, now you are the problem because no one else can help you and you're working on x,y,z feature and you're stuck Workflows may be similar, but the moment you fork the road, when you run into a problem, now you are the problem because no one else can help you and you're working on x,y,z feature and you're stuck. If your toolchain/kit becomes extremely esoteric, every time you do something, it's magic to those around you, and when you fumble on something no one is there to offer assistance because you've taken the contrarian workflow that sets you apart from everyone else. I can only hope if you work with others, if someone ever has to observe your workflow, they can atleast walk away saying, hey, I learned something I can use within my toolchain/kit/etc. They have standardized on a very specific workflow, everyone who uses it learns it from those around them. Not to say that you or I work for facebook sized companies, but as developer count increases, standardization becomes more important. In an already established environment, this could be regressive. Tools & instructions are often times handed down. Example: every time you make a change on your local system it gets uploaded to your work-environment in a similar fashion that you would have had on say a vagrant installation, instead you push to remote system.
Toolkit integration become very bound to workflows in code-bases. I've seen where processes become very dependent based on what ever editor/IDE being used is. I'm not going to claim I'm an expert by any means.