* Its uncanny ability to find references and declarations in both Python and JavaScript, even when the references are dynamic. What is this .log() or .render() actually calling? Instantly I'm looking inside the relevant function, even if there are hundreds of functions with the same name. This works across imports and libraries. Doesn't always work, but even when it doesn't, it usually makes good guesses and lets me select from a list. If you're working on a large, unfamiliar codebase, this is a godsend. You will sometimes wonder why your coworkers are struggling to understand code references and then you realize they don't have this power-tool available to them.
* Local file history separate from git history, with fantastic navigation/diffing support. It's an undo/redo button on steroids that keeps months of history.
* When searching for something, you get a full, scrollable preview of the surrounding context of each matching result. Results are organized within the file hiercharchy and are collapsible.
* Remote debugging. Drop an egg in your remote source and go.
* Annotated code, line by line, with the relevant commit and comment next to it.
* Auto-linting to catch common mistakes when coding. It'll immediately underline suspicious-looking code and tell you why. Lots of customizable style-linters to keep your code pristine looking.
I've been a WebStorm fanboy since I purchased a license during a sale two years ago. The biggest selling point for WebStorm for me is its smart searching abilities. "Find In Files" doesn't just do text search, it's also smart enough to allow you to include or exclude matches in strings and comments. It also has a great parser that understands the structure of your code well enough to do legitimate "Find References" searches with really good results in spite of Javascript's dynamicness.
Obviously Python is a very dynamic language as well, so PyCharm has most of the same strong points. I'd been using the Community edition for a while, but finally picked up a Commercial license a couple weeks ago. In this case, the feature that finally convinced me to pay for it was no-kidding Remote Debugging. Drop a .egg next to your deployed app and stick an extra import and connection call into your code, and then PyCharm's debugger (which is another great feature in and of itself) just flat-out works over SSH.
Ultimately, both these tools have saved me enough time and effort to pay for themselves repeatedly.
While WebStorm and other JetBrain IDEs are great, the RAD/WYSIWYG part is missing. We had already Frontage/Dreamweaver for HTML3-4. If JetBrains would add a HTML5 WYSIWYG editor based on webkit/blink to their IDEs, it would be awesome.
I don't think so. They have an excellent IDE for editing html on a source basis and an HTML WYSIWYG wouldn't have a developer as a main target, most developers would prefer editing the html directly (and would need to, unless they used a templating system based on the ideas of Enlive).
These days the target market for WYSIWYG HTML editors would be probably be using an online CMS like WP - which actually has a WYSIWYG HTML editor. Failing that, Microsoft Word actually had nice HTML output last time I checked.
> HTML WYSIWYG wouldn't have a developer as a main target, most developers would prefer editing the html directly
WYSIWYG always had a split-screen view which allows one to work in design and code mode at the same time (and see the changes in the other mode). It's very efficient.
> Microsoft Word actually had nice HTML output
MS Word 2000-2013 web page export is based on the old Frontpage engine, and generates invalid HTML4 and converts vector graphics and word art to VML, the proprietary predecessor of SVG, that IE10+ don't even support anymore (except with legacy quirks mode mode).
> online CMS like WP
The contentEditiable HTML4 API that CMS use is sadly completely broken in every browser in a different way - the experience and the code output quality is far worse than Frontpage ever was - and Dreamweaver is better in every aspect.
There is a reason why we have BBCode and Markdown, because contentEditiable isn't that great at the moment. And as several browser vendors have a competitive advantage with their web based Office services (Office365 Web Word, iCloud.com Pages, Google Docs), they will never fix the various bugs of contentEditiable in IE/Safari/Chrome.
The current year is 2015, MS word has come a long way since 2001. In fact they bragged with clean HTML output, suitable for inserting into your blog, in MS Word 2007. If you haven't worked with Word for almost 15 years do yourself a service and don't assume it looks much the same anymore - most the complaints I hear about it are no longer so much an issue in the newer versions.
Also I have no idea where you got the idea that WYSIWYG always had a split-screen view unless there is some product that is named WYSIYG, for me it has always meant What You See Is What You Get and the entire idea was that you have to mess with how it worked under the hood. As implemented in e.g word (or open office) you don't even have the option of doing that. Are you arguing that Word is not WYSIWYG?
Finally take a look at the the output from the WP HTML editor, I have no idea why you bring up the contentEditable API, but either you are misinformed or wordpress use something else because the output is pretty clean and it can convert between that and free HTML entry.
You are wrong, please test it again. In Word 2010 it still uses the Frontpage engine to output not so good HTML4 code with VML graphics. Btw. Office applications haven't changed that much since Office 97 (beside regular interface changes).
And just because some have never have seen a good HTML WYSIWYG editor doesn't mean it's a bad rapid development method and should not be integrated in a modern IDE.
- contains VML code
- will not render correctly in any modern browser
- If you want to be able to render it in IE11, you have to press F12 (Developer tools)
and change from "Edge" to compatibility to version 7 (or even 5) of the IE engine.
Then it will be drawn "correctly".
To clarify the generated code is invalid HTML 4.01 (20 errors according to W3C HTML4 validator https://validator.w3.org/check ) and the first view lines look like this:
Microsoft split Frontpage in two products SharePoint Designer and Expression Web (the later with a new web render engine), though both products are either a shadow of the former self (no WYSIWYG view anymore) or abandoned (free download without support): https://en.wikipedia.org/wiki/Microsoft_Expression_Web
I think that would not happen, with all the difference and mess in implementation under multiple browsers (even with webkit based Safari and Chrome), and file watcher+auto reload is less of a headache.
WYSIWYG always had a split-screen view which allows one to work in design and code mode at the same time (and see the changes in the other mode).
It's very efficient and less headache. WebStorm could add webkit and sync the code view like Dreamweaver. JetBrain's IDE is Java based and integrating a C++ based WYSIWYG view might be more complicated. And all the Java based browsers have been discontinued like https://en.wikipedia.org/wiki/HotJava .
Not PyCharm user, but IntelliJ IDEA, PhpStorm and WebStorm - they are from one family.
Most important things are:
1) Static errors analyzing. Saves a lot of time. Really, hundreds hours of time.
2) Code completion (VS users call it "IntelliSense").
3) Refactoring tools. You can change name of method in one place and IDE will change all usages of this method everywhere in code. It's extremely important.
I'll second all those points, especially the first one, but I'll add a word of caution. All of the points you mentioned require the IDE to parse all the code, not just the code you are writing at this moment. If it doesn't know the type of $foo, it can't tell what $foo->getModel() calls and therefore it can't rename that getModel(), for example. This means you have to be careful in projects using older frameworks or CMS. From recent experience, a great example of such an atrocious codebase is Magento:
- their method calls are excessively chained, which means a failure to analyse step 2 of the chain blocks analysis of all further chained calls
- their phpDoc either doesn't exist or is actively misleading at times
- they rely on magic methods all throughout the codebase without properly annotating them
I mostly develop in Sublime/Atom + iTerm2, but after working in RubyMine for several months, it feels like I lost some sensation in a limb. (and I only explored the bare essentials) Biggest wins for me: Cmd-click pretty much anything and jump to the file, even if it's a gem somewhere outside of my app. Code hinting. The way a Rails console behaves.
For me the features I appreciate the most are the debugger, framework support, and decent multi-language syntax support (for when there's js embedded in the html). All that and it runs a lot faster than PyDev.
I was so happy when I found out that you can select a string and then inject a new language right there which gets you code completion for that language. I was even more happy when it allowed me to edit that string in a separate window as if existed in a separate file.
Ruby web dev here...I pretty much use liberal puts statements (actually the awesome_print) gem. It's never really been a problem for me with ruby. 2001-2007 I was primarily a Java developer and the debugger was essential. But since switching to ruby in 2007 I've just never felt the need. I think it's probably the cycle time...we were using BEA weblogic as our Java server and cycle times weren't quick so you didn't want to waste time and needed to be able to step through the code. With ruby/rails it's almost instant to see your logging so I've never even looked into how to use a debugger in ruby.
Another ruby dev, back in my java days I used debuggers from jbuilder and eclipse. I now use pry and much prefer it as an experience. I found having everything at your fingertips rather than scattered around a gui far more efficient.
