It’s been about a year and a half since I started working at North Carolina Central University. They are a fairly medium sized HBCU located in the middle of Durham, North Carolina and have been around since 1909. This is my first position in higher education and a lot of things were much different than working at a regular Fortune 500 company. One thing, I did not see coming however, is using a language for server-side development that I had not touched before. TL;DR Lucee is not really such a bad solution for developing your web applications today, especially if you are skilled in Java or some other C-based language and do not want to deal with compilation.
At NCCU, Lucee is the stack of choice for server-side application development. I’ll try to avoid any opinionated rants about the positives and negatives of that choice in this article, but instead attempt to layout an educated use case for anyone looking to deploy a website for a large organization. To keep things fair and balanced, I’ll lay down one negative and one positive.
As a web developer watching the ecosystem today, I cannot stress this point enough. This is the single best thing about using Lucee. I don’t need Apache, nginx, PHP modules, junky Debian scripts, npm, babel, gradle or any of the myriad tools out there to get something running. Working on Lucee sites has given me the advantage and freedom to just download a package, answer some questions and run the resultant script. Here, let me show you how to get Lucee running on your system.
$ wget http://cdn.lucee.org/lucee-5.2.3.035-pl0-linux-x64-installer.run $ chmod +x lucee-5.2.3.035-pl0-linux-x64-installer.run $ sudo ./lucee-5.2.3.035-pl0-linux-x64-installer.run $ ...
Wow. And that’s the hard way. You can also just use Lucee Express and hit ./startup.sh to get a server running.
So I didn’t need to download Java, because it comes bundled with it. The package is maybe 200 MB, which I complained about quite a bit when first starting off. But when I think of the task that is installaing something like Laravel with probably close to half a gig of PHP packages, Javascript and Apache modules that I will probably never use again, I’m consoled. On a fresh system (provided that your Linux or OSX box already has everything else you need), something like the following would get Laravel running.
$ sudo apt-get install apache2 php composer php-{bla,bla,mcbla}
…and a whole bunch of other stuff I can’t remember right now. And we haven’t even setup any of this yet. These are just packages on our system…
Most any authentication, hashing and salt methods are included in the Lucee download. The most common database drivers ship with it (curiously enough, SQLite is missing.). Session management ships as well and supports multiple back-ends (file, database and memory). A mail function and an LDAP function both exist. And, if you’re into that sort of thing, you get a pretty well polished GUI1.
However, this brings me to my negative point.
Honestly, I probably shouldn’t have given this one a negative, but one of the reasons for the growth of communities around tools like npm and pip is because of the ubiquity of the package management aspects. Lucee has a meager community right now (when compared to the communities using node and brethren) and as such it is a bit difficult to find modern extensions for those times you really need them. OAuth is one big thing I can think of that there is no gold standard for. While an OAuth implementation is not that hard to bang out (I’ve done one in Lua before and that was with a huge shortage of libraries), it would be incredibly helpful to new users if basics like this already existed.
That said, there is one package manager of note rolling around. See CommandBox. Homebrew has some packages available. I believe I was able to get it working on Cygwin. However, I don’t think the community is fully behind it yet and it may still be picking up speed. There used to be RIAForge, but that has apparently fallen out of favor.
CFML is not the nicest language, but nothing special is needed to do some templating.
As web developers, it would be a bit ridiculous to say we don’t need templating. It would be even more ridiculous to use a framework that left templating as an afterthought. Yes, the world has changed quite a bit since most languages came about, but pretty much all of them have kept up with this.
I’m not the biggest fan of the tag-based language that is CFML. However, I do like that it facilitates writing templates without a lot of fuss. Let’s use Mustache as an example, the logic-less wunderkind of the template universe. It’s one of my favorite types of templating languages because the simplicity constrains you to designing templates that avoid tons of complex logic. Let’s take just this example:
I'm your chiropractor
{{ #condition }}
<p>It looks like you've got a case of achy joints</p>
{{ /condition }}
Mustache will only let you choose to display the text It looks like you’ve got a case of achy joints, depending on the boolean value of ‘condition’. However, what if I were looping through a database query and ‘condition’ was a number or, even better yet, a string defining a particular health condition? To solve that in CF would be pretty trivial (if a little verbose).
<cfif condition eq 1>
<p>It looks like you've got a case of achy joints</p>
<cfelseif condition eq 2>
<p>Oh no! It looks like you've got a case of bronchitis</p>
<cfelseif condition eq 3>
<p>It looks like you've got a case of a broken heart</p>
<cfelse>
<p>Hey! Get out of here! There's nothing wrong with you</p>
</cfif>
Now of course, this can get out of hand really fast and it takes a fair bit of discipline on the developer’s part to keep the businesss logic and views seperate. Rails, Laravel and other modern frameworks excel at this. Lucee ships with no capabilities to make this possible, but it is forgivable because I don’t need any other libraries to make it happen.. But this brings me to my negative point…
I’ll use an example to illustrate:
<cfquery name="etc" datasource="yourmom">
SELECT * FROM no_fs_given
WHERE user = 'superman' AND status = 12
</cfquery>
<cfsavecontent variable="GreetingText">
Hello, and welcome to this spiffy webpage.
It's purty, ain't it?
</cfsavecontent>
<cfset bla=0>
<html>
<body>
<p>
<cfoutput>#GreetingText#<cfoutput>
</p>
<table>
<cfloop query="etc">
<tr>
<cfif bla gt 3>
<td>#column1#</td>
<cfelse>
<td>Nothing at all</td>
</cfif>
<td>#column2#</td>
<td>#column3#</td>
</tr>
<cfset bla=bla+1>
</cfloop>
</table>
</body>
</html>
If that doesn’t make you want to throw up, then you, my friend, have bad taste. And unfortunately, there is tons of CFML code running around that looks exactly like this (minus the spicy data source name).
As stated earlier, a lot of this is up to the developer. But the fact that CFML somewhat encourages this kind of style doesn’t help at all. Now let’s take a look at some fairly clean Mustache.
<html>
<body>
<p>{{ GreetingText }}</p>
<table>
{{ #etc }}
<tr>
<td>{{ column1 }}</td>
<td>{{ column2 }}</td>
<td>{{ column3 }}</td>
</tr>
{{ /etc }}
</table>
</body>
</html>
Ah. Like breathing without a mask. (Edit, as of April 4th, 2022; I’m updating this post-COVID, so no pun intended.)
In fairness, my aversion to the the tag based language is more a matter of personal taste than anything else. It looks a bit too much like HTML and is not always supported by popular code editors. One of the interns in our department loves Sublime Text and, surprisingly, an easy to install plugin could not be found for the language. Additionally, it’s not consistent. Certain tags close, others don’t. Named parameters are not always easy to guess at and roll with, so this kind of hurts productivity. Queries are referenced using strings and not using hashes (e.g. ‘myQuery’ vs ‘#myQuery#’ ), but lists are the opposite. Again, minor niggles, but you can get an idea as to why some of these things are not useful when looking for a language that will last for a while.
So, not only does just about everything come with Lucee, but there is pretty distinct documentation on most of the language features that ship with it. The sites hosting CF documentation (whether it be Lucee’s or Adobe’s or this one) at least succinctly explain what everything does and provide some examples on how to use it.
One thing I always disliked about the PHP documentation was the inclusion of comments in their documentation. You read too far and you start looking at functions that have been deprecated or far simpler ways to pull off what you were trying to pull off. As a beginner anyway, none of that ever worked or would work in a previous version of the language, etc. I felt like there always something extra I needed to think about. CFML seems to work fairly reliably across its many available versions and functions that are and are not supported by a certain version of the server are pretty clear. It is a rare time indeed that I actually need to visit StackOverflow or some other site to figure something out.
One of PHP and Python’s greatest strengths are in their ease of extension. If you really need something to run fast or are looking to integrate the hottest new message queue library into your application, there is a clear documented way to do that. Neither Lucee nor Adobe have made that process super clear. And, of course, Java is going to be your preferred option when needing to implement a low-level extension.
A notable example of this was when we considered adding SASS to our toolkit at NC Central. The Java options were few and fiddly. There are, however, a number of strong C and C++ libraries out there to convert these files. Another time I’ve wanted this capability is when adding SQLite support to ColdMVC. There are apparently some ways to bind C++ code into Lucee, but this takes a fairly high level of wizardry and sifting to figure out how to do.
Lucee is pretty darn simple to get running. It’s also easy to be productive. When starting my position, I was productive with cfscript after about a month being at Central. (The first two weeks were spent peeking around the mostly CFML codebase and trying to figure out what I’m dealing with). I’m fairly strong in programming and know about 5 other languages well. But even if you’re a greenhorn, you’ll be able to figure out how to get rolling. We are not dealing with Haskell here, with its monads and other mythical species2. Also, for the Java/C#/Go heads, no compilation is needed. I don’t have a problem with compilation, but dynamic websites driven mostly by text really don’t have a need for those sorts of things.
CF is old. Like “Dave Mustaine, Gene Simmons and Public Enemy Do America Tour” old. Lucee is not the first attempt at open-sourcing the CFML engine. (It is arguably one of the best though, and the most well supported currently.) Because of the language’s age, CF talent may be running few and far between. ColdFusion talent is up there with COBOL talent as far as the animals in the ecosystem. Just something to be aware of.
After all of this, why would I advocate for the use of Lucee? The one large integration is a big plus for me. Even though there isn’t a ton of ColdFusion talent still kicking about, cfscript is a pretty easy language to come to grips with. I picked up the language in about two weeks, most of CF’s quirks within about two months and banged out a simple framework in about four hours within three months after starting my position. I didn’t even mention all of the other really super well written frameworks that are already out there. Framework One by Sean Corfield is a popular solution and pretty lightweight and easy to get around for a seasoned Java dev. ColdBox is the product of Ortus Solutions, and comes with a bunch of tooling in the form of CommandBox. It makes your ColdFusion sites act like node sites. A simple framework in Node would have taken me a bit longer, forced me to force my users to download a bunch of extra stuff that they probably don’t need, deal with dependencies not working with certain versions of a framework (cough Rails) and of course, I would have had to write my own server and tooling to administer it. Express is a situation where this is done well, but its still a lot to just get a website on the screen. I long for simpler days, and I’m one of the people who believe we can have them and still stay up to date on what’s hot in the market.