This article is about a journey that started in the early 1970s, that has no itinerary and no foreseeable end.
The Journey Starts
The first microcomputers were powered by primitive microprocessor chips that initially could only be programmed using numbers, and each type used different numbers. So in a Motorola 6800 from 1975, the codes
86 0d
were an instruction to put a carriage-return character into the A accumulator, but the same codes meant something completely different - or nothing at all - to a Zilog Z-80. We also had assembly language, which was the same thing but with the numbers replaced by letter codes for the benefit of human beings, and where the same instruction was
lda a 0x0d
In those days 4 kilobytes was a lot of memory so programs had to be short and efficient. They were usually written in assembler. High-level language compilers need a lot of memory so they ran on larger machines, but these were difficult and expensive for ordinary people to access. Which didn't really matter because few people had microcomputers at home.
As the cost of memory fell it became practical to have more of it, and by the end of the 1970s, 8-bit computers were appearing with a full complement of 64k bytes of memory, enough to even run a high-level language. This really marked the start of the computer revolution as it became possible to write application programs on the computer itself, and here mass-market software was born.
The computer revolution
The next decade saw the introduction of the home computer, the IBM PC, the Macintosh and the main kinds of computer software we are now all familiar with; word processors, spreadsheets and operating systems. But the next major port of call on the journey came at the end of the 1980s, with the birth of the World Wide Web. For the first time it was now possible to connect home computers to the Internet, which up until then had been a tool for universities, military and industry.
More than the Web itself it was the browser that really changed things. For here was an application that of itself did nothing but relied on content to be provided by the Internet. In order to process that content the browser had a fixed program that transformed HTML codes into web pages in front of your eyes. The only interactivity on offer was hyperlinks, which caused a request for a new page to be sent to the server, but before long the browser code was being enhanced to do more in this area, and in the mid-1990s the first browser programming languages arrived in the form of VBScript and JavaScript. The second of these turned out to be the more popular, and since then JavaScript has been the sole choice for browser programming.
For nearly two decades, applications were programs you installed on your computer and the browser was there to give you the means to download them. But as the speed of the Internet increased it became practical for applications to download and run in the browser. The advantage was obvious; nothing to install or update, just run it. Anywhere.
The majority of these applications were still self-contained, though; once loaded they had little to do with the Internet itself. But with continued increasing Internet speed and reliability, a browser application could begin to operate seamlessly across the Net, distributing itself in any way that suited it best. We had arrived at the Web App.
Right now we're seeing the slow decline of the installed application, as more and more is done with web apps. Some personal computers, such as ChromeBooks, don't even offer the means to install applications; everything is done with the browser. This process is mid-way so we cannot see where it's headed; all we can do is guess. But my guess is that in the end nearly everything will be done with a browser, rendering even the operating system redundant or relegated to being just a core component of the browser.
Web apps
So where are web apps - and application software development in general - going? At present the only language browsers understand is JavaScript, a language famous for being able to do everything you need, famous also for having half a dozen different ways of doing any one thing and notorious for being able to screw up royally if given half a chance.
To get round this and bring some semblance of order, a plethora of tools and frameworks have been developed, starting with JQuery then Bootstrap, Angular, React, Vue and many more. Most of these add to JavaScript rather than replace anything, though JQuery is a little special as it offers alternative, simpler and more consistent ways of doing common things. In that respect it's more like a slightly higher level language built atop JavaScript.
One of the things a framework also does - JQuery quite well, the others less so - is bring a measure of order to the chaos that underlies much of JavaScript. Every feature that was ever in the language is still there, because of the need to go on supporting decades-old websites. Each time a new feature is added a strange and wonderful new syntax is dreamt up - fat arrows and triple-equals, for example. There's no question it works, but at the price of making the language ever harder to learn and master. Hence the jokey assertion "You Don't Know JS". Nobody does.
The current craze for devising new frameworks represents just a step in the journey. All of the current frameworks share a common problem, that they are complex and hard to learn, which means only experienced programmers can use them properly. Worse, they seem to have a limited life before they are overtaken by something new and more fashionable. (This would have happened to JavaScript itself were it not for the need to update every browser in the world to add a new language.) Websites, on the other hand, have a long life, in many cases requiring maintenance for well over a decade. It should be obvious that finding skilled programmers to maintain a framework that became unfashionable half a decade ago is not going to be either easy or cheap.
I don't wish to suggest that frameworks are a bad thing, but in their current form they are overly complex when it comes to expressing the somewhat random logic the customer is interested in, where the system meets the user in an arbitrary and frequently-changing set of business rules. Everything has its place, and where frameworks excel is in building stable, self-contained components that require little maintenance and interact with the rest of the system through well-defined interfaces. To go from there to assert the entire system should be managed the same way is a mistake. It may work for Facebook but few of us work with a thousand other engineers, build sites of that nature or have to maintain them.
For now we are seeing a steady increase in performance without any fundamental change to the way it's used. There are few web apps that truly test the performance of JavaScript. Even Google Maps, which to me still represents magic and witchcraft, runs on any smartphone. We have performance to spare and we will see another stage of the journey; of that I am certain. What it will look like we can only guess. It may be more than one thing. Perhaps AI will help us build and maintain applications, but that's likely to come much later on in the journey.
Put together the increase in performance and the rise in complexity and we have an opportunity. It's possible to have another layer on top of JavaScript that removes all need to use the complex, hard to understand underlying code, replacing it instead with something simpler. By which I don't mean less capable but able to do more with each instruction. JQuery was a small step in the right direction but if you look back on the journey you'll see we've been here before.
Insanely great
In the mid 1980s, users of the revolutionary Macintosh computer could run a program called HyperCard, a combination of flat database, graphical system and programming language, the latter being called HyperTalk. Years before the Web entered the scene, HyperCard/HyperTalk excelled in being able to create flexible user interfaces that were easy to understand and maintain. It's like it was born before its time. Users with little or no computer training could build sophisticated "stacks", as they were called - interactive graphical database applications - to meet a host of needs. Just like web apps, but without the connectivity.
HyperTalk was designed to look as much as possible like English, so you could write
put the first character of the third word of line 5 of card field "sometext" into theChar
which requires no computer training at all to understand. The system was so exceptional that it earned the epithet "Insanely great"; praise the likes of which I've not heard applied to anything else in the intervening 3 decades and more.
Code like this is close to what we write when asked how something should work. It's readable by domain experts as well as programmers and I have yet to come across a web page whose appearance and behavior could not be described using language of this kind. Complex functional blocks like Google Maps can be included as packaged components with their own simple operating keywords, leaving the appearance and behavior of the page understandable by all and the question "why do it any other way?" hanging in the air.
JavaScript may be the only language understood by browsers but it's now powerful enough to act as an assembly language with which we can code higher-level languages that behave like native code. This is really the only way we'll break out of the endless cycle of increasing complexity and achieve better productivity.
My time using HyperTalk left such an indelible impression with me that for over 20 years I've been writing scripting languages that seek to emulate it, and last year I coded my first one in JavaScript. Since then I've been using it to build websites while trying to persuade others to consider adopting the technology to handle the business logic of their own pages. I'll shortly publish a series of articles on how it can be used to build a Web App.
Thank you for staying with me. If you are interested to know what a high-level browser scripting language looks like, head over to EasyCoder.
Title photo by Florian Olivo on Unsplash
Oldest comments (6)
Great article, I discovered HyperTalk thanks to you, and I think this is where the web development, but also programing in a general manner, should go.
Did you published a version of your HyperTalk emulator? I would be glad to try it!
Hi!
Thanks for your encouraging comments. Sometimes it gets a bit lonely doing things differently to everyone else.
I'd be reluctant to call EasyCoder a HyperTalk emulator - far from me to put myself in the same league as Bill Atkinson. What I've done is apply some of the same principles.
EasyCoder is not a stand-alone product; it's a plugin for WordPress, so to use it you'll need to set up a website. My next articles will explain how to do this.
There's a lot of information on the EasyCoder website and all the code is on GitHub. I'm quite happy to answer as many questions as you'd like to ask; my preferred eventual means of communication is Slack as it lets any number of people join in.
BTW, if you really want a stand-alone HyperTalk emulator (as opposed to a web solution) there are products like Revolution and LiveCode that were also inspired by the same great forerunner.
I like your perspective. Thanks for the post!
There are still many low-latency high-throughput applications that the web is fundamentally poorly suited for. For example, multitrack audio recording, where 10msec latency is unacceptable, really needs to run locally. Running locally doesn't necessarily exclude the browser as a platform, though. Do expect these types of mostly non-web applications to move to the browser platform as well, just following the trend?
I think I made it as a throwaway comment, but now I look again and yes, it's certainly a possibility. After all, do we really care what the operating system is or what it's doing as long as it delivers the goods?
Actually you can do a lot of work in 10ms, even in JavaScript. The latency of the OS is a lot more of an issue, whether the app is browser based or a non-web application. Recordings have to go somewhere, data is written in large blocks and most systems are only designed for human perception of latency.
Moving the OS into the 'browser' (which can't really be called that in such a scenario) blurs the line between OS and App so I wouldn't rule out functionally real-time performance being possible. How far forward am I permitted to look?
The concept of a "computer" may itself be only temporary. Some Facebook users think they don't use the Internet; in their minds they've bought a single-purpose appliance. This effective reductio ad absurdum leads to various different types of single-purpose machine, each being a different build of a common platform. Who knows?
Nice post!
I remember HyperCard, it was really my first intro into doing something with my old mac, other than drawing pictures.
I totally agree with your points of view and have really enjoyed your perspective.
Javascript is really become more confusing and the more people are jumping on board, the more ‘frameworks and tools’ are being thrown into the pool.
But I have for a while now thought that the ultimate solution would be something completely new and removed from the old way of doing things, not mere an evolution of the previous.
Thank you. Your comment and those of the others are encouraging me to continue a little further along the same lines. There's no shortage of technically-oriented articles on software engineering so I try to apply some balance by placing more emphasis on the human side of things.
My concern is particularly that too many people with lesser technical skills (among whom I number myself) are being excluded from contributing at a time when there is a vast and growing amount to be done. The reactions I'm getting to my articles help dispell the fear that I'm just wasting the time of professionals by writing about things the way I do.