You'll have to forgive me for a moment. I've just recently realized I'm not a Mura developer.

Now, as a revelatory moment, this might seem minor, but it came within the frame of a much larger conversation I recently had with my colleagues and made me realize something very crucial about the way developers identify themselves, and more importantly how companies identify the kind of talent they are looking for.

A developer's relationship with the languages he uses is complex and deeply ingrained. I've thought of myself as a CFML developer for a long time, over twenty years. Before that, during the halcyon days of the internet, I was a Perl developer (I've been around a while, you see). The switch from Perl to CFML was easy; Perl is a complicated, unforgiving language, too flexible for its own good and pernicious in its varied ways of writing the same line of code. An old joke is, "how do you force a Perl developer into retirement? Give him another Perl developer's application to debug." CFML was easy to code in comparison.

But I digress.

Over time, I've become certified in CFML and a few other languages. ActionScript, for one (ah, Flash, I do not miss you), SQL and JavaScript, and learned many others and frameworks besides. I've also seen most of these languages derided and disregarded at various times, especially (perhaps even as viciously as Flash itself) JavaScript.

The foundation of the Mura Digital Experience Platform is like most other web-originated applications: HTML, CSS & Javascript. There have been more than a few iterations of technology and framework.

Oh, how JavaScript was loathed and feared in the late 2000's, browser-blocked and shunned, vilified as a curse to overworked processors, breached security and endless loops. Hated, it was.

We Were Talking About Mura?

Right. In this recent conversation with colleagues, the topic evolved into "what makes a Mura Developer", and we realized that there really was no such thing. Take me, for lack of a better example. I've been a Mura core developer for over seven years, and have worked with the platform for over a decade. The last two projects I worked on have been complex and larger-scale.

The first was the addition of the Scaffolder and Assembler to Mura's core functionality. Introduced in Mura 7.1, the Assembler allows site administrators to "assemble" Mura-native Objects using an intuitive interface. The Scaffolder allows admins to then manage the data for these Objects by automatically scaffolding out a form for creating, deleting or updating entries. The thing I found most amazing about this project is that I wrote it entirely, as in 100% entirely, in JavaScript (using the Vue framework for the front-end). I wrote not a single new server-side function, but relied entirely on the native functionality that already existed in Mura JS and the Mura JSON API.

The second project, which I am currently working on, is a native replacement to CKFinder, a tool for browsing and managing file assets within Mura. This project has almost entirely been written in JavaScript (Vue) once again, with perhaps 5-10% of the code server-side.

So, does this make me a JavaScript developer? A Mura developer? Neither, in fact. I am just a developer who specializes in web-type technologies.

How Did We Get Here?

The truth is, we developers have been this way for a long time. Our toolkit often starts out narrow, there are always certain languages that we lean towards initially, but as our experience grows, so too does the number of languages, frameworks, and technologies we use on a daily basis. The truth is, any developer who calls themselves a "this language" developer is likely doing themselves a disservice, or perhaps (if you'll forgive me) isn't trying hard enough.

Mura JS, in particular, has become a key part of Mura's roadmap.

Web development today is more complicated than ever, but at the same time, is much easier. There are many tools at our disposal, many frameworks, and it is our ability to learn these tools and apply our previous experience to new environments, that makes us professionals.

Mura Toolset

The foundation of the Mura Digital Experience Platform is like most other web-originated applications: HTML, CSS and Javascript. There have been more than a few iterations of technology and framework as we've evolved to the current version: HTML 5, CSS pre-compilers, and a number of Javascript libraries. 

Within that ecosystem, Mura has four primary interfaces into its core. Mura ORM, which is our auto-wiring server-side Object architecture; the JSON API, which is our self-describing remote interface; and Mura JS, our JavaScript framework that functions both as a jQuery-type DOM selector/manipulator and as a session-managed interface to the JSON API and remote-accessing framework (Mura JS exists as a separate Node project, for instance).

...a developer can access every single aspect of Mura, from content to users to file assets, all within a secure, authenticated, curated environment that is flexible enough to match any number of development experience backgrounds.

Mura JS, in particular, has become a key part of Mura's roadmap. Not only has it removed the possible conflict of version-conflicting libraries, but has also moved us internally towards a different style of development. Remote, client-side and asynchronous, to be specific.

Through these three toolsets, a developer can access every single aspect of Mura, from content to users to file assets, all within a secure, authenticated, curated environment that is flexible enough to match any number of development experience backgrounds.

Take, for instance, Feeds and Iterators. A Feed is essentially a Mura-type request for data, be it content, users, categories or permission groups. An Iterator is a mechanism for looping through the returned results. These two patterns contain all of the functionality a developer would need for managing this task (such as the number of records returned, pagination, request scope, and others).

Here is an example of a Feed request via the JSON API:

http://localhost:8080/index.cfm/_api/json/v1/getmura2/content?title=about

This example will return a set of content pages based upon the default parameters (i.e. the first 20 pages, sorted by most recently created).

Here is the same request via Mura JS (using promises, for context):

Mura.getFeed('content')
 .where().prop('title').isEQ('about')
.getQuery().
  .then(
    //success
    function(collection) {
          processContent(collection.getAll());
    },
    //fail
    function(response) {
          requestFailed(collection.getAll());
    }
  );
}

The content returned in both cases will depend upon the context they were called in (i.e. session and permissions). In both cases the data returned is identical, self-describing and well-informed:
 
{
                "data": {
                                "endindex": 7,
                                "startindex": 1,
                                "entityname": "content",
                                "totalpages": 1,
                                "totalitems": 7,
                                "links": {
                                                "entities": "http://localhost:8080/index.cfm/_api/json/v1/default",
                                                "self": "http://localhost:8080/index.cfm/_api/json/v1/getmura2/?&entityname=content&siteid=default&method=findall&pageIndex=1",
                                                "properties": "http://localhost:8080/index.cfm/_api/json/v1/getmura2/content/properties"
                                },
                                "itemsperpage": 20,
                                "items": […],
                                "pageindex": 1
                },
                "params": {
                                "entityname": "content",
                                "siteid": "default"
                },
                "method": "findAll",
                "apiversion": "v1"
}

Any experienced developer (with access to comprehensive documentation) should know instantly what to do with both of these functions, and how to work with the results, in short order.

You Said Four…

The fourth, and for us internally at BlueRiver, the least used interface into Mura, is CFML. This is the raw backbone that Mura was developed upon, but in truth, we use it far less frequently in our projects than in the past. The reason for this is simple: Mura has matured to the point that for nearly every task that needs to be performed in our Digital Experience Platform, a Mura-type function or pattern already exists to answer it (see above).

This isn't to say that we don't still appreciate the power and flexibility that CFML offers us, just that it is no longer *necessary* on a day-to-day basis.

In the case where a deeper level of integration or extension is needed, we certainly do appreciate its presence. For those of you who aren't familiar with the language, here is brief peek at some typical CFML code, beside a set of similarly functioning JavaScript:

The example on the left is JavaScript, and the right, CFML. If you know Javascript, you'll see that the only definable difference between them is that CFML (and please don't get me started on this) iterates from one (1), instead of zero (0). Other than that, they are identical, and you will find this similarity extends into much more complicated examples with similar results.

At Blueriver, when we look to hire, we rarely advertise for or seek a particular coding skill set. What we are looking for is people with experience, an interest in learning and a passion for the craft.

Why is this important? Well, it goes back to my original point that, there is no such thing as an "X" developer. If you currently identify as a Javascript developer, you are already so far along the way to also being a CFML developer that the difference is mostly trivial.

In other words, because the differences in style and format are infinitesimal, they are inconsequential to a professional developer. Knowing one provides a huge platform of understanding for learning the other. This isn't to say they perform in the same way or have identical functions/methodologies; this cannot be, because they are fundamentally different in intent, environment, and purpose. 

The key point here is that any professional developer with decent documentation will walk through these differences without difficulty, will move from knowing one language to learning the other with practiced ease.

There is no such thing as a Mura Developer

So, we are back to where we started, me accepting that I am not a JavaScript developer or CFML developer or Mura developer, simply a developer.

At Blueriver, when we look to hire, we rarely advertise for or seek a particular coding skill set. What we are looking for is people with experience, an interest in learning and a passion for the craft. We are looking for these types of people because we ourselves are constantly learning new technologies as the web adapts and grows in new and unexpected ways. JavaScript, once reviled, has become the cornerstone of current web development. Applications like Node, frameworks like Ember, React and Vue, have made it so.

Other languages like Ruby on Rails were ultra hot once, but are less so now. The industry evolves. Technologies like Git, Docker, Buddy.Works and others have and will continue to transform the way we look at development and deployment.

Being a professional developer means that you are constantly evolving, expanding your toolkit, learning new ways of solving old problems, adapting to the ever-changing landscape of web technology. There is no "one-language" developer anymore, no singular experience.

Embrace it, find good people, and you will do great things. It has certainly worked for us!