In my article "Why I Continue to Use Expression Web," I explain why Expression Web (EW) will continue to be my central tool for Web development projects and why I need something better for writing PHP code. In this follow on article, I explain why I decided to purchase and use Rapid PHP 2016 by Blumentals Software.

It is important to understand my perspective. I am not switching all my development activity away from EW and to a new editor. EW has some excellent features, particularly in project management and including a couple of things I'd like to continue to use. My first priority is having a much better editor for PHP. EW5 promised more support for PHP that was never delivered after Microsoft dropped EW as a product.

The features I wanted in a tool fall into two main categories - project management and editing.

Project Management

• The ability to launch the editor from within EW.
• Have the editor/IDE understand the context or scope of a project.

Editing

• The equivalent of Microsoft's IntelliSense for the languages I most often use - PHP, HTML, CSS, and JavaScript. EW has this but because EW is no longer maintained, its IntelliSense is not up to date with the latest versions of PHP and it is missing things from other languages as well.
• "IntelliSense" for my own code. Visual Studio products do that but EW does not.
• PHP syntax checking.

I decided to examine several tools:

• JetBrains PhpStorm
• Blumentals Rapid PHP
• Microsoft Visual Studio Code (VSC)
• Atom
• NotePad++

I quickly rejected VSC and Atom because their project management capabilities did not jive with EW (or they didn't have project management at all). I use NotePad++ every day for general text editing and thus know it well but rejected it because of the lack of project management.

I considered looking at the two major PHP plug-ins for Visual Studio, VS.PHP and PHP Tools for Visual Studio. Because using the tools would have made Visual Studio the central tool, I decided not to bother. I am also somewhat concerned about the future of plug-ins - will they be maintained as long as the parent tool and will they always be compatible?

That left Rapid PHP and PhpStorm. I downloaded both for their respective evaluation periods (generous in both cases) and experimented with them both. It became immediately apparent that PhpStorm is the superior product with more capability and features than Rapid PHP. It was also apparent that just getting PhpStorm going and properly configured was more complex. While I'm confident that PhpStorm is not beyond my abilities, I like simple. I was doing useful work faster with Rapid PHP while still struggling with PhpStorm. After editing with both for reasonable amounts of time, I decided to do a deeper dive into Rapid PHP and ultimately decided that it was more than adequate for my situation.

The rest of this article will focus on why I was willing to commit to Rapid PHP. It is a review because I will describe Rapid's features and how it applies to my situation, calling out both the good and the bad. It will not be comprehensive, examining every aspect of its capabilities and stating judgements. A key assumption should be that as an editor Rapid PHP meets my needs. Otherwise, I would have been a fool to choose it.

Meeting my Goals

Let's start by revisiting my key features list and seeing how Rapid PHP ("Rapid") addresses them.

Project Management

Expression Web (and before it FrontPage) has the ability to specify which editor should be used for a given file type. In most cases the editor is internal to EW. This feature has been very handy all along for graphics files, which I happen to think is the original reason the feature was created. The developers chose to make the feature generic, meaning that any file type can be associated with an external editor. It was thus simplicity itself to add Rapid PHP to the list of editors for PHP files. (For testing I also added Atom, NotePad++, VSC, PhpStorm and others.)

The limitation of this useful EW feature is that it can only tell an external editor to open one file. It cannot tell the editor to open a folder or a project. This limitation is important. I had hoped to have EW control the project but unless Rapid opens the project, Rapid cannot "see" the entire project and thus understand the scope of the code. In practice this means that I must open a project in both EW and Rapid. This is more inconvenient than I hoped but it is not a complaint about Rapid; it also applies to the other tools I evaluated.

I thought about reversing the process by having Rapid open the project and launch EW. Rapid can do it, but EW does not accept a command line argument and thus cannot be told which project to open.

When it opens a folder (project), Rapid explores the entire folder and "absorbs" the PHP code. It thus understands and uses the full context of the code it sees. My entire environment (SiteCommander) is always included in each project and Rapid therefore has the full context of each project.

One aspect of project management is navigating through the code. My sites typically include 3,500 to 4,000 files including all the supporting code. EW supports a couple of views. Rapid has those views and more. I can either match what I do in EW or take advantage of other views. Rapid has a "combined" view, which shows the folder tree at the top and the contents of a selected folder at the bottom. It's both annoying and helpful, but it's at least there.

Rapid PHP meets my goals for project management.

My original idea of using EW as the central tool won't work as well as I would have liked. There is no choice but to open a project in EW and then open it in Rapid. I must thus use project management in both tools.

There is also one feature of EW that Rapid does not match - multiple instances. At one point in its evolution EW lost the ability to open multiple instances so that multiple projects could be open at the same time, which resulted in an enormous hue and cry from the user base. Microsoft rapidly released a service pack that restored the feature. With Rapid, only one project can be open at a time. After several weeks of use, I decided not to have EW automatically launch Rapid as originally planned. This will let me use the editor in EW for a quick change to project B while I have the full context of project A open in Rapid. What I found was that project navigation in Rapid was sufficiently fast and natural that launching from EW was not much of an expedient.

After a few months of use, I can see that I will eventually configure Rapid with FTP information and in most cases will publish directly from Rapid. One goal here is improving productivity; going back and forth between EW and Rapid hardly meets that goal.

Editing

Rapid has code intelligence. It does not appear to have a branded name like Microsoft's IntelliSense, so for purposes of this article I will refer to it as "RapidSense."

RapidSense does know the full extent of the PHP environment, so it meets that goal. Rapid PHP 2016 does not yet know about PHP 7. That is a bit of a disappointment; JetBrains was rolling support for PHP 7 into PhpStorm before PHP 7 was even released, several years ago. We are over a year downstream of the PHP 7 release and Rapid is very much behind the curve. From a practical point of view, this has little effect on my work because for code intelligence the number of changes from PHP 5.6 to PHP 7.1 is relatively small. However, adoption of PHP 7 in the economy hosting plans used by my clients is happening now. Blumentals has some catching up to do. It's clear that the company must get support into the product soon and, although it would not discuss its schedules with me, I got the impression that this work was under way.

If Rapid opens a folder or project, RapidSense knows about everything in that project. In this respect Rapid is a huge boon for me. Even though my CMS, SiteCommander, is relatively simple, after a decade it has hundreds of globals, functions, classes, methods, and properties. RapidSense puts all that right at my fingertips and frees me from referencing my paper and online versions of help (I built a PHP reflection class that also sees my entire environment, but not as well as Rapid nor as convenient). This one capability alone makes Rapid worth every penny.

Rapid does have a weakness, items that have not been defined. For example, if I have a function called STYLE and I mistakenly type STYEL, I'd like that to be caught. This is something of a mixed bag because sometimes the definition could legitimately be outside the current context and no IDE can know that. Thus the question is whether I can live with it. The answer is yes because I'm living with it now and it is something of a rarity in the sorts of errors I usually make. Still, it would be nice if Rapid could do it, perhaps optionally.

Next is syntax checking. Rapid 's syntax checking is through the expedient of passing the current file through the local copy of PHP, probably by calling EVAL(). PhpStorm does not use PHP but rather parses itself and can thus find just about all the errors at the same time, including undefined items. This is the one feature that gave me pause when deciding between Rapid and PhpStorm because I need to stop using live sites as syntax checkers (i.e., uploading a file with an uncaught error and testing it on a live site). In addition, PHP always stops at the first error, which can sometimes be far downstream of the actual mistake when the error involves closure.

Rapid's help system, perhaps in self-defense, explains that Rapid performs syntax checking when the line count of a file changes. It's not enough, as it is possible to make changes to one or more lines without adding or deleting any lines and thus not triggering syntax checking at all. In my own self-defense, I've learned to manually invoke syntax checking before I upload a given file. I have also suggested a different strategy to Blumentals that I believe will dramatically improve syntax checking without adding extra overhead; perhaps we'll see that or another improvement in a future version.

When Rapid does find a syntax error, sometimes the reporting of it can be fleeting. It does highlight the error line but that highlight goes away quickly if I'm working quickly and not paying attention to the screen. On the positive side, the highlight is very visible and cannot be missed if one is actually looking. I'd like to see that highlight stick until the next time the syntax checker runs.

Why did I accept this limited syntax checking when PhpStorm's is more comprehensive? There are two reasons. First, I had no syntax checking with EW and now I have acceptable syntax checking, which makes it a huge improvement. Second, although PhpStorm does a better job I found that it did not necessarily make my work go faster.

Rapid PHP meets my goals for editing.

The bottom line is that I had two boxes to check and Blumentals' Rapid PHP checks them both.

The Editor

Moving from EW to Rapid is not without its challenges, especially because I've been using EW for so long.

Non-Standard Editor Style

I've been using Microsoft-style editors for a long time. Whether Microsoft adopted an outside style or vice versa, the MS style is very common now. As a very simple example, I can hop between EW's editor and the very popular NotePad++ almost seamlessly.

Rapid PHP (and presumably all Blumentals tools) is not consistent with the MS style. My two big stumbling blocks are selecting one or multiple lines with the mouse and selecting a text range with the mouse (e.g., double-clicking on something). I'm not saying that one is better than the other, just that they are different. The MS style is so ingrained that I constantly make selection errors in Rapid.

Searching

I think the search capabilities in EW are almost perfect. They are embodied in a single dialog and enable a search within all pages, open pages, selected pages (those selected in the folder list), and the current page. EW allows two result sets to be maintained, a feature that I've rarely used but which is very helpful when needed. A key omission is the ability to search within selected text.

Rapid has two searches called Find and Find in Files. Find works on the current page, all open pages, and selected text. Find in Files works on a project or a folder. Find in Files has no keyboard shortcut but Rapid has an excellent keyboard shortcut facility, so one can be assigned.

Having become so used to the single dialog in EW, I've had trouble adapting to Rapid. I use Find but tend to go back to EW for files. I have resolved to try harder.

Search Results

EW has a superior search results display that Rapid cannot match.

In both products, one can double-click on any result to have the editor move the cursor to that spot in the file. However, EW remembers the line the search result references even if edits are made to the file. Rapid records the character position of the found item and as the file is edited Rapid loses track. It moves the cursor to the general vicinity and warns of this by beeping. This is on my list of top problems for Blumentals to address.

With EW, the items in the search results list can be selected - one, all, or any subset. A number of operations can be performed on the selected results but my favorite, by far, is having EW select that set of files in the folder list. That's because a selected group of files can be published with one click. (Long ago I asked Microsoft to allow publishing from the search results list but my idea was rejected.) Rapid can't do this.

Code Navigation

It is not unusual for some of my PHP modules to be 2,000 lines long, with dozens of properties and methods and whatever. Navigating through them is very tough in EW, something that slows me down. An example is the name of a private method that is called many times within the class. In EW, searching for the name of the method returns a list of every reference, not just the definition.

Rapid's Code Explorer is the answer to this particular nightmare. Every constant, variable, function, class, property, and method is listed in an organized fashion. The Code Explorer shows this information for the current file. While such a feature is hardly unique to Rapid, it is a huge productivity advance for me.

Syntax Highlighting

I'm very accustomed to the syntax highlighting scheme used by EW, including a few modifications I've made to my taste. It's not much of a surprise that Rapid's is different. I'm not adjusting well.

And I'm lazy. The scheme can be edited in Rapid and I just haven't done it. I do think there are a couple of things that I won't be able to make the same but until I can report accurately about that, I'll assume the best.

[05 Oct 2017 Update] The syntax highlighting schemes of the two products are just different enough that I cannot make them match. The closest I came gave a result that I did not like at all, so I reverted the Rapid's default. One ray of hope is a Rapid feature that allows the creation of external highlighting scripts, which can highlight in ways that the core product cannot. I'd call that an advanced feature that I'm not likely to explore.

[21 Feb 2018 Update] I spent a couple of hours trying harder to match the highlighting of EW and Rapid. I came closer than before and I'm using my new scheme in Rapid. It's still not as good as I'd like.

I'm just whining here. There nothing wrong with the highlighting scheme in Rapid.

Why I Bought Rapid PHP

The main reason I decided to buy Rapid was price. I'm not against paying for tools and I may spend more in the future, but it's hard to beat $40. Given Blumentals' release schedule, that's $40 every 18 to 24 months. Had I found major weaknesses with Rapid I would have gone ahead with PhpStorm regardless of price, but that was not the case.

Rapid PHP has proven itself an effective tool. I am more productive using it and my error rate, especially where typos are concerned, has improved. I'm hopeful to see some future improvements in automatic syntax checking for PHP, which could bring my error rate to almost nothing.

Rapid PHP is simple. I was up and running very quickly and I was generally able to figure out how everything worked. For those cases when I was stumped, Blumentals' forums proved their worth.

Is Rapid PHP Right for You?

Rapid PHP is working out well for me. I gain more comfort with each passing day and I look forward to using more and more of its features. Whatever inconvenience I experience with my hybrid EW/Rapid solution is more than offset by my improved PHP productivity.

If you are using EW to develop PHP, there is no question that Rapid PHP will be an improvement. As I've shown, you don't have to abandon EW.

If you are using EW's Dynamic Web Templates (DWT) and writing PHP, you can still improve your situation by using Rapid but you can't abandon EW. You'll have to use the hybrid solution until you find a way to abandon DWTs.

And if you're not using EW and are just looking for better editor for PHP, Rapid PHP is worth a serious look.