Lucee: A dynamic, Java-based, tag and scripting language for web app development(github.com)
github.com
Lucee: A dynamic, Java-based, tag and scripting language for web app development
https://github.com/lucee/Lucee
68 comments
Most of the stagnation happened under Macromedia, not Adobe.
Apologies, you're probably right about that.
It's all good. I was going to respond with some of the history. I had typed up a good story, but accidentally deleted my tab. Oh well.
I’m having a hard time understanding how to build apps with this. The docs are an endless labrynth of links containing very little meaningful information on what everything does and why it’s good.
At this point the only thing you can glean is it resembles java and it’s targeting the JVM.
A true start to finish hello world or basic app would be nice to see.
At this point the only thing you can glean is it resembles java and it’s targeting the JVM.
A true start to finish hello world or basic app would be nice to see.
You wouldn't build apps with this. It's essentially a modern implementation of a ColdFusion engine. CFML is quite arguably an abandoned language and should never be used in new projects.
The only meaningful use case I see in Lucee is to be able to run and maintain legacy CF applications in an environment that is still supported without rewriting them for a more modern and capable language/runtime. It would be best utilised for putting legacy applications on life support, not for creating the next big thing.
The only meaningful use case I see in Lucee is to be able to run and maintain legacy CF applications in an environment that is still supported without rewriting them for a more modern and capable language/runtime. It would be best utilised for putting legacy applications on life support, not for creating the next big thing.
I've got a lot of friends building new apps using it. I'm using it for the REST back end of my new startup. There's a strong vibrant community on Slack.
It may not be as popular as other languages but it has two advantages:
1. Rapid application development
2. A glue that ties other enterprise apps together
I got into a fight on Twitter over using CFML for new projects with a rather prominent fellow in the coding world. The year was 2008 and a lot of apps have been written in it since then;<).
It may not be as popular as other languages but it has two advantages:
1. Rapid application development
2. A glue that ties other enterprise apps together
I got into a fight on Twitter over using CFML for new projects with a rather prominent fellow in the coding world. The year was 2008 and a lot of apps have been written in it since then;<).
> You wouldn't build apps with this.
Why not? The environment is feature rich, runtime performance is fantastic, developer productivity is exceptional, and integration is compelling because it runs in the JVM. Yes, the JVM. So even if Lucee doesn't do what you need, you can natively call upon countless Java features like javax.script or javax.crypto, or third-party Java libs like JSoup or Lucene with just a couple extra lines of code.
And yes, like any language, it doesn't stop you from writing incompetent and stupid shit. The one big knock against the ColdFusion-inherited language is that the templating syntax is often overused for writing code, when it also has a great C/Java/JS-style scripting syntax.
Why not? The environment is feature rich, runtime performance is fantastic, developer productivity is exceptional, and integration is compelling because it runs in the JVM. Yes, the JVM. So even if Lucee doesn't do what you need, you can natively call upon countless Java features like javax.script or javax.crypto, or third-party Java libs like JSoup or Lucene with just a couple extra lines of code.
And yes, like any language, it doesn't stop you from writing incompetent and stupid shit. The one big knock against the ColdFusion-inherited language is that the templating syntax is often overused for writing code, when it also has a great C/Java/JS-style scripting syntax.
I disagree.
If you want legacy support, simply use the older Adobe provided Linux CF engines.
Look at the Coldbox framework and you will be pleasantly surprised at the implemented best practices and ease-of-use, all running in Lucee.
If you want legacy support, simply use the older Adobe provided Linux CF engines.
Look at the Coldbox framework and you will be pleasantly surprised at the implemented best practices and ease-of-use, all running in Lucee.
My thoughts are the same. I was looking for a simple hello world and it is a bit of a puzzle to find that.
Right on the front page a simple snippet example would already do wonders. Especially if the "rapid prototyping" is a key attribute.
Right on the front page a simple snippet example would already do wonders. Especially if the "rapid prototyping" is a key attribute.
Hello World in Lucee would simply be:
echo "Hello World" > hello.cfm
As @aidos and @abraham_lincoln pointed out, an "Hello World" example is simply putting that string in a file named hello.cfm on the root of the web application and calling it with your browser, e.g. http://localhost:8080/hello.cfm
Before you can do that though, you need to install the CFML engine. I recently published a tutorial that shows how to install Lucee in Tomcat very easily:
https://www.youtube.com/watch?v=nuugoG5c-7M
http://blog.rasia.io/blog/how-to-easily-setup-lucee-in-tomca...
To make your Hello World example a bit more interesting, you can add the tag `<cfoutput>` with some dynamic content, e.g.
Before you can do that though, you need to install the CFML engine. I recently published a tutorial that shows how to install Lucee in Tomcat very easily:
https://www.youtube.com/watch?v=nuugoG5c-7M
http://blog.rasia.io/blog/how-to-easily-setup-lucee-in-tomca...
To make your Hello World example a bit more interesting, you can add the tag `<cfoutput>` with some dynamic content, e.g.
<cfoutput>
Hello World on #dateTimeFormat(now(), "mm/dd/yyyy 'at' HH:nn:ss")#
</cfoutput>
This would be a great "Hello World" snippet to thrill the newcomers on the website. That simple paragraph as you wrote.
Enough already to entice further curiosity now to explore on the dynamic content portion and start thinking on where this thing can be used on my daily tasks. All the best with Lucee.
Enough already to entice further curiosity now to explore on the dynamic content portion and start thinking on where this thing can be used on my daily tasks. All the best with Lucee.
<cfdump var="Hello World!">
or
writeDump("Hello World!");
or
writeDump("Hello World!");
It's just ColdFusion/CFML.
The best approach would be the ColdBox framework at https://www.coldbox.org/
The best approach would be the ColdBox framework at https://www.coldbox.org/
Please work on your documentation.
It is very unclear what this is, how to use it, how to get started, where to find a simple example.
Everything is spread out over 50 different links and pages with labels like
Getting Started Start Here First Steps
and none of that is really applicable to actually "what do I do to use your product".
It is very unclear what this is, how to use it, how to get started, where to find a simple example.
Everything is spread out over 50 different links and pages with labels like
Getting Started Start Here First Steps
and none of that is really applicable to actually "what do I do to use your product".
Definitely could be better, but as it's really just ColdFusion/CFML, cfdocs.org is the best resource. I think the assumption is that most people are coming to Lucee as the open source alternative to the Adobe ColdFusion product, but obviously that's not a good assumption to make.
I guess... I mean that assumption could be basically accurate yet still a questionable decision.
Seems like an assumption one would make who doesn't intend for their project to survive or grow. Don't they want new users, or just a continuously decreasing set of current ones?
And it would seem like working on a project with those intentions would be a waste of time for all involved.
> "it's really just ColdFusion/CFML, cfdocs.org is the best resource"
This should be the first thing I see on the website with a link to cfdocs.org
Seems like an assumption one would make who doesn't intend for their project to survive or grow. Don't they want new users, or just a continuously decreasing set of current ones?
And it would seem like working on a project with those intentions would be a waste of time for all involved.
> "it's really just ColdFusion/CFML, cfdocs.org is the best resource"
This should be the first thing I see on the website with a link to cfdocs.org
Yeah for years that was a conversation about trying to sever the connection with ColdFusion, since it's definitely not one of the kewl kid languages.
No code snippets and a tiny README.md that just links to other stuff is a great way to get me to hit the back button.
Edit: So, there's a link to docs on the Github page. http://docs.lucee.org/. You need to click "About Lucee", and ignore the page they take you to, then, in the nav-bar you need to click "Why Lucee Server's great". Or, if you didn't have the patience, you can click here https://docs.lucee.org/guides/about-lucee/why-lucee-server-g...
This definitely needs to be the first thing I see on the Github page...
Edit: So, there's a link to docs on the Github page. http://docs.lucee.org/. You need to click "About Lucee", and ignore the page they take you to, then, in the nav-bar you need to click "Why Lucee Server's great". Or, if you didn't have the patience, you can click here https://docs.lucee.org/guides/about-lucee/why-lucee-server-g...
This definitely needs to be the first thing I see on the Github page...
Already on the getting started page I see something that looks almost like possible SQL injection: https://docs.lucee.org/guides/getting-started/first-steps.ht...
I hope I'm wrong?
I hope I'm wrong?
Sometimes things get simplified in tutorials. Best practice in CF is to use cfqueryparam:
SELECT * FROM #strDatabasePrefix#_courses WHERE intCourseID = <cfqueryparam value = #intCourseID# CFSQLType = "CF_SQL_INTEGER">
You would also want to protect your input variables so that you only get what you're expecting.
There's also a free service called HackMyCF that lets you check your server after you've hardened it with the guide that comes with both Lucee and Adobe CF.
https://foundeo.com/hack-my-cf/
SELECT * FROM #strDatabasePrefix#_courses WHERE intCourseID = <cfqueryparam value = #intCourseID# CFSQLType = "CF_SQL_INTEGER">
You would also want to protect your input variables so that you only get what you're expecting.
There's also a free service called HackMyCF that lets you check your server after you've hardened it with the guide that comes with both Lucee and Adobe CF.
https://foundeo.com/hack-my-cf/
> Sometimes things get simplified in tutorials
That’s putting it nicely. What’s happened is you’re showing users the wrong way to do something without it being explicitly clear to them. Then we wonder why people write crap code...
My view is NEVER simplify an example to the point it becomes a security or performance hazard.
What this tells me now is that this projects examples are not useable, their agenda is to make things appear easy when in fact concrete examples may not be.
That’s putting it nicely. What’s happened is you’re showing users the wrong way to do something without it being explicitly clear to them. Then we wonder why people write crap code...
My view is NEVER simplify an example to the point it becomes a security or performance hazard.
What this tells me now is that this projects examples are not useable, their agenda is to make things appear easy when in fact concrete examples may not be.
I am quite certain, regardless of language, a good developer would be aware that input for a DB needs to be sanitized.
Equally, one could argue a 'good' developer would not in any way be put off by an example that demonstrated good security practice.
And 'good' needs to be put in context: e.g. a 'good' hardware or kernel engineer who never wrote front-end stuff may legitimately be unaware of the need to defend against SQL injection unless its written somewhere.
If they're as 'good' as you're expecting they would probably not even require a getting started tutorial...
Anyway, this is something I see in many tutorials and its somewhat unfair to single out Lucee. I just wish tutorial writers would put effort into real-world examples more often.
And 'good' needs to be put in context: e.g. a 'good' hardware or kernel engineer who never wrote front-end stuff may legitimately be unaware of the need to defend against SQL injection unless its written somewhere.
If they're as 'good' as you're expecting they would probably not even require a getting started tutorial...
Anyway, this is something I see in many tutorials and its somewhat unfair to single out Lucee. I just wish tutorial writers would put effort into real-world examples more often.
And what about all the none-"good" developers?
There are also frameworks that do the sanitization for you (e.g. Rails IIRC), and novice developers coming from those certainly might not be aware.
There are also frameworks that do the sanitization for you (e.g. Rails IIRC), and novice developers coming from those certainly might not be aware.
It's not a great example as it's trying to be ultra simple for first steps.
There's a lot of built in security to Lucee/CF but for a query I'd always be doubly sure and explicitly state the parameter data type as well and that'll definitely block SQL injections. So this code would be:
queryExecute( "select * from employee where id= :itemID" { itemID = { value=arguments.itemID, cfsqltype="cf_sql_varchar", list=true } } );
There's a lot of built in security to Lucee/CF but for a query I'd always be doubly sure and explicitly state the parameter data type as well and that'll definitely block SQL injections. So this code would be:
queryExecute( "select * from employee where id= :itemID" { itemID = { value=arguments.itemID, cfsqltype="cf_sql_varchar", list=true } } );
That works, though I think most developers are drawn to the markup style <cfquery> (I've been building CFML apps since 1999, and I don't know if I've ever seen queryExecute in the wild)
I've seen both in security reviews, primarily driven by where the code fits in the application. The more modern apps that I've come across (with stronger coding standards) restrict tag-based code to view templates.
Just want to point over to the CFML Slack channel: https://cfml-slack.herokuapp.com/
I've found it a great developer community. We're containerizing some Lucee apps and they've been really helpful.
The language is by no means dead.
I've found it a great developer community. We're containerizing some Lucee apps and they've been really helpful.
The language is by no means dead.
Ah CFML. Lucee is the descendant of an open source replacement for the ColdFusion templating language.
Mura CMS runs on Lucee https://www.getmura.com/
It's definitely not the usual HN web building community though. Less swagger, more sell.
Mura CMS runs on Lucee https://www.getmura.com/
It's definitely not the usual HN web building community though. Less swagger, more sell.
DO NOT mention Mura CMS. I never thought that something could be coded worst than WordPress until I saw Mura's code. It is an embarrassment and should just die a horrible death.
If anyone is interested in more resources Lucee is pretty much interchangeable with Coldfusion (CF):
Learn Modern ColdFusion (CFML) in 100 Minutes: https://modern-cfml.ortusbooks.com/
Learn CF in a Week: http://www.learncfinaweek.com/
CF Docs: https://cfdocs.org/
TryCF (in browser CodePen style): https://www.trycf.com/
Learn Modern ColdFusion (CFML) in 100 Minutes: https://modern-cfml.ortusbooks.com/
Learn CF in a Week: http://www.learncfinaweek.com/
CF Docs: https://cfdocs.org/
TryCF (in browser CodePen style): https://www.trycf.com/
For anyone who was as confused as I was, this page has all the answers https://docs.lucee.org/guides/getting-started/getting-to-kno...
I got my first development job and learned the basics of full-stack development thanks to CFML. It certainly can be a good tool for the right size company, and I made a fair amount of money writing it over the years. The ecosystem is small-ish, but the community is great.
Nowadays, I prefer to use a strongly-typed, compiled language for server-side code (C#). I get a certain peace-of-mind when it compiles successfully that just I don’t get with interpreted languages.
Nowadays, I prefer to use a strongly-typed, compiled language for server-side code (C#). I get a certain peace-of-mind when it compiles successfully that just I don’t get with interpreted languages.
I worked for a company that was in the process of moving their coldfusion application to a django application. We decided to move from Adobe's cold fusion server to Lucee, the process wasn't seemless but the road bumps we're smoothed out pretty quickly. Lucee is quite good.
Lucee also has a much better Docker story than Adobe ColdFusion.
I tried using Lucee once (recently) to see if I could get a back-end in coldfusion moved over. The admin of Lucee broke so bad, from making one change with one mistake, I had to reinstall. When it broke again, I just chucked it out of the window and wrote it off. If you know how shitty Coldfusion is, or even if you have no idea, don't waste your time with Lucee. This is one of the few things I wish I could down-vote on hacker news. Seriously.
You know you can download older Linux based actual CF engines from Adobe?
You can also modify the Lucee admin settings to be compatible with older versions.
You can also modify the Lucee admin settings to be compatible with older versions.
Yes, but Adobe's product isn't open source or free, in case that's a requirement.
I haven't had that experience (migrated multiple Adobe CF apps to Railo/Lucee; been working with the language since 1999)
It's an open source project, so something isn't working, did you file a bug?
Oh, CFML. I was recently involved in adding Kafka support to an older CFML application. I found a couple of things that were really difficult to work around:
- the versions of some (most?) of the libs Adobe CF (even 11) depends on are ancient, years old, shading had to be used a lot, a lot to add things like Kafka or protobuf
- EVERYTHING loads into a single JVM process, every gateway shares the same JVM with the application server
How does Lucee handle this?
- the versions of some (most?) of the libs Adobe CF (even 11) depends on are ancient, years old, shading had to be used a lot, a lot to add things like Kafka or protobuf
- EVERYTHING loads into a single JVM process, every gateway shares the same JVM with the application server
How does Lucee handle this?
One of the big architectural changes in Lucee 5 was moving to OSGI https://docs.lucee.org/guides/lucee-5/osgi.html which is much more flexible
I can't wrap my head around why anyone would like to use a tag language. Feel like some kind of XML hell.
They wouldn't, they would just use Lucee's script syntax instead which is very similar to JavaScript.
That’s how I feel about JSX, but it seems pretty well accepted these days. Spurious end tags were once regarded with more horror.
The general best practice is script-based syntax in your controllers and models, and tag-based in your views. You choose what makes the most sense and is easiest, which feels cleaner than many templating approaches where you're shoving syntax into expression tags.
It has its uses. It's a good fit for the actual templating part where it feels pretty natural mixed in with html.
Check out the Coldbox framework.
I think it is pretty cool.
I think it is pretty cool.
Lucee makes it really simple to take advantage of multi-threading
http://blog.rasia.io/blog/easy-parallelism-in-lucee.html
I really want to get into Lucee. It reminds me of the tagged system of FileMaker v6 using CDML (Claris Dynamic Markup Language). I was sad when the next version of FileMaker got rid of it as it was so easy.
It's really just ColdFusion, which has been around since the mid-nineties.
cfdocs.org is a good resource; learncfinaweek.com is a good resource (but leans toward the commercial Adobe ColdFusion product, but syntax is pretty much the same). You'll want to look at coldbox.org for a full-featured framework.
cfdocs.org is a good resource; learncfinaweek.com is a good resource (but leans toward the commercial Adobe ColdFusion product, but syntax is pretty much the same). You'll want to look at coldbox.org for a full-featured framework.
I'm all for cool new projects, but when the first thing I see in a project's readme is "build: failing", I'm really discouraged from looking into it further.
https://travis-ci.org/lucee/Lucee/branches
master branch being broken for 3 months doesn't exactly instil a lot of confidence in something that seems to be intended to run critical legacy software
master branch being broken for 3 months doesn't exactly instil a lot of confidence in something that seems to be intended to run critical legacy software
Other people's branching strategies are often a mystery to me.
If master has 20 builds and the latest stable release branch has 1071 builds and there are 25 stable versions currently available for download but those only go back to version 4.5; then I think they're not using master as the stable release branch.
5.2 is the stable branch https://github.com/lucee/Lucee/tree/5.2
5.3 is the active development branch https://github.com/lucee/Lucee/tree/5.3
5.3 is the active development branch https://github.com/lucee/Lucee/tree/5.3
You mean having a failing build like this new project?
https://travis-ci.org/rails/rails
FWIW, Lucee has been around for several years. (prior to Rails) It originated as Railo; some issues with the company that owned Railo the company led to the same development team forking to Lucee.
https://en.wikipedia.org/wiki/Railo#History
https://travis-ci.org/rails/rails
FWIW, Lucee has been around for several years. (prior to Rails) It originated as Railo; some issues with the company that owned Railo the company led to the same development team forking to Lucee.
https://en.wikipedia.org/wiki/Railo#History
Ahhhh Lucee... An engine specifically designed by developers who refuse to learn/accept NodeJs.
I made a decent career as a ColdFusion developer for about 10-years. I embraced Lucee when it first was launched, and I still use it when I get in a bind.
But that being said, I bit the bullet about 3-years ago, and switched to NodeJS. It's simplicity and speed just doesn't compare.
The CF community has failed to realise that web pages don't really refresh anymore. We are in a world where JavaScript rules the front end, single-page apps are king. So the only useful part of CF is as an API engine, and frankly, NodeJS, Go Lang, Elixir, and Python will all run circles around it.
I made a decent career as a ColdFusion developer for about 10-years. I embraced Lucee when it first was launched, and I still use it when I get in a bind.
But that being said, I bit the bullet about 3-years ago, and switched to NodeJS. It's simplicity and speed just doesn't compare.
The CF community has failed to realise that web pages don't really refresh anymore. We are in a world where JavaScript rules the front end, single-page apps are king. So the only useful part of CF is as an API engine, and frankly, NodeJS, Go Lang, Elixir, and Python will all run circles around it.
That's a little unfair since NodeJS was released 3 years after Lucee (then Railo). And probably the main usecase is more around people with stack loads of code already that they need to keep running. If you were a CF shop, throwing everything out and switching to Node was probably not a great use of your time, especially given that Node didn't even exist at the time! :-)
try not to break your arm patting yourself on the back.
I switched from ColdFusion years ago as my primary language cause of the job market (as i'm sure many others have), not because it is a bad language OR because it was tag based. to be completely honest, ColdFusion itself is an outstanding product and STILL is so easy for a barrier of entry and setup.
the things (to me) that are kill it a) the price is ridiculous, b) they never officially supported a framework in the era of MVC (ColdBox, FW/1, CFWheels would all have made a good candidate) and c) they never listened to their developers about features to implement.
I switched from ColdFusion years ago as my primary language cause of the job market (as i'm sure many others have), not because it is a bad language OR because it was tag based. to be completely honest, ColdFusion itself is an outstanding product and STILL is so easy for a barrier of entry and setup.
the things (to me) that are kill it a) the price is ridiculous, b) they never officially supported a framework in the era of MVC (ColdBox, FW/1, CFWheels would all have made a good candidate) and c) they never listened to their developers about features to implement.
THIS.
I'll add that when Adobe CF introduced a "richer" script syntax, it wasn't complete and along the lines of too little, too late. This is where MACR stagnated. Had CF introduced a full blown scripting language in the early 2000's, CF would certainly have a little more staying power these days, especially with open source implementations like Lucee.
The biggest problem for ColdFusion is that there was a time (2008-ish) that the open source web development world innovated and evolved by leaps and bounds around it and CF stood still. One of CF's biggest selling points was that it wasn't open source and that it wasn't PHP. I'm not knocking PHP; the reality was that there were a ton of companies that would steer clear or open source projects back in the mid-2000s. If you were doing "enterprise" web development in 2003-2005, you were either doing Classic ASP, Java, or ColdFusion.
I'll add that when Adobe CF introduced a "richer" script syntax, it wasn't complete and along the lines of too little, too late. This is where MACR stagnated. Had CF introduced a full blown scripting language in the early 2000's, CF would certainly have a little more staying power these days, especially with open source implementations like Lucee.
The biggest problem for ColdFusion is that there was a time (2008-ish) that the open source web development world innovated and evolved by leaps and bounds around it and CF stood still. One of CF's biggest selling points was that it wasn't open source and that it wasn't PHP. I'm not knocking PHP; the reality was that there were a ton of companies that would steer clear or open source projects back in the mid-2000s. If you were doing "enterprise" web development in 2003-2005, you were either doing Classic ASP, Java, or ColdFusion.
> An engine specifically designed by developers who refuse to learn/accept NodeJs.
You do realize Railo (which Lucee forked from) was first released in 2004?
You do realize Railo (which Lucee forked from) was first released in 2004?
People have a lot of hate because, Coldfusion, but actually, they got it to a really good place. It has a lot of stuff baked in, so you can configure everything like dB connections, mail settings etc outside of your app and they’re available without any messing around in your code. CFML is actually a pretty clean templating language and everyone had switched to “cfscript” for the actual code. Also, it was relatively fast, and you could plug in any java classes you wanted (and even load them dynamically).
My point is, don’t be too quick to judge. This is actually a good bit of work that came along after it’s lineage had fallen out of fashion.