Two blogs ago I wrote about how technology waves come about, the stages they all go through, and the benefits and risks that come from when you choose or how you choose to ride a particular wave. Then, in my last blog I described what I see as the four generational waves in legislative information technology – starting with the mainframe era in the 1980s, the office productivity era of the 1990’s, the XML era of the 2000s, and the current standards wave starting in the 2010’s.
So what comes next? Will it be an extension of the current technology wave or will it define a new wave altogether?
The Web-Inspired Platform Wave
Web-based computing has been changing rapidly over the past few years. One thing I have noticed is that it has become much easier to build complex systems. Part of the reason for this is that everything is becoming much more integrated – and much more consistent. I think the ultimate result of this is that all the things that have acted to divide computing up in the past will start to give way to solutions that will instead unify the computing landscape.
First, as I said in my last blog, I believe that the era of the proprietary technology stacks will soon come to an end – it’s just not where the action is anymore and hasn’t been for quite some time. What the proprietary technology stacks have provided in the past is stability – something to build upon for the long haul. However, standards can play the same role – ensuring an evolutionary path forward without the churn and chaos that comes from one bright and shiny idea replacing the last bright and shiny idea every few months.
Second, I think that there just has to be a blurring of the computing platforms. Today there is Windows, MacOS, IOS, Android, Linux and so on. Nobody tries to build a new application for each platform anymore – it’s just not practical. Instead, web-based applications are built that will run in a browser on any of those platforms. However, the web browser isn’t the best place to host an application. Security limitations make some things impossible – like accessing local resources, overloading key definitions, and so on. The document nature of the web browser isn’t always a good fit for every application. Without the commonality of a user interface design language coming from the operating system, web-based applications tend to be all over the map, usability wise.
The fix for this is that the technologies that comprise the browser are slowly being restructured to produce a web-centric application development platform rather than forcing every application to become a website. You can already see this approach coming about with the Electron platform – used by Slack, CrashPlan, Visual Studio Code, GitKraken, and even Xcential’s LegisPro. Maybe Electron won’t be the be all and end all of this approach, but it points to the future – one in which the role of the desktop is resurgent, but this time unified across platforms by standards-based technologies that originated in the browser. (Remember Microsoft’s active desktop plans in the 1980’s – it was the right idea, but Microsoft’s embrace and ambition to dominate mindset undermined it)
Third, I think that the distinction between building client- and server-based systems will continue to blur. I remember when there were client- and server-based applications. Then came a middle tier which quickly turned into n-tier. Now with the development of technologies like Node.js and isomorphic JavaScript, there is little reason why a component or a service can’t just run wherever it is needed without the need to formally place it in one tier or another.
Fourth, I think that the era of JavaScript will come to an end. Don’t get me wrong – I’ve gone out of my way to get to a unified development platform based largely around JavaScript. But JavaScript heritage as a simple browser scripting language and the tortured path it has taken to become more than that hurts it. It’s a bit of a convoluted mess. The new class mechanism is welcome, but too simplistic. JavaScript’s scoping rules can be unfathomable. JavaScript’s limitations such as the lack of type checking and all the attempts to remedy them create a babel of language variants (yes, I know that babel is a transpiler to compile from one version of JavaScript to another – the name is ironic). Ultimately, a new rethought language is going to be needed. Perhaps WebAssembly will be the enabler that allows for a new, more elegant development language without the need to always map to quirky old JavaScript.
Fifth, as we achieve a critical mass of capabilities built upon a stable computing platform, there are many new technologies we can start to exploit that have been research topics or pipe dreams up to this point. Already we’re starting to look at machine learning for processing text to deal with the difficulties of converting legacy paper-based data into modern digital information and to interpret the meaning behind legislative language, particularly as it relates to amending.
Data interoperability is another area that will grow in importance, particularly in areas such as regulatory compliance where the cost-benefit of increased automation is so easy to make.
I think where this is all headed is that we will eventually get to a point where the digital age is so entrenched that the paper representation of legislative information becomes irrelevant. When this happens, we will start to drop many of the paper-oriented paradigms that have made legislative automation so difficult. I’m thinking about page and line numbers, numerous strict print formatting rules, and all the document-centric lifecycle procedures that have been put in place over the centuries where paper was the dominant medium. I saw this happen once before – in my previous world of Eletronic Design Automation (EDA). What started as a very slow change away from draftsman producing paper schematics to support the engineers suddenly gave way to a sea change as the benefits of the digital age became realized. Today engineers work in a totally different way, describing the hardware they’re designing using sophisticated languages and without schematics ever even being produced. They wouldn’t dream of having it any other way — it’s just not practical anymore.
