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.
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 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.
...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:
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):
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:
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.
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.
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.
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.
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!