Monday, July 25, 2016

Gentlemen! (m/f) – Restart your View Engines!

Take real advantage of the MVC pattern and step, with me, outside of the box for a minute.

So here’s the thing. I’ve been doing Sitecore implementations for over 10 years now. And for all of those 10 years, part of my job has been – to some extent – taking front end assets (HTML, JS and whatnot) delivered to “the project” by either an external agency or internal team and work it into the Sitecore solution.

You all know the deal; you take these HTML files, you break them into their component parts by chasing down <DIV> elements. Lately, you may have noticed that you often get the HTML delivered in part like this already – so broken down “library” snippets of HTML. Be that as it may, you still end up having to “Sitecoreify” this into your solution.

You replace the static text and images with Sitecore Controls (if you’re still stuck with Webforms) or maybe Sitecore Razor helpers (@Html().Sitecore.Field(“Headline”)). Or maybe you’re using Glass to wiff things up a bit, or perhaps you’re in the same camp as I am, believing the Razor view should depend on nothing but the model – so you end up with code like FieldRender.Render() into your model properties.

Whatever your approach, I think we’ve all been down one or more of these roads.

What If I Told You - what if I told you All of that work is obsolete

Yep. Morpheus isn’t wrong. I’ll elaborate.

What if I told you – you could achieve all of this:

  • Never mess around with another View file again. You’re a Sitecore rockstar, why would you be spending your time on trying to inject “col-md-40” class attributes into frontend elements when you could be spending your time on better eXperience Editor support?
  • Not to mention; having to inject class attributes based on back-end functionality and data just feels oh so n-tier-wrong to begin with.
  • Remove anywhere from 20% to 50% of your Sitecore project implementation time.
  • Remove anywhere from 20% to 50% of your Sitecore project implementation time. I repeated this on purpose. Try measuring your own time, spent on fiddling with views.
  • Achieve complete separation of frontend and backend parts of your project. The “No man’s land” that currently exists somewhere in the .cshtml space can be eliminated.
  • Your frontend developers would never need to leave their OSX Macbooks and boot up Windows.
  • Get people working on what they do best; instead of having to require people on your team with skillsets that look like this:
    • Must know c#, javascript, handlebars, Sitecore, SQL, SQL Replication, MongoDB, SOLR, Lucene, ASP.NET MVC, CSS, Responsive Design, Photoshop, NodeJS, jQuery, jQuery UI, Bootstrap, Knockout and how to fish.
  • When instead these concerns should be (and almost without exception always are, in the real world) separated:
    • C#, Sitecore, ASP.NET MVC (Sitecore Developers)
    • Javascript, Handlebars, CSS, Responsive Design, NodeJS, jQuery, jQuery UI, Bootstrap, Knockout (Frontend Developers)
    • SQL, SQL Replication, MongoDB, SOLR, Lucene (Application Engineers)
    • Who fishes, anyway?
  • Get “backend” developers (Sitecore) working on what they do best. Model Sitecore, set up IA, implement features – present it all in the form of Models. (M).
  • Get “frontend” developers working on what they do best. Handlebars, frontify, node, SASS and so on – anything and everything that runs on the client – and feed their Views (V) with a mock of the Model (M).
  • Connect the two worlds with Controllers to render the final results server-side and send it off to whatever client happens to be connected (C).

Have I got your attention yet?

This is how we do-o-o it

Admit it, I now managed to get that song spinning in your mind. Don’t worry, it will go away in a couple of hours ;-)

So yea. The technology exists. I’ve been hinting at it for a while, some documentation and explanation effort is underway. I hope to find time to aid in some of this documentation and explanation effort as well – but for right here and now, my aim for this post is just to serve as an eye opener, thought provoker, and see if I can get a bit more community engagement going.

What I’m on about is NitroNet for Sitecore.

NitroNet for Sitecore in less than 5 minutes.

Don’t worry if most (or all) of the below Open Source projects I mention now are completely unknown to you. If you are like me, you probably know as little about the whole frontend developer stack as you can get away with – and it is exactly this stack that NitroNet for Sitecore aims to bridge the gap to. Stay with me.

NitroNet for Sitecore is an extension to NitroNet. It adds Sitecore concepts to the stack, in form of placeholders, eXperience Editor support and so on.

What is NitroNet?

NitroNet is an ASP.NET MVC View Engine that replaces Razor. It parses Handlebars.js templates (server side), based on OS code from TerrificNet and Chris Sainty’s Veil Engine.

So in simpletalk: NitroNet replaces Razor to do Handlebars server side instead of Razor Views.

(but you can still use Razor Views, should you need to)

NitroNet is the server side component for Nitro.

What is Nitro?

Frontend developer framework. I’m actually not being vague intentionally here, I simply don’t know all that many details LOL :D  But that’s the beauty here; I don’t need to know all that much about frontend – and I like it like that.

So here’s a few highlights. And remember; this stack is all your frontend developers will need to worry themselves about. They don’t need Windows, they don’t need a local Sitecore running.

  • 100% file based
  • Runs on Mac, Win and Linux (and who knows, maybe more)
  • Encourages Atomic Design and BEM concepts
  • Comes with its own lightweight web server

So essentially, frontend developers will be “doing their thing” on their beloved Macbooks, developing components using Atomic Design/BEM via Handlebars, running and testing it locally and when they’re done they will even tell you (the Sitecore developer) what the model they require, looks like. All you need to do, is deliver it.

Take a look here, for more information. Better yet, point your resident frontend developer team in this direction and hear their thoughts: https://github.com/namics/generator-nitro/blob/master/app/templates/project/docs/nitro.md

So ummm….

Yea I know. Scope of this goes a little beyond “should we use this or that Dynamic Placeholder solution in our project?”.

I tell you this though; this is what real architecture looks like. In my view. Separation of frontend and backend concerns is key for a list of reasons so long, I wouldn’t even know where to begin. I challenge you to consider these things:

  • Having your frontend and backend developers being able to work in complete parallel – all they need to discuss early on, is the Model.
  • Having your frontend developers work on their tools and platform of choice, not needing to get them running Sitecore locally or even boot up Windows.
  • This goes for post go-live changes too. If the model doesn’t change, no Sitecore resource need even be involved in a fix.
  • 100% file based JSON models also means, you could hook into the Sitecore PathFinder project and possibly get your Sitecore templates, Rendering items and so on auto-generated. I’ll gladly get involved if a community effort is kicked up around this.
  • Completely removing the need for Sitecore developers to fiddle around with view files, hiding HTML blocks, injecting attributes, wasting their time. Sitecore devs don’t really come cheap, nor in particular abundance.

So yea. The scope of this certainly promises more than adequate ROI. I encourage you to verify my claim on this :-)

Quick list of links and references:

Start your engines!

Posted by at No comments:
Subscribe to: Posts (Atom)