Hacker News new | past | comments | ask | show | jobs | submit login
Building ColdFusion for the Web (thehistoryoftheweb.com)
92 points by paulgb 11 months ago | hide | past | favorite | 79 comments



I built the first part of my career in ColdFusion, ran the local CF user group, and even spoke at a number of CF conferences. I even still run a production app and occasionally do consulting in CF.

CF, while still a commercial product, also has a well-maintained open-source version called Lucee [1]. There's a modern MVC framework called ColdBox [2], and the parent company also produces a number of amazing ecosystem tools like CommandBox [3] (a first-class tool for standing up local dev servers, dependency management, etc) and a modern testing framework [4].

I mostly focus on Rails these days, but there's a number of things I miss from the CFML world. (web GUI for configuration, in-memory ability to query recordsets with SQL, etc). I can't help but chuckle at things like server-rendered components which we were doing in the 90s with CF custom tags.

1. https://www.lucee.org/

2. https://coldbox.org/

3. https://www.ortussolutions.com/products/commandbox

4. https://www.ortussolutions.com/products/testbox


Could you expand on what does "web gui for configuration" mean?

Do you mean that CF came with a default system to create db-backed configurations with some pre-built UI?

That seems cool but somewhat nasty to deal with when having different environments.


No, I'm talking about application configuration. Things like database connections, caching, SMTP server, etc. All the things in contemporary frameworks that are stored in YAML or JSON files.


Important to note that this config is still stored in an XML file inside of WEB-INF and can be version controlled etc. (Or at least it can with Lucee. Don't know about Coldfusion Server. Surely nobody seriously uses that any more?)


Adobe CF also definitely uses an XML configuration as well.


What happened or what role has in this Open Blue Dragon?


Blast from the past. I was a lead ColdFusion developer for almost a decade. Good times. When I rearchitected the booking engine for all of the Disney Parks, I based the design on Fusebox, a popular ColdFusion framework at the time. It's still in use today.


Was Fusebox a predecessor to ColdBox?


Yes.


ColdFusion was a very influential language for me. I first encountered real world use of it in 2001 when I worked at TradingCars, a startup in the Netherlands. A guy could build in a few hours in Coldfusion a faster version of the same webapp that took several of us Enterprise Java guys several weeks to build. I think they even ended up dumping Java for the Coldfusion version in the end, but I can't verify that.

Anyway, I always loved the elegance and simplicity of the SQL embedded in the HTML (from what I remember).

Also interesting how the creator of Coldfusion, Jeremy Allaire, ended up moving to Crypto and creating Circle and USDC, one of the cornerstones of the whole crypto world.


I used ColdFusion for many years. I think it was a great choice back in the early 2000s. It is basically a JVM language where you can write cf at a high level and use straight Java in the same code base if you need to do anything more low level (like high almost never happened, but was useful on the rare occasions it arose).

But one of the main reasons it died off is license costs. The last time I was involved in license negotiations with Adobe, they wanted to charge us $100k per cpu core per server per year. These were cloud servers with many cpu cores and there were dev, qa and prod servers. The licensing cost for a single years was astronomical.

There are free versions of ColdFusion (Lucee is the best), but they are far too late for ColdFusion to make any sort of comeback.

The main thing I miss from ColdFusion is cfquery and cfquerypararms and query of queries. I’ve never seen any other language that makes database interactions as easy as those do. Every other language is such an enormous pain to do sql queries, when compared to cfquery.


I wrote CFML for the better part of two decades, only getting away from it in the past couple years.

I started back with 4.5 when I found it on a shelf at the publishing company I worked for in high school - a former employee had won it in a contest at a conference and had no idea what it was. I ended up building an entire ecommerce system on it, building many backoffice apps, connected to the mainframe and building far faster than the green screen programmers ever could. (this is not a critique of mainframes or green screens, there was much value there thats been lost, but I digress)

I am very happy to be away from CF today. it was one thing with macromedia, a different thing when adobe bought it and IMO mismanaged it over the years (I cant believe they still have it tbh, the money they make from legacy apps using it in the enterprise must be enormous), and while lucee started off great, it lost its way and never had enough resources to do things well.

But the biggest thing was that like many niche languages, you end up with a cult of zealots - either true believers, those whose livelihoods are tied to it, or those who are so pot committed to it they have to convince everyone around them that they’re continuing to make the right choice sticking with it. Ive seen it with many niche or dying languages, the ones that have been around as long as this one, really had time to metastasize, theyre the worst though. You cant criticize or critique without causing drama. “evangelists” jumping into every thread, yelling how CF isnt dead, how their latest framework is the one true way, arguing over things that dont matter. I know because I was one of those people for a decent stretch. Not wanting to believe that the language I had chosen and spent so much time with wasnt the the best.

But I also look back fondly on CF, and others like it. PHP, rails, these are looked down on today but there are so many places where they are an excellent choice for the job at hand. Types are fantastic once you reach a level of complexity and size, theyre a hindrance till then. The compiler is great when you reach that size, it slows you down till then. In my “modern” stack at work, there are lots of nice features, but the iteration speed is a tenth of what I had with my server-rendered, JIT, html sprinkled with programming language. We delivered more value, far faster.

So I guess ill just say, thank you CF for what you were, still are for many. If youre on the outside or inside nowadays, dont look down on it, but also dont think about it like religion.


I want to add one more thought here though: the one language that I will evangelize as long as I live, the one that will outlast them all is SQL - and credit where due, CF had a fantastic relationship with SQL, much better than many other comparable langs, honestly one of the best ive ever seen. cfquery was and still is the best thing CF ever had. No other lang was it as easy and fast to run a safe, parameterized sql statement and stick the results in html.


Absolutely. I mentioned this in another comment, but the fact that every language doesn’t have a version of cfquery (including query of queries) is criminal. It makes me sick when I have to work with sql in any other language because I always think how much easier it would be with cfquery. People should copy the best ideas and cfquery is one of the very best ideas ever to come out of programming languages. Everyone should be copying it.


As a teenager in the 90s, I built a huge site off of CFML, IIS 4.0, Apache 1.3 pre-fork, Windows NT, and MSSQL (6?). Really grateful for that tech back then.


ColdFusion was a great product for its time. My employer in the early 2000s had it as our default preferred language though if a client had a different language preference, we'd use that instead. Today most of my exposure to CF is through finding untouched old code still chugging along decades after it was first written. Unfortunately, injection vulnerabilities were pervasive in CF coding practices of the era and now it's very common to find old CF programs with thousands of vulnerabilities and no one to fix them. Any documentation on the business rules in them have long been forgotten. We have web application firewalls and other monitors in place to try to catch any vulnerable code being exploited and hope someday that the departments behind the programs decide they need a major overhaul that necessitates a greenfield rewrite. I did push for us to hire someone to either correct the vulnerable code or do a transliteration conversion to a contemporary tech stack but no one wants to allocate money for it, especially since the problem is spread around many different departments.

That the ColdFusion programs have been silently doing their thing for a long time without failing is a testament to the strength and durability of the platform. It also says something about what a sleepy, mundane employer I'm with now, but sometimes it's nice to not have to deal with everything around you being a moving part constantly changing its path.


I still use CFML today, albeit a fully open source rewrite of it. It’s insanely productive, even if it doesn’t tick all the modern enterprise programming boxes.


It’s true. CFML is the fastest nothing to something I’ve ever used.


CF is actually pretty good for server-side rendering. However, when mixing with JS it does get a bit convoluted.

I used it back in 2010-2014, and made some pretty nifty webapps to manage a tournament with brackets and live scores. I thought whoever designed it was bonkers, and the ones who bought into it, even more bonkers. But Ben Nadel showed me the way, bringing some sanity to the language.


Are you using Lucee?


Yep. It’s been running my large-ish website for over a decade. Performance, reliability etc are all off the charts compared to any other ecosystem I’ve used.


Is whirlpool.net.au built with coldfusion?


It’s built with CFML and the server ran ColdFusion in the early years but we switched to Railo (later Lucee) pretty much as soon as it was an option. Aside from being free, it was faster and more reliable.


Great to hear, whirlpool has helped me quite a bit over what seems like decades at this point. It's a great resource!


What’s the open source one called?



Hands up if you’ve still got ColdFusion powering critical apps in production to this day


Yup. I support a largeish legacy application for a federal government agency running on ColdFusion. The idea of rewriting it in another language is a tough sell as long as it's still supported by Adobe. I'm realistic about its past, present and future but I also still love using it every day.


I was watching all these "I used to CF" replies and wondering if anyone else was going to admit to having running applications. :-)


I still support a few sites and continue to update one large app written in it.


I was on the web early (building amzn in 94), doing everything from scratch in C++ with NSAPI. ColdFusion was probably the only tool I saw in that period that made me ever think "I wish we were using that". Probably for the best that we didn't :)


Heh, I was pretty young when I first managed to get my hands on a CF license. Like others said, CFML was amazing. The other thing I found that was amazing was their IDE. It was folded into Dreamweaver and never really fully recovered down the line but it really set the standard for features like symbol/syntax completion.

The misgiving it had I think was in being expensive and totally proprietary. I think it died sometime after the Adobe acquisition and cost was all I heard about. Interesting that there's a FOSS fork now though!


In the 90's I saw a poster calling for ColdFusion developers to apply, in one of those backlit poster stands, in the mall. That's how crazy the job market was.


Is there a modern version of CFML today or something currently maintained? It sounds really nice and stands in contrast to the convoluted options we have today.


I built the first part of my career in CFML. I then moved onto Rails, which I feel has much of the same ethos.

That said, Lucee is a well-maintained, open-source variant of CFML that you can use today. I still maintain a significant production app that uses it.

https://www.lucee.org/


Same, I run a large-ish website with it. Lucee is insanely stable and reliable, and is VERY actively maintained. It just works, and it keeps on just working.

The only thing going against it is prejudice, IMHO.


CFML was the easiest way to get into dynamic, server-side rendered pages back in the day. It was insanely productive and easy for a person cutting their teeth on programming as it was such a small leap from HTML.

I don't know of anything that still ticks those boxes but if you're just looking for (1) easy-ish, (2) interspersing HTML tags and code, and (3) server-side rendered simplicity, then PHP is still a very viable successor.


I'd say that PHP is actually a fairly good alternative to CF. It's probably why CF fell out of favor (CF was also a commercial product).

Early PHP was almost always embedded in HTML, like CF. It's been many moons, since I've worked that way, but many developers still do.


And indeed decades ago when i used CF, some developers would move to files that had all CF logic and no HTML, for an MVC-kind of setup where only the V was HTML with embeds. Similar to the trend in PHP.

(I stopped using it nearly 20 years ago and don't know what has happened since).

I would agree that PHP and CF (at least CF of 20 years ago) are pretty similar conceptually.


Yes, there is Lucee; I never used it, but when I was briefly asked to take on some Coldfusion work almost two jobs ago, I remember that I found it looked to be a vibrant and actively developed community, far different than what we were seeing of CF upstream that appeared to be on life support. I did not get into it, I'm afraid my manager thought I might like it too much and I was asked to work on something else about when it started heating up :( too bad for me.

I also remember coming across something called Railo that appears to have come before Lucee.


Lucee was forked from Railo (Railo, like Lucee, was well-maintained until the company that owned it and hired the developers mismanaged it. The developers left and went on to start Lucee)


Oh looks like adobe sells one. But I’m not a fan of their software so I wonder if there are any other comparable options?


Yes, there's an open source variant

https://www.lucee.org/


I almost became a CF dev in 2013.

I was living in my car and another car stopped at the rest stop making bad noises. I traveled with lots of tools and helped them diagnose the issue, and he said if I could write ColdFusion and PHP they would practically beg me to join (although he used a more sexual phrasing...).

Anyway I declined the offer and got a job writing PHP and Node... :)


Probably a solid life principal to decline sexually tinged offers at truck stops


i learned cold fusion in middle school. this was before stack overflow and i remember that one of the benefits to cfml was that it was highly guessable. i wasn’t great at consulting docs and once you got a few patterns you could figure the rest out with trial and error


I had to do a final project in ColdFusion in a web dev class in college (2006 I think?). It was a class where we had also used Perl, PHP and classic ASP. After that class I spent a lot more time with PHP and eventually ASP.NET, never touched ColdFusion again.

Unrelated, but by far the worst part of the class was the requirement to connect to MS Access databases, which were notoriously tricky to avoid locking, after which point the whole application would stop working until you figured out why. Many of us would keep a “clean” snapshot of the database around with the expectation we would somehow break/lock/corrupt the one the website was using. A reboot would also fix it but took a lot longer back then…


I was a Flash/AS3 developer before, saw ColdFusion every time in Macromedia software serial, never used it.

All macromedia tech stack dead now, the feelings of ColdFusion developers today, is the same like us legacy AS3 developer.


We built one of the first digital photo sharing / printing websites and its fulfillment system in ColdFusion in 1999.

The fulfillment system was a mess, but that was due to my lack of experience and not due to any issue with ColdFusion.

I will definitely have a look at https://www.lucee.org/ the next time I need to throw together a quick prototype.


I never used ColdFusion but I had a negative association with it because all the Latin American developers I knew while living in Brazil derogatively referred to it as "confusion." It must have been funnier in Spanish but I still got the joke.


Maybe they were expressing their confusion because you were speaking Spanish to people in Brazil?


Funny!

It was ironic that I lived in Brazil but because the entire office there spoke Portuguese they always sent me to the Spanish speaking countries. At that point I liked to travel and didn't mind staying in fancy hotels in Argentina and Chile. So all those conversations were in Spanish.

It isn't as funny to refer to ColdFusion as confusāo. I never heard a Brazilian make that joke.


Aha, I see, makes sense!


Ah.. my first Job was writing apps in cfm.


In 1997 I got a job at a local newspaper, threw together a weekly website that mostly consisted of hard-coded HTML templates and liberal use of `<frame>` tags.

After a few months and several hundred hard-coded files, a helpful fellow at our hosting firm introduced me to ColdFusion and Microsoft Access. That set the foundation for the next twenty-five years of my life, really.

Thanks CF!


Metafilter still runs on ColdFusion

https://metafilter.com


The ugly legacy of ColdFusion lives on in tools like Vue and AlpineJS.

If you like working with HTML, don't use tools that introduce proprietary syntax to inject janky control structure and looping logic.

Instead, consider StimulusJS, which allows you to add behaviors to elements in your DOM. It's the sharpest tool you're not using. Give it a shot before smashing that down arrow.


> Instead, consider StimulusJS, which allows you to add behaviors to elements in your DOM. It's the sharpest tool you're not using. Give it a shot before smashing that down arrow

I did. And that’s exactly why I’m smashing that down arrow. It’s highly subjective whether it’s the sharpest tool for the job, because for me it’s not.


> don't use tools that introduce proprietary syntax to inject janky control structure and looping logic

And StimulusJS doesn't?

   <div data-controller="modal"
     data-action="keydown.esc->modal#close" tabindex="0">
</div>

   <div data-controller="content-loader"
     data-content-loader-url-value="/messages.html"
     data-content-loader-refresh-interval-value="5000"></div>
Zealots cannot recognize a custom nonstandard poorly specified DSL even if stares them right in the face


Wait, do you mean this custom nonstandard poorly specified DSL? https://html.spec.whatwg.org/multipage/dom.html#attr-data-*

What you're showing above is 100% standards HTML 5. Data attributes have been a thing since 2008 or perhaps slightly earlier.

You might not love the look of it, but the markup above is something that your browser understands without interpretation. You can turn off JS and it will render without any issue whatsoever.

https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att...*

This is very different from tooling that uses alternative, non-HTML syntax. Our browsers might be written to be absurdly tolerant of broken markup, but that doesn't mean that Vue/HTMX/Alpine/CFML templates aren't proprietary.


FWIW I'm pretty sure Alpine can be configured to require `data-` as a prefix for its tags, e.g. `data-x-click="handleClick"`.


> What you're showing above is 100% standards HTML 5. Data attributes have been a thing since 2008 or perhaps slightly earlier.

So, which part of these is standardized and non-custom:

   keydown.esc->modal#close
   content-loader-url-value
   content-loader-refresh-interval-value
> This is very different from tooling that uses alternative, non-HTML syntax.

Ah yes. Pure HTML syntax of `keydown.esc->modal#close`


You appear to be confused. If you look in the specification I linked to, what you're hung up on is known as a "value".

It can be any valid characters required by your application.


> You appear to be confused. If you look in the specification I linked to, what you're hung up on is known as a "value".

Of course I'm not confused. You're hung up on the little insignificant part that `x="y"` is a HTML attribute and pretend that this immediately makes it standart non-weird DSL.

Funnily enough you share this with proponents of some other frameworks like lit. "But we use HTML attributes here's an MDN link"

> It can be any valid characters required by your application.

Indeed. So let's look at those characters, shall we.

First it's the literal "proprietary syntax to inject janky control structure" that you complain about. Funily enough you're ignoring this when I'm pointing it out:

    click->gallery#next
    keydown.ctrl+a->listbox#selectAll
    resize@window->gallery#layout
    click->gallery#open:capture
    scroll->gallery#layout:!passive
Second, you have a literal custom DSL composed of data-attributes.

    # Passing params to events
    data-[controller-name]-[param-name]-param

    # "Targets". All elements will be put into an array in [field-name]
    data-[controller-name]-target="[field-name]"

    # "Outlets" because you need a different name for references
    # to instances of other classes
    data-[controller-name]-[field-name]-outlet

    # Data binding. Much like Vue, it requires a specific 
    # structure of values present in your code
    data-[controller-name]-[value-name]-value
    
    # An additional data binding for CSS classes
    # that are also specified separately
    data-[controller-name]-[css-class-name]-value

But zealots are completely blind to the fact that they also have a non-standard badly specified hacky DSL because "but we use HTML attributes".


You can say this as many times as you want, but you're factually incorrect and conceptually misguided.

HTML attributes were literally created to do the exact thing that you seem to think is a smoking gun.


> but you're factually incorrect

I've provided the actual facts that you ingored

> HTML attributes were literally created to do the exact thing that you seem to think is a smoking gun.

1. You complain, and I quote, "proprietary syntax to inject janky control structure".

What's this then:

    click->gallery#next
    keydown.ctrl+a->listbox#selectAll
    resize@window->gallery#layout
    click->gallery#open:capture
    scroll->gallery#layout:!passive
2. Do read up on what DSL means. The fact that you're using custom tags to implement it don't make any less of a DSL, and any less of a proprietary syntax.

Though... You know what? Don't bother. Zealots are blind.

Adieu.


Stimulus is great, but a technology that really gives me the vibe of working with CFML is HTMX.

I think the "ugly legacy" is a bit of a near-sighted perspective. Today CF's reputation seems limited to being a spaghetti-riddle mix of HTML with logic, but for the era it was built in, it was an amazing language focused on productivity.


I agree that HTMX is in this camp. My primary frustration with HTMX - even more than the CF-inspired syntax - is that it's fundamentally a client-side solution. Better than nothing, but if you want to build the next Figma, you need to look towards a toolset where the single source of truth is on the server. StimulusReflex on Rails or Phoenix LiveView on Elixir are a lot closer to a full-stack solution.

Obviously, all of this is highly subjective. When ColdFusion came out, I was primarily working in ASP and its OSS clone, PHP. You'll have to trust me when I say that my opinion on the ugly was formed at the time, and hasn't changed since.

It seems as though folks either like interpolated templates (ASP, PHP, ERb), components (React and etc) or macros (CF, Alpine, HTMX). It could be that one's first true love endures.


Such a weird comment... nobody would ever suggest using HTMX to build a "desktop app" running in the browser like Figma. But since 99% of projects are nothing like Figma, it's typically not an issue.

But HTMX practically requires server-side state. The whole point is to make it very easy to frequently update, and receive new content from, a server (HATEOAS), and NOT to maintain state client-side. If you're building a site "where the single source of truth is on the server" then HTMX fits perfectly.


The difference I'm referring to is "requires" vs "ships with".

As to whether a requirement is typical or not, I am frustrated by local maximum thinking. If your tooling cannot build an ambitious project, then you're not going to build an ambitious project.

I actively try to spend my finite time on ambitious projects in general. You don't need LiveView or StimulusReflex to build a landing page, that's true. But if you're building an ambitious real-time web app, the range of complexity where it makes sense to use HTMX instead of a full-stack solution gets smaller very quickly.


I think you're either misguided, or just a hater.

HTMX can accommodate ambitious, real-time web apps. Its entire purpose is to make interacting with a server (that single source of truth) easy, fast and transparent, as if doing so was simply built in to the HTML spec.

What it can't do, is calculate the shape of a bezier curve, and that's why it's not a good choice for building an app like Figma.


I definitely do not like HTMX, that much is true. Does that make me a hater?

I'm reading what you're saying, and it's very clear that you do not understand what frameworks like StimulusReflex and LiveView do for you. There is no fair comparison between HTMX and frameworks that ship with a server-side infrastructure for maintaining a long-lived, persistent connection.

I won't mock you if you set aside your assumptions, investigate and have a moment of illumination.


How is it clear that I don't understand those frameworks when I haven't said a word about them? I've commented exclusively on HTMX and its use cases, you're the only one making comparisons.


It's because you keep implying HTMX is a good choice, when there are vastly more powerful solutions in play.

I know a guy who still insists that MS Access is the best database tool. His identity is fully wrapped up in this being true.


You have very poor reading comprehension. I never claimed HTMX was "the best." But yes, HTMX is a fantastic tool (and language agnostic), and the existence of other frameworks does not diminish its utility. If your only argument is to compare it to 30-year old Access/Jet, you're simply exposing your own lack of credibility and inherent irrelevance.


Serious question: are you wickedly combative in all discussions, or just when you get the cold feeling that perhaps you might not know as much as you think you do?

If you look through the progressive responses you've given, you resort less to actual technical points and more to personal attacks. It's weird.

When you stop rage replying and take an honest look at how LiveView or StimulusReflex work - for you actually can build the next Figma with them - you'll see that the comparison between Access and a modern database is pretty apt.

I'm specifically talking about a dramatically higher ceiling of possibility in terms of the problems that you can solve.

If you'd rather exhaust yourself trying to make personal attacks than level up your current local maximum perspective, there's really nothing else I can tell you.


Oh jeez, quit with the self-righteousness, each of your comments contains some passive-aggressive dig (HTMX = Access, HTMX is for "a landing page", I need "illumination"). You haven't stated a single "actual technical point" either. Let it go.


You don't have to like what I'm saying for it to be true.

If two people set out to build something like Figma - one in HTMX and one in LiveView - only one is going to ship.

That's not passive aggressive. It is as you say, an actual technical point.


if someone asked me if they should build figma in htmx, I would say no:

https://htmx.org/essays/when-to-use-hypermedia/




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: