Lucee 5 beta: .lucee files

G'day:
I held off on this one hoping more information would come through from LAS, but I've run out of other documented features to look at, so here we are.

Lucee has added a new "language" to their engine, which is a dialect of CFML.

The beta docs say this about it:

The Lucee dialect is a modern language based on the original concepts of CFML. It is completely open source and exposes the most advanced features of the underlying JVM with performance, class loading, OSGi and JSR-223 support at its core. The Lucee language will continue to evolve to meet the ever increasing demands of modern web application development.

The Lucee language is LAS’s opportunity to evolve a modern dialect that is both familiar to existing CF developers while providing the freedom to grow in a more ambitious direction and LAS are committed to this as much as they are to supporting the CFML development community.

So the positioning is that it's an alternate language to use instead of / as well as CFML. I'll get back to that.

First things first... they need to give this language a name. We cannot keep saying "Lucee Dialect", because that's rubbish. And "Lucee" doesn't really work as a language name either, as it's the name of the app server, which is more than just the language, so is not a good way to disambiguate the two. One can get away with the term "ColdFusion" to refer to both the server than the language it processes because that's all the server does. Obviously "ColdFusion" isn't the name of the language though, it's CFML. But Lucee (the server) doesn't simply process Lucee Dialect, so that doesn't work there.

Another issue here is that they're clearly trying to suggest that CFML has its issues that TLD (nah, can't even say that, dammit!) The Lucee Dialect solves. But if it's referred to as a dialect, the next question is going to be "dialect of what?"; to which the answer is "um... well CFML". So that distancing idea doesn't run very far.

Unfortunately they've jumped the gun slightly and settled on the file extension of .lucee, which now kinda does link the code to the app server name.

I have a suggested solution for this, which I'll get to.

The second thing... as it currently stands, one cannot create components with .lucee files because of a bug in Lucee 5.0.0.43: 294. There's a syntax error in one of the core files which prevents any .lucee-based component (I almost said "CFC" then, oops) from working. I hasten to add this is fixed, but if you start messing around with this stuff today, you will need to go fix a file first. Open this file: [Lucee base dir]\webapps\ROOT\WEB-INF\lucee\context, which has this in it:

<cfcomponent displayname="Component" hint="This is the Base Component"></cfcomponent>

You need to change that to this:

<:component displayname="Component" hint="This is the Base Component"></:component>

Then things'll work. Micha's fixed this, and I guess it'll ship in 5.0.0.44. Hopefully they're also write some tests for this, this time.

OK, so the chief difference between The Lucee Dialect and CFML is demonstrated there. Tags are like this:

<:nameoftag>

Rather than this:

<cfnameoftag>

The Lucee Dialect files also have some different compiler/runtime settings than CFML files do. Mostly tweaks Railo / Lucee had done as options are now the standard in The Lucee Dialect files.

These include:

• null exists as a concept.
• Variables are local to functions by default.
• Component-wide variables are declared with the prefix this.
• These component-wide variables are private by default, but can be declared as public if required.
• Function arguments can exist in addition to same-named local variables, and can be disambiguated by prefixing the argument with the arguments scope. If they don't need to be disambiguated, they do not need that prefix
• Component-wide variables likewise can be disambiguated with the this scope prefix, but it is not necessary if there are no same-named local variables or arguments.
• Dynamic tag attribute values are treated as expressions by default.

I've purposely tried to position those as independent language features, not comparing them back to CFML as an exercise.

That's not really a terribly compelling list, but they must be the high points as it's all LAS have chosen to document so far. There's more documentation "coming soon", according to the docs page.

I don't feel I need to show you any code, as it's just CFML except with "<:" instead of "<cf".

To be honest, I think they should pull this feature from Lucee 5. As it stands, it's a working proof of concept, but it seems too feature-poor to think about launching yet. When launching something new, it needs to be compelling, and "does a few things different from CFML" isn't compelling. It would also need to have a few things ready to run out of the box if it was to be "a thing":

• a plug-in for some text editor / IDE to support syntax awareness of Lucee files.
• Online docs.
• Some popular CFML third-party applications ported to run on it. I'd pick:
  • FW/1
  • DI/1
  • Taffy
  • perhaps PresideCMS
    
  Although given Ortus is an investor in LAS, I would expect it'd be more likely to be ColdBox and Wirebox there, instead of FW/1 and DI/1.

And, yeah, I get that Lucee will play nice with CFML, this is beside the point in the context of The Lucee Dialect if it is to have meaning in and of itself. If it doesn't have meaning in and of itself, then it's a pointless exercise.

I suppose LAS can position it as a "build it and they will come" exercise, but... with such a small CFML community already and only a fraction of that having been the Railo community, and a smaller fraction still migrated to be the Lucee community... I'm not sure "they will come". Especially as the CFML community ain't so good with the whole "community spirited helping out with the work" pragma.

I also think The Lucee Dialect should be sharded-off from the main CFML server project entirely, and just treated as a plug-in to the main gig. Lucee's CFML offering is pretty mature, whereas The Lucee Dialect is not. Accordingly its release cycle will be different, its versioning should be different, and it needs to exists as its own thing. Well: in a way there should be three projects: the server, the CFML component and The Lucee Dialect component are all different things.

My bottom line opinion is that this feature is kinda the <cfclient> of Lucee. I'm not sure why they did it, and not exactly sure what it is they have actually done. And unless they demonstrate something interesting about it, I don't think I'll be revisiting it. That said, as they themselves said they haven't actually documented it properly yet, so they might have mentioned all the wrong stuff in the beta docs. It could be really good. But I would have expected that they'd promote the good stuff up front. I know the LAS bods are marketing-naïve, but surely not that marketing naïve? The exciting stuff comes first, yeah? So was that the exciting stuff? Blimey.

Let's wait and see. But I think the key here is: "wait".

--
Adam