Geek out a bit
Seriously? You're here?
All right then. I suppose I should write something.
Seriously though, I'm pretty stoked and totally geeking out over the tool suite we've put together. Part of it is the time it will save myself and others and part is because of the thoughts, concepts, and philosophical underpinnings that went into building it.
If you've been following my (Josh) writing at all over the last little while you've probably seen me point to a talk by Sean Parent on A possible future of software development. In this hour long talk Sean touches on two things that forever changed the way I wanted to approach anything remotely close to software development: generic programming and directed acyclic graphs.
Forgoing whether or not I actually understood what Sean was talking about I felt I had discovered my Yoda. For years leading up to this talk I had been that developer. You know the one, always complaining about the inelegance of other people's code and completely not seeing the flaws in my own. (Boy, glad those days are behind me for the most part.) Anyway, I had been talking about how a computer should not have defects…no really, no software application should have a defect—literally impossible.
It's like math. X + Y = Z…every time. If you click a button, you get a response, every time. For a few years I worked my little developer fingertips off figuring out ways to get there:
- Minimize mutable state.
- Minimize use of global state.
- Minimize how much global affairs could touch some process.
- Create functions that did what was expected, every time, no matter the combination of arguments.
- Create functions that did one thing, and make that thing as small as was logical or possible.
Then, as with a lot of my fledgling ideas, I was introduced to the people who had pretty much been writing the book on the subject and coming to the same conclusions; namely, functional programmers.
There are so many reasons I'm jazzed about this kit. (Here comes the geeking out part.)
It's stateless. You can't instantiate anything. Even if you did, all the functions are static and you couldn't call them from those instances in a productive way.
It's lazy. Nothing boots up before necessary and the only thing that sticks around from one step to the next is your configuration. It's like a roughen stone going through a polishing process.
It's primitive. No library dependencies. No framework dependencies. Just pure PHP (except for that one JSON file, but I couldn't find a tool that would output a PHP array of all the countries in the world and I certainly wasn't about to write one by hand). Not only that but it all goes back to a single core method to generate the output; every point before then is just polishing the stone—that final method makes your jewel, just as you asked for it.
It's fast. Don't misunderstand, we are being helped a great deal by PHP7 and it's new Zend engine. We are also using a base framework that may or may not be caching some things. But each page is being generated primarily by the kit and the time to first paint (the point when you get to see or interact with something) is less than two seconds for most pages (on broadband…and LTE). (We still have a couple of rough spots on mobile.) One of the biggest complaints I've heard regarding the web is that it's too slow—even on broadband. We spent way too long figuring out ways to make things faster for dial-up users for the problem to be the platform…I say it's not the Internet, it's our code; or, to be more blunt, the problem is us.
What Markdown did for writing content for the web, the kit does for creating user interfaces; it removes the markup until it's called for. Just like Markdown allowed web authors to focus on writing the content they cared about, the kit allows developers to write the code they care about. Namely, those parts unique and necessary to your application or the experience in front of you instead of all the tag names, nested elements, classes and other attributes (don't forget the HTML specification).
It's readable. I'm a big proponent of self-documenting code. In the case of 8fold Elements the architecture of the code is literally based on documentation (the HTML specification), reading the element classes in that library is almost a one-to-one match of the HTML specification. Not only that, but in most cases the code you write to interface with the kit is self-documenting as well. Take a text input component, for example. Your technical lead has asked you to change the hint text of that component, find it in the following examples.
Without the kit:
<div> <label for="text_input_1">Text input</label> <span id="text_input_1-hint-text" class="ef-form-hint">Some helpful text.</span> <input id="text_input_1" name="text_input_1" aria-describedby="text_input_1-hint-text"> </div>
Not too difficult, but coming in as a fresh developer to this codebase you really have to sift out the parts that don't really matter.
With the kit:
UIKit::textinput([ 'label' => 'Text input', 'hint' => 'Some helpful text.', 'name' => 'text_input_1' ])
Readable rating just went up quite a bit. The code reads something like the following:
Hey, UIKit! Give me a text input with a label that says, "Text input"; a hint that says, "Some helpful text."; with a name of "text_input_1".
Don't get me wrong. This isn't about being unique or getting to yell "First!" because we're neither of those. Not by a long shot. There are a lot of frameworks with data models linked to view generation (most client-side frameworks these days, in fact). This might be the first time I've seen it this extensively in a server-side language and I have never seen a library that would do the entire HTML specification but, again, this write-up is mainly just about being stoked to have developed it in the first place—and to have it work better than anticipated.
As I was wrapping up the first go of the 8fold UI site I would sometimes hit a snag. I would, almost out of habit, start thinking it was something buried in the lower-levels of the code. But, inevitably, after 10 or 15 minutes looking at 8fold Elements or even 8fold Component I would say to myself, "You probably just missed something, go back to the kit and try again" and, when I followed my own advice 99.9% of the time I had missed something, I made a minor change (commas are the enemy), and it just worked. I have to say the developer part of me is experiencing a wonderful feeling. The feeling of having that level of stability in something.
Of course, in a year or two, who knows? I might look back and say, "What was I thinking!?" But, I will always have the learning and the higher level concepts.