Announcing Classic Computer Science Problems in Python

I am pleased to announce the availability of my third book, Classic Computer Science Problems in Python. Starting today, you can purchase early access to the book from Manning. Use promo code mlkopec2 for 50% off through August 3rd, 2018. I have completed drafts of the first four of nine chapters, three of which are available today from Manning, with the next three to follow over the summer. The final version of the book will arrive in Fall 2018. The book requires Python 3.7 and makes extensive use of type hints.

Classic Computer Science Problems in Python is a great “second book on Python.” It is aimed at those with some basic knowledge of Python’s syntax who want to delve deeper into the covered problem solving techniques, brush up on core algorithms, or learn more Python using problems familiar to them from other languages. It is suitable for professionals looking to deepen their understanding of the covered topics, students with some programming background looking to expand their computer science knowledge, and anyone preparing for coding interviews.

What is a “Classic Computer Science Problem?” It is a problem one typically finds in an undergraduate computer science curriculum. The topics covered in the book span the gamut from core computer science algorithms you would find in a data structures & algorithms class to artificial intelligence and its sub-discipline machine learning. There are both practical and whimsical problems. They include classic search problems, constraint satisfaction problems, graph algorithms, genetic algorithms, k-means clustering, simple neural networks, and more!

All of the code in the book is available on GitHub. The book takes advantage of the latest features in Python 3.7 like dataclasses and improved support for type hints. The code only uses the Python standard library throughout (with the small exception of the typing_extensions package for improved type hints), so there’s no wrestling with third-party libraries. You will learn how to solve all of the problems in the book “from scratch” so that you gain a deeper understanding of how each problem solving technique works under-the-hood.

To learn more, checkout the Classic Computer Science Problems in Python page on Manning’s website where you will find a full table of contents and free access to the Introduction and Chapter 1 (Small Problems). If the table of contents looks appealing to you, dive in with promo code mlkopec2 which will give you 50% off through August 3rd!

This is the second book in the Classic Computer Science Problems series. If the contents of the book interests you, and you are a Swift developer, you may want to checkout the prior book, Classic Computer Science Problems in Swift. The two books have similar contents, but in the Python book we are careful to write our code in a Pythonic way, whereas in the Swift book we made every effort to solve each problem in a Swifty way… For example, whereas in the Swift book you’ll find protocol-oriented programming in the fourth chapter (Graph Problems), in the Python book you’ll find extensive use of object-oriented patterns, first-class functions, decorators, and new Python features like dataclasses.

Remember that you are purchasing a pre-release version of the book, so you will be joining me on the journey to its final release in the fall. You will be receiving rough drafts of chapters before they have been fully developed. I encourage you to send me your feedback, but keep-in mind that these are early days and everything is not yet perfect. You will receive the final version of the book upon publication.

Posted in , , , , , , , , | Leave a comment

History of Web Programming (2014)

2018 Note
This is Appendix B from my 2014 book, Dart for Absolute Beginners. Like the rest of the book, it’s now a little outdated. It misses the developments of the past 4 years—notably the rise of large client-side JavaScript frameworks (Angular, React, etc.) and the failure of Dart to conquer the world as a client-side Web technology. It’s still, I think, pretty good reading, a decent summary of the history, and interesting in terms of what it got right and wrong about trends. Any mistakes are my own and/or a result of conversion to Markdown for this blog. If you like my writing, you may enjoy my new book, Classic Computer Science Problems in Swift which you can get for 40% off with code kopec40 on
History of Web Programming

Author's Note: This appendix is not meant to be reference quality material. It contains speculation, suppositions, and opinion. The technologies/programming languages mentioned were built by incredibly smart and dedicated people who did not have the foresight of twenty-five years of the Web that we have today. Any slights pointed towards them must be read with that context in mind.

To fully appreciate Dart's place in the Web development ecosystem and its purpose, it's necessary to understand a little bit about where that ecosystem has come from. This appendix is not about Dart – it's about what led up to Dart. It's about the languages that have been used for programming the Web throughout its history.


In the beginning, the Web was static. A page was downloaded and it didn't change. When Tim Berners-Lee released the first web browser in 1990, web pages consisted of text with a little styling, and links to other web pages. It was a web of information – not of interactivity. One has to remember the technology of the time. A cutting edge microprocessor in 1990 operated at 50 megahertz and the average personal computer had a few megabytes of RAM. The speed of computers has improved exponentially since then.

Over time the technologies available in web browsers for content presentation became more impressive. Images were added. The ability to play sounds was added. Browsers included the ability to extend themselves with plug-ins. CSS was introduced to improve styling. New HTML tags were introduced to improve layout.

Even as web pages became prettier, they still lacked the capabilities of native applications. Web browsers were in essence HTML document viewers. They lacked the ability to respond to users in any kind of dynamic way. In order for the Web to become a platform that could compete as a venue for interactive applications, client-side browser programming languages were developed.

Java Applets

Java 1.0 was released in 1995 by Sun Microsystems[1] and it made a big splash. It promised to be a new, memory-safe, secure, object-oriented, platform-independent programming language/software runtime with familiar syntax. A cool aspect of the new language/platform were so-called applets. Java applets are Java programs that run with a graphical user interface in a pre-defined rectangle on a web page.

The promise of Java applets was that programs could be written once and run on any platform that had a Java runtime environment and a web browser. This write once, run anywhere philosophy, aimed to make the distinction between running a program on a Mac versus on Windows irrelevant (or on a Unix workstation). Netscape Navigator was the first web browser to support Java applets.

The reality in the late 1990s was that Java applets were slow to load, had inconsistent user interfaces, and suffered from incompatibilities after Microsoft bundled its own Java runtime environment with Internet Explorer (a lawsuit was fought over this) that had subtle differences from that deployed by Sun. Java applets can still be run today on any web browser with a Java plug-in but they're becoming increasingly rare. The lack of support for Java applets on mobile platforms like iOS has sped along their demise.


The introduction of JavaScript happened practically in parallel with that of Java applets. JavaScript also launched in 1995 and Netscape Navigator was also the first web browser to ship with it. Indeed, JavaScript was the creation of Brendan Eich, a Netscape employee, and the story goes that he designed the whole language in ten days. JavaScript was not originally meant to be used for the same kind of applications as Java applets. It was supposed to be a lightweight scripting language. There had been previous attempts at providing scripting languages in a web browser but none of them had the backing of a major player like Netscape or Microsoft until JavaScript. The name JavaScript was a marketing ploy to take advantage of the hype around Java.

JavaScript was standardized as ECMAScript by Ecma International. JavaScript was popular enough that Microsoft incorporated a slightly modified version of it in Internet Explorer the following year. The incompatibilities between Microsoft's version of JavaScript and Netscape's version, despite the ECMAScript standard, would plague web developers to this day.

While JavaScript quickly gained popularity, for the first decade of its life it was utilized almost exclusively for what we would consider today to be quite small use cases. A major reason for this was its speed (or lack thereof). The original JavaScript engines were interpreted. It wasn't until the 2000s that JavaScript engines commonly included a Just-in-Time Compiler (JIT).

Over the past decade, as the speed of JavaScript engines increased, its features expanded, and its compatibility across browsers improved, it began to be used for increasingly significant applications. Browser apps increased in complexity to the point where they rivaled native software. JavaScript also increasingly became popular on the server (see below in Server-Side).

Today, JavaScript is the lingua-franca of the Web. There are very few, if any, of the most popular websites in the world that are not powered largely by JavaScript on the client-side. By any measure JavaScript is one of the most popular programming languages in existence. For a little more on JavaScript from a technical standpoint, checkout Chapter 17's section on it.


Microsoft once had a tendency to leverage its near monopoly status in the industry to push proprietary technologies that would encourage platform lock-in. VBScript was arguably one such proprietary technology. Added to Internet Explorer in 1996 as a kind of answer to/Microsoft eco-system alternative to JavaScript, VBScript leveraged the Visual Basic name in a similar fashion to JavaScript leveraging Java's brand (in name only).

VBScript attempted to fill a similar nitch to JavaScript-that being a lightweight scripting language for making web pages more interactive. Due to its proprietary nature however, websites with VBScript could not function properly in non-Microsoft web browsers. This was okay for a while, when Internet Explorer had around 90% marketshare in the early 2000s, however proprietary technologies are considered antithetical to the ideals of the open Web.

VBScript lost out to JavaScript but found its way into some other Microsoft products. As of Internet Explorer 11, it has been deprecated as scripting language for the web browser[2]. Although it hasn't been a real player on the Web for over a decade, many will still say good-riddance to the proprietary Web.


Flash is a platform for interactive content that is most commonly used for games and streaming video. It actually extends beyond the Web, but we’ll keep our discussion limited to the Flash web browser plugin. Flash was originally developed in the 1990s by several different companies before coming under the guise of Adobe after its 2005 acquisition of Macromedia. Flash is programmed with the ActionScript language. Interestingly, ActionScript is derived from ECMAScript, the same standard as JavaScript.

In a world where Java applets were too slow loading, and JavaScript was too unsophisticated, Flash came to dominate the niche of web-delivered richly interactive experiences. The Flash browser plugin was at one point installed on over 90% of web browsers and commonly came bundled with new computers. Flash was everywhere.

Flash’s big challenger came in the form of improved JavaScript engines and APIs. The smartphone revolution rendered another blow to Flash as mobile web browsers didn’t include plugin support, most famously the original iPhone. Steve Jobs wrote an open letter in 2010 criticizing Flash as a proprietary, legacy technology who’s time had passed[3]. The letter was controversial, but ultimately signaled a shift in the industry away from Flash and towards HTML5 and JavaScript technologies.

However, Flash is still the main language used for Web games and streaming video on laptop and desktop web browsers. There are JavaScript and HTML5 technologies that are making inroads, but the Flash plugin will likely still be with us for years to come. With that said, it’s probably not a good idea to develop new Web applications in Flash.


Silverlight is another Microsoft technology that was seemingly developed as an answer to an industry de-facto standard. As VBScript was an answer to JavaScript, Silveright was an answer to Flash. Microsoft Silverlight is based on the technologies of the .NET Framework, Microsoft’s sophisticated software stack that underlies most of its modern platforms. Silverlight is delivered chiefly in the form of a web browser plugin.

Silverlight applications can be programmed from several different programming languages, but the browser plugin never saw widespread adoption outside of the Microsoft ecosystem. The notable exception has been Netflix, which plans to move away from Silverlight in a future version[4]. First released in 2007, Silverlight may have simply come too late to market to garner widespread adoption.

The official Silverlight browser plugin is only available on Windows and OS X. Although a free software version of Silverlight is available that runs on Linux and other operating systems, like with Flash, you will be leaving iOS and Android users in the lurch if you develop your site with Silverlight. Further, Microsoft's support for Silverlight appears to be waning. Stick with Dart and JavaScript.

Recent Developments

It seems a rule in web technology (if not all technology) that any platform that comes to dominate a space will quickly have newcomers attempting to displace it. When it comes to JavaScript, the strategy seems to be more one of acceptance of it as a standard, while attempting to work around it. Embrace and extend if you will.

The chief JavaScript alternatives all compile to JavaScript. You obviously already know about Dart, Google’s effort which launched in 2011. Dart is an entire alternative platform. CoffeeScript is a less ambitious effort. It’s basically a set of syntactic sugar that makes JavaScript more readable and adds a few more advanced language constructs that reduce the size of an equivalent program (in terms of lines of code). Of course the benefits of a syntax change are up to the whims of an individual. Some people will prefer CoffeeScript’s syntax (which borrows from Ruby and Python) while some people will prefer traditional JavaScript.

CoffeeScript has gained some traction. It is a popular language on GitHub and was even included in the 3.1 release of the popular web development framework Ruby on Rails[5]. CoffeeScript does not represent a paradigm shift. It represents an influential direction for client-side languages as far as programmatic syntax is concerned.

Microsoft had an answer to JavaScript and an answer to Flash. Surely, it must have an answer to Dart… Of course it does! TypeScript, first appearing in 2012, is Microsoft’s player in this space. Unlike Dart, TypeScript does not represent a completely separate platform, but instead is a superset of JavaScript. In fact, many of TypeScript’s features are expected to appear in the forthcoming JavaScript standard ECMAScript 6.

Like Dart, TypeScript aims to relieve the difficulty of cleanly building modern, significantly sized applications that live in the browser. Also like Dart, it includes support for classes and optional types. That’s where the similarities end. TypeScript does not represent a new platform. It represents an improved environment for building JavaScript applications. There is no TypeScript VM. If Dart didn’t exist, TypeScript would be a more compelling pure JavaScript alternative. But, as it stands, most of the features inherent to TypeScript will be included in the near future in JavaScript anyway.

Although seldom mentioned in the tech media, Haxe is a rather remarkable language. It not only compiles to JavaScript, but also to Flash, PHP, C++, Java, and more. It’s truly a truly platform independent language if there ever was one. At the same time, it’s syntax is close to ECMAScript so it looks familiar to JavaScript and Flash developers. Haxe first appeared in 2005.

Server Side

The difference between server-side and client-side programming is delineated in Chapter 7. The diversity of solutions for server-side development far outstrips that of the client-side. The alleviating factor that makes the possibilities so much more pliable, is the lack of necessity to run in the browser. There are web frameworks available for just about every programming language in mainstream use. The job of a sever-side web framework basically boils down to receiving a request, processing it (and any user supplied parameters), and outputting HTML back to the web server ready to be served to the user. The story of server-side web development has been a story of making this (and everything that goes with the process step such as database access) process easier.


CGI stands for Common Gateway Interface. It's an interface, first developed in 1993, that allows a request sent to a web server to result in the execution of a program on the server. The content generated by the program can then be sent back to the client via the web server. A CGI program can essentially be written in any language. The interface was developed as a standard that all web servers could implement.

Although uncommon today, it wasn't unusual to see large CGI programs built in C or C++ in the 1990s. They were ubiquitous languages that offered tremendous speed at a time when computer hardware, even on the server-side, struggled to keep up with the demands that were placed on it. The problem with C/C++ is that they're memory unsafe and don't have tremendous built-in facilities for text processing, which is the purview of much web work. These points make writing CGI programs in C or C++ arguably more difficult than in other languages. That didn't stop Amazon from building a large part of its original 1995 site in C[6].

C and C++ were so widely used (outside the Web) that their syntax became the template for most of the languages used on both the client-side and the server-side of the web in the 1990s including JavaScript, Java, Perl, and PHP. Today, it's rare for a server-side web application to be developed in C or C++. However, a program built-in another language may call a C/C++ library for performance reasons. An example would be a Python based genetics research web app that calls C code for doing numerical analysis. The logic of building the app may be all Python, but the computationally intense bit will be C. For a little more information about C, see Chapter 17.

Many of the languages that became popular on the Web began by being utilized through CGI. Most of them later gained their own web server extensions that bypass CGI for performance reasons. CGI continues to be an option on modern web servers.


For many years, Perl was the glue that held together the Internet, operating through the Common Gateway Interface to power many early websites both large and small. It was the first higher-level language to be widely deployed for server-side web programming. Perl, founded by Larry Wall in the late 1980s as a scripting language, actually predates the Web. Perl has extensive capabilities for processing text – a task critical in web development (HTML is just text after all).

So, why didn't Perl maintain its popularity? One of Perl's slogans is "There's more than one way to do it." That's not always a good thing. Perl gained a reputation for being the language most likely to be used for writing cryptic, unreadable code. If everyone does things their own way, and individual style trumps common conventions, then that's a recipe for a lot of mutually difficult to read code.

Perl has been stuck in a versioning nightmare since a new redesigned version, Perl 6, was announced in 2000. Fourteen years later, Perl 6 continues to be in development while Perl 5 has diminished in popularity. Larry Wall continues to lead Perl as its Benevolent Dictactor for Life (BDFL). Several popular websites continue to be developed in Perl including Craigslist which hired Larry Wall in late 2013[7].


PHP began as a set of C CGI scripts that Ramsus Lerdorf used on his personal homepage in 1994. It evolved into a templating language, and over time a distinct programming language that somewhat resembles Perl. PHP lives side by side with HTML. It has the ability to be embedded in tags within an HTML document, which makes deployment as simple as uploading a PHP file to a web server. This simplicity of deployment is likely what rocketed PHP to become the most popular server-side web language amongst small to medium size websites. It's practically unheard of to sign up for a small business web host and not have the web server come with built-in PHP support.

PHP even powers the most popular content management system in the world, WordPress. In fact, PHP is so popular, even today, that it gets mocked by developers from other language communities for the poor quality of the code developed with it. As a popular, easy to deploy, ubiquitous language, PHP attracts a wide swath of developers including many just starting out. Naturally, if inexperienced developers make a large set of your user base, code quality will suffer. It's in a similar situation on the server-side to JavaScript on the client-side which is also sometimes mocked by other language communities.

Are these criticisms fair? The answer is largely, no. High performance, beautifully engineered code is written by top-tier talent in PHP every day. Facebook is largely written in PHP[8]. PHP is relatively high performance compared to some of the other popular modern server-side offerings. PHP may have been the accident of one man's tinkering and largely unplanned as a language, but it's clearly been successful for a reason – it's easy to get started with and high performance.


ASP was Microsoft's original entry into the server-side web technology war. ASP, which stands for Active Server Pages, could in its original 1996 incarnation most readily be compared to PHP. It had an emphasis on embedding logic in tags alongside HTML. With an emphasis on Windows server operating systems, ASP never had a fighting chance of reaching PHP's level of ubiquity given that the majority of web servers run Linux or other Unix like operating systems. ASP was replaced by ASP.NET, a version tailored for Microsoft's multi-language .NET platform. Microsoft released a paper in 2003 titled "Migrating from PHP to ASP.NET" comparing PHP and ASP.NET that may be interesting from a historical perspective[9].


The big excitement when Java launched surrounded using it for building write-once-run-anywhere desktop applications and Java applets. Over the years, Java did achieve dominance across a wide array of devices from mobile phones and credit cards to DVD players, but it never achieved prominence on the desktop outside of the corporate world. It did, however, find a surprising niche as the power behind many industrial strength web infrastructures. J2EE (Java 2 Enterprise Edition), released in 1999, was the first major version of Java that explicitly targeted large scale web infrastructure developers.

Sun Microsystems, the creator of Java, created Java as an open specification that other corporations could implement. IBM, RedHat, and others created J2EE implementations that could run the same server-side programs that ran on Sun's J2EE application server. This created an ecosystem of industrial strength enterprise grade Java application servers backed by the world's biggest enterprise tech companies. Java flourished and became the preferred enterprise server-side technology.

JSP, or Java Server Pages, a part of J2EE, allows Java to be embedded with HTML similarly to PHP. Java continues to be widely deployed in the enterprise world for server-side stacks due to its high performance, maturity, and large pool of developers and advanced libraries. Newer languages that run on the Java Virtual Machine (JVM - similar in principal to the Dart VM) such as Scala, Clojure, and Groovy have their own popular web frameworks (Play is one, for example) that have the added benefit of being able to interact with legacy Java libraries. Further, versions of Ruby and Python (JRuby and Jython), two popular languages to be mentioned shortly, also run on the JVM.

For all of the reasons expounded in the last paragraph, the Java platform continues to be compelling. It probably has lost web developer mind-share, not so much because of its faults, but instead because what's come after it is so compelling. A concentration during the last decade on rapid application development frameworks with batteries included, which includes Ruby on Rails and Python with Django, has captured the imagination of the industry because they allow developers to build more quickly than with traditional solutions like Java.


Python, like Perl was originally created by a single developer as a scripting language for Unix-like systems. In this case, the year was 1991 (just 4 years after Perl) and the creator was Guido van Rossum. While Perl was successful on the server-side of the Web almost from the beginning, it took until the 2000s for Python to become a mainstream server-side Web language. For more about Python, the language, see Chapter 17.

Python's clean, easy to follow syntax and batteries included philosophy makes it a great language for getting things done quickly. However, that didn't make it a great language for building web apps until web frameworks that matched the elegance of the core language became available. The most prominent Python web framework is by far Django. Django began life in 2003 at a newspaper for its internal use and was released to the public initially in 2005. Django follows a classic and powerful software development paradigm known as MVC (Model View Controller), which emphasizes the separation of data from display.

Django is not the only game in town. Python is somewhat notorious for the proliferation of so-called microframeworks. These are small web frameworks that don't necessarily include all of the features of a full service framework like Django, but make it very easy to get smaller web apps built quickly due to their logical defaults and concise setup. The most popular microframework is probably Flask. Hello World in Flask (showing a web page that displays "Hello World") is just a few lines of Python.

If Python's syntax is so praised and it has such great frameworks available then why isn't everyone using it for server-side web app development? Python's popular implementation has relatively poor performance compared to some of the other options available which makes it unsuitable for some applications. Further, Python deployment is trickier for beginners than something like PHP where a file with embedded HTML just gets dropped on a server. However, Python is still very popular today, and probably doesn't compete as much with PHP developers as it does with Ruby developers. Also similarly to Perl, Python has suffered from a botched version transition from Python 2 to Python 3 (no letters please!), although Python 3 has been gaining traction as of late, 5 years after its debut. Like Larry Wall, Guido van Rossum continues working as Python's BDFL.


Ruby is a language first released by Yukihiro Matsumoto in 1995. Like Python it features clean syntax and a thoroughly object-oriented design. Outside of Japan, Ruby failed to gain significant popularity until the released of the web framework Ruby on Rails (also known just as Rails). Ruby on Rails led to an explosion of interest in Ruby (mostly to use Rails) due to high developer productivity in the framework.

Ruby is coupled with a popular packaging system called RubyGems that is analogous to Dart's pub. The combination of a vibrant gems ecosystem with Ruby on Rails has allowed for the rapid development of many web apps. It is a pretty common belief that an equivalent web application can be built with fewer lines of code with Ruby on Rails than with comparable web frameworks for other languages.

There's a lot of "magic" that goes on behind the scenes of a Ruby on Rails web application that allows just a few lines of code to provide an impressive array of functionality. This magic has been criticized because it is thought that it leads to a situation where novice developers build complex web applications without understanding fully what's going on behind the scenes. It is so easy with RubyGems to include an open source project that adds significant functionality to a Rails application that it is trivial. This notoriously leads to many poorly supported gems underlying the architecture of Rails applications.

Also like Python, Ruby's most popular implementation suffers from performance problems (even worse ones than Python indeed). Twitter was originally developed largely in Ruby on Rails but due to performance and scaling considerations had to move several pieces of its stack to JVM based languages (Scala and Java) as it grew[10]. Ruby on Rails development offers many similar advantages and pitfalls to Python with Django. Choosing between the two has more to do with personal preference (in regards to language syntax and how the frameworks work) than any inherent advantage of one over the other. When you don't need to worry about large scale, as most beginning developers don't, both are excellent options for modern server-side web app development.


JavaScript has only become a popular server-side option since the advent of high performance JavaScript VMs during the last decade. Netscape actually shipped a server-side JavaScript framework as early as the mid 90s, but it was not really until the release of Node.js in 2009 that sever-side JavaScript began to flourish. Node.js is a platform for building asynchronous web apps using JavaScript. One of the most popular frameworks for Node.js is Express.js.

Why is JavaScript on the server-side a good idea? The key benefit is the ability to use one language for both the client-side and the server-side. This familiarity arguably enables an environment where code reuse is optimized and developer skillsets can more easily span both domains.

Node.js provides not just an application server, but also a packaging environment. npm is a package manager, analogous to pub. Plain vanilla JavaScript does not provide a clear path for package management.

JavaScript on the server-side, and specifically Node.js, is seeing adoption in the corporate world. Microsoft helped port Node.js to Windows[11]. Walmart is utilizing Node.js to back its online store[12]. These are recent developments within the last three years. Clearly server-side JavaScript has momentum.


The biggest trend in server-side web development of the past ten years has actually come from the client-side. The advent of fast client-side JavaScript and the popularity of AJAX has allowed logic that was once exclusively the realm of the server-side to be pushed into the browser. This has caused the focus of server-side development to be less on building full MVC (model, view, controller) applications and more on supplying data to be displayed by complex JavaScript front-ends. It is not uncommon for a single server-side application, serving JSON, to deliver data for a web-client built in JavaScript, an iOS client built in Objective-C, and an Android client built in Java. In fact, this maybe the epitome of what's seen as a "modern" architecture.

Another clear trend is use of the same programming language on the client and server. This is most obvious with JavaScript's Node.js, but there are other examples. Dart is one. There are several projects that put Python in the browser via compilation of Python to JavaScript (pyjs, Skulpt, PyPy.js). There are similar JavaScript compilers for Haskell, Clojure, and many other languages that are also used on the server-side. The best known other-language-to-JavaScript-compiler may be another Google sponsored project, called Google Web Toolkit. Google Web Toolkit (GWT) compiles Java to JavaScript.

Finally, one more trend has been language experimentation. The number of languages with viable server-side web frameworks seems to be ever expanding. There are languages that are beautiful in their functional purity, like Haskell, and languages bent on simplicity like Go. There are languages that thrive when put to the test of concurrency like Erlang, and languages that are hyper-modern in their feature-set like F#. All of them are being used to build industrial strength web applications that would've been built with PHP or Java a decade ago.

The overall focus of all of these trends is on simplifying the toolset and letting developers work in the environment they are most comfortable with. There's an incredible diversity of options available for server-side web programming today. With a lot of choice also comes a lot of fragmentation and little fiefdoms. Do you have a big server-side web app coded in Haskell? It's going to be a very specialized (and probably expensive) set of developers that can service it.

How do you pick a server-side language/framework in such a fast moving landscape? Take advantage of these trends. If your application can move much of its logic to the client-side, do so. Then you can code it largely in Dart. If you can simplify your life by using Dart on both the client and server, go for it! If the specialization of one of the many languages that have robust server-side frameworks available is good for your application, then take advantage of it, as long as its ecosystem looks viable going forward.

Where Does Dart Fit In?

Dart emerged at the end of these timelines, both on the client-side and the server-side. It incorporates a lot of great thinking from its predecessors. It's a balanced language. It's not necessarily overtly focused on a single niche in the same way that a Haskell or PHP might be. It's most comparable to JavaScript in that it runs both in the browser and on the server. However, syntactically it shares a great resemblance with Java.

Dart is meant to be an accessible language suitable for developing both small and large web apps. It contains facilities for rapid prototyping. Yet, it also has features that make building large applications easier than with JavaScript. At the same time it's compatible with today's client-side infrastructure because it compiles to JavaScript. Dart tries to take a Goldilocks position.

Dart has many of the modern features present in languages that have emerged over the past few years, yet its syntax is reminiscent of older languages. Dart is not the fastest language available, but it's faster than JavaScript (when run on its own VM) and the most popular implementations of Ruby and Python. Is a lack of specialization a problem for Dart when JavaScript is seen as good enough by many? Only time will tell.

Evolution of the Web Browser

Alongside the ever changing landscape of client-side and server-side web programming languages has been a parallel history of browser development and enhancements to HTML/CSS. In the beginning (i.e. 1990), there was Tim Berners-Lee original Web Browser for NeXTSTEP called WorldWideWeb. The HTML spec and that original browser didn't even support images, let alone CSS. Mosaic was the first widely used multiplatform web browser, and it was released in 1993 by a team at the National Center for Supercomputing Applications (NCSA) at the University of Illinois Urbana-Champaign.

Microsoft and Netscape Duke it Out[13]

Mosaic led to two spinoff browsers. Netscape Navigator was a commercial program released in 1994 and built by a team of ex-Mosaic engineers at the nascent Netscape Communications Corporation. As a commercial entity, the Netscape team had to purposely avoid using any of the old source code from Mosaic. Netscape quickly succeeded Mosaic as the browser of choice for early Web users.

Microsoft, realizing the web platform was a threat to its dominance of desktop personal computing, licensed the technology behind Mosaic from an entity called Spyglass Inc. which in turn had licensed the source code to Mosaic from the NCSA. Microsoft released Internet Explorer 1.0 in 1995. Over several revisions during the next few years, Internet Explorer took significant marketshare from Netscape.

The period of Netscape and Internet Explorer competition (roughly 1995 to 2000) was one in which several client-side technologies previously mentioned were developed and popularized including JavaScript, VBScript, Java, and Flash. Unfortunately, at least with regards to the former three, they led to significant incompatibilities between dueling feature sets in Netscape and Internet Explorer.

A JavaScript program written for Netscape would not necessarily run unmodified on Internet Explorer. Likewise, a Java program coded for Microsoft's Java Virtual Machine (JVM) would not necessarily run correctly in Netscape/Sun's JVM. A VBScript program wouldn't run in Netscape at all.

Even the HTML spec itself was up for dueling visions. There were tags that one browser supported and the other didn't. Even more common, a tag/style displayed in one browser could look very differently on the other. Even today, it's important to check how a site looks in all of the popular browser, but back then it was also a matter of coding around the inconsistencies and building specialized versions of a program/site for each browser.

During this period there were no major platforms that mattered other than personal computers and they ran Microsoft Windows or Mac OS. Those were the main platforms that Netscape and Internet Explorer supported. There was no worry about supporting browsers popular on smartphones or tablets or game consoles (although early versions of browsers for all of these existed).

Microsoft's coupling of Internet Explorer with its dominant Windows operating system and proprietary version of the JVM led to lawsuits, but in the scheme of things they didn't really matter too much for the average web developer. By the year 2000 Internet Explorer had won. Microsoft's browser attained over 80% market share. Netscape was sold to AOL and the source code to its browser was given to a not-for-profit foundation known as Mozilla.

Firefox Emerges from the Ashes of Netscape

Mozilla released an open source browser that made little dent in Internet Explorer's hegemony. During the period of Internet Explorer's domination it was not uncommon for sites to be coded for it to such a degree that they would not work in alternative web browsers. The first significant challenger to Internet Explorer came out of Mozilla in 2002. Firefox was a stripped down, more lightweight version of the open sourced Netscape components that gained a quick following in some international markets.

The interest in Firefox coincided with a reemphasis on open standards in the industry (including specifications like CSS and HTML 4). The goal was to avoid the fragmentation of the 1990s and ease the difficulty of web developers' day jobs. It didn't happen quickly. There was little incentive for Microsoft to move quickly to adopt standards to help erode its dominant position.

In 2003 Apple released its own web browser, Safari, only for Macintosh, and based on open source technology earlier used in the Linux world. The same year, Microsoft announced it would not release any new versions of Internet Explorer for Macintosh. Although Window had over 90% marketshare amongst personal computers, this did provide a further impetus for web developers to build sites based on open standards and cross-browser compatibility.

Mobile and a Revitalized Browser Ecosystem

There were versions of Safari for Windows that didn't make much of a dent in the market, but it was the version of Safari that came with the original iPhone in 2007 that really changed the game. Mobile web browsers had existed since the 1990s, but they were limited in functionality due to the weak microprocessors and user interface technologies that existed on mobile phones up to that point. The iPhone was the first smartphone to offer a full web browser experience that made websites designed for desktop browsers easy to read on the go. And the iPhone's Safari depended on open standards.

Most importantly, the iPhone's Safari didn't support plugins. This meant no JVM (no Java applets) and no Flash. The iPhone was a sensation and if web developers wanted to capitalize on its success, they would need to code to the open web standards (namely JavaScript, HTML, and CSS) that it supported. It was also the beginning of concern for making sites that worked well on many highly different screen sizes. While the iPhone could display sites written for big monitors that accompany desktop web browsers, sites looked better when their content was responsive to different screen sizes.

Google's Android followed in 2008 and largely reinforced the changes brough about by the iPhone. And these were yet further reinforced by the iPad and Android tablets. It's unusual for a site today to not look great on both mobile and desktop.

Google also released its own desktop web browser, Google Chrome in 2008, based on the same open source project, WebKit, as Apple's Safari. Chrome's super fast JavaScript VM, V8, was a revelation. It enabled applications to be coded for the browser that were previously only done natively. It led to a arms race in JavaScript VMs between all of the major players – Mozilla, Apple, Microsoft, and Google – which ultimately pushed the state of the art on the Web forward.

Whole platforms emerged based on browser technologies. Palm launched the ill-fated WebOS which was ultimately scattered in pieces across HP and LG. Google launched an operating system called Chrome OS that has seen some success in low-end laptops. Mozilla launched Firefox OS, an operating system for smartphones targeted at emerging markets and low-end handsets.

By the mid–2010s, Microsoft was no longer dominant in the browser space. Web developers today care as much, if not more, about what Google, Apple, and Mozilla think about web standards as they do about Microsoft. On the other hand there are still many older versions of Internet Explorer floating around corporate environments that need be coded to for major applications. Microsoft, whether as a result of a change in its corporate culture, or a shifting competitive landscape, has embraced open standards in the past few years. The most recent versions of Internet Explorer are on the cutting-edge standards wise.

HTML5, the current version of the HTML specification, embraces facilities for managing the changes that have occurred over the past decade with regards to the web development ecosystem. For instance, it includes facilities for displaying rich content like video, audio, and graphics that were once the purview of Java Applets and Flash. It also has built-in support for displaying content in ways that is responsive to differing screen sizes.

Firefox and Chrome have adopted rapid release cycles that bring innovation to users as quickly as possible. At the same time, users are treated to constant upgrades with little discernable difference between sequential versions. Table B–1 summarizes the browser world today.

Table B–1 Web Browsers Today

Internet Explorer Firefox Safari Chrome
Developer Microsoft Mozilla Apple Google
First Appeared 1995 2002 2003 2008
Release Cycle Traditional Rapid Traditional Rapid
Rendering Engine Trident Gecko WebKit Blink (forked from WebKit in 2013)
JavaScript Engine Chakra SpiderMonkey Nitro V8
Open Source? No Yes Engine Only Based on open source Chromium project
Desktop Platforms Windows Cross-Platform OS X Cross-Platform
Mobile Platforms Windows Android, Firefox OS iOS Android, iOS
Other Platforms Xbox Chrome OS

There are other browsers too, such as Opera which has mobile versions, desktop versions, and versions for specialty markets like the Nintendo Wii. Most alternatives to the big four use the same rendering engine as one of them so can be expected to render things in a similar fashion. For example, Opera has adopted the Blink engine used by Google Chrome. Another example is the experimental browser included on some versions of Amazon's e-ink based Kindle e-readers which runs an engine based on WebKit, the same engine used in Apple's Safari.

There are differences between the mobile and desktop versions of the big four. In other words, Windows for Windows Phone doesn't necessarily support all of the same technologies as Windows for desktop computers. More and more the emphasis for new websites has been on designing mobile-first as usership naturally moves to mobile devices.

Importance Today

Why does it matter what web apps were coded in 20 years ago? It matters because there's been a clear progression, both on the server-side and the client-sider, in web technology. Each technology exists today as a response to what came before it. PHP would likely never have existed if writing web apps in C wasn't cumbersome. Dart is a direct response to the difficulty of building large scale applications in JavaScript.

The browser wars ultimately resulted in the adoption of open standards. That's arguably good for almost everybody (save the former dominance of Internet Explorer perhaps). Web developers today largely don't need to worry about coding platform specific hacks.

By understanding the history, it's possible to tease out trends that will continue to affect the industry. By understanding these trends, a developer can insure that he's riding the wave of technology instead of swimming against it. If you could see the direction the industry was going in 10 years ago, you certainly would have been careful not to code a large application in VBScript. Today that might be Flash.

There are right answers when choosing a Web technology to build with. It's important to understand what your alternatives are. It's important to code with an eye towards the future and understand the mistakes that others have made in the past. The Web can be complicated, but it's generally getting less painful with each passing year.

  1. Oracle "The History of Java Technology"–198355.html  ↩
  2. Microsoft VBScript is no longer supported in IE11 edge mode for the Internet zone  ↩
  3. Steve Jobs Thoughts on Flash  ↩
  4. Anthony Park and Mark Watson HTML5 Video at Netflix  ↩
  5. Peter Cooper Rails 3.1 Adopts CoffeeScript, jQuery, Sass and… Controversy–3–1-adopts-coffeescript-jquery-sass-and-controversy–4669.html  ↩
  6. Brad Stone The Everything Store: Jeff Bezos and the Age of Amazon (Little, Brown 2013) p 36  ↩
  7. Jim Buckmaster "Artist. Formerly known." Craigslist blog  ↩
  8. Brian Shire "PHP and Facebook"  ↩
  9. Microsoft "Migrating from PHP to ASP.NET"  ↩
  10. Alex Williams "Once Again, Twitter Drops Ruby for Java" readwrite April 11, 2011  ↩
  11. Ryan Dahl "Porting Node to Windows with Microsoft's Help" Node.js Blog. June 23, 2011  ↩
  12. Eran Hammer (Interview) "Node Black Friday at Walmart with Eran Hammer" The Changelog (Podcast)  ↩
  13. For more on the early history of the Web checkout The Internet History Podcast at  ↩

Posted in , , , | Leave a comment

Classic Computer Science Problems in Swift is Released!

Last week, Classic Computer Science Problems in Swift was released in print by Manning. It’s now in general availability from both Manning and Amazon. It’s a great book for students enrolled in a computer science program, professionals looking to learn a few computational problem solving techniques they’ve always been curious about, people preparing for job interviews, or anyone who already knows Swift and would like a very tutorial-oriented intro to some basic algorithms from AI.

The book aims for breadth instead of depth. There are chapters on search (including depth-first search, breadth-first search, and A*), graph algorithms (including Prim’s algorithm and Dijkstra’s algorithm), genetic algorithms, constraint-satisfaction problems, k-means clustering, neural networks, and more. It’s not a data structures & algorithms textbook. Instead, it’s a concise set of hands-on tutorials starting from scratch in each subject area. It’s also not an app-development book. The reader will not find any UI code. Instead, it focuses on solving several classic problems one would typically find in an undergraduate CS curriculum as concisely as possible in Swift Playgrounds.

The book assumes the reader is an intermediate Swift programmer. It is not appropriate for absolute Swift beginners. You can watch my short intro video explaining the book on YouTube and you can find all of its accompanying source code (tested against Swift 4.1 Playgrounds in Xcode 9.3) on GitHub. Most of the code will work in any Swift project, including projects for Linux.

If you read the description in the YouTube video, you will find a code to get a significant discount on the book from Manning. You can also download both Chapter 2 (Search) and Chapter 4 (Graph Algorithms) for free from the book’s page on Manning’s website. I think Chapter 4 (Graph Algorithms) is a really great chapter. In it you solve several problems related to building out a Hyperloop network in the United States while developing a graph data structure programmed in a protocol-oriented style.

Writing the book was mostly a joy. I finished the manuscript in September 2017. Delays in Manning’s production department led to the April 2018 release. I apologize to readers who pre-ordered the book and had to wait so long for the final version. I am not terribly happy with the formatting of the .mobi (Kindle) and .epub (iBooks) editions, which unfortunately is out of my control. I recommend picking up either the PDF from Manning or the print edition. When you purchase the eBook from Manning, you get the PDF, Kindle, and iBooks versions together.

Thank you in advance for reading. Feedback from readers in Manning’s early access program has been very positive. Pre-order sales of the book have also been strong. Let me know your feedback (both positive and negative) about the book on Twitter. And Amazon reviews (especially positive ones 😀) are appreciated. We are probably going to “port” the book to other programming languages, but those new books are likely a long-time away from release. I will also update the GitHub repository with an updated PlayGround when Swift 5 ships in final form.

Posted in , , , , | Leave a comment

Core Image for Swift Review

I recently completed reading Core Image for Swift by Simon Gladman. The book is available for free on iBooks. I had little previous exposure to Core Image, nor writing GLSL (the language Core Image filters are defined in) and I found this book a thorough and well written introduction.

To my knowledge, this is one of only two full-length book about Core Image. I have not read the other, but since its publication date (2012) predates Core Image for Swift (2016) by four years, I imagine it is somewhat out of date. Gladman is comprehensive in his coverage of the technology. He covers the built-in filters, creating various kinds of filters from scratch, image display options like GLView and MetalView, and peripheral technologies like vImage. In short, everything you would need to get started using Core Image for almost any purpose is covered in this book.

Gladman’s approach is one of using copious source code examples. Some people learn better from English explanations and some people learn better from code. This book will mostly appeal to the latter kind of reader. With that said, Gladman does take the time to explain basic information that the uninitiated in the digital image manipluation world will likely find helpful. Such as, how does a convolution filter work? The difference between various techniques and why you would use each is made clear throughout.

I read the book from cover-to-cover, which is probably not how most people would approach this book. The chapters are self-contained enough that you could probably just read the first few and then pick and choose chapters on topics that interest you. In my opinion each chapter is a more cogent explanation of the topic at hand than Apple’s documentation provides.

The biggest downside of Core Image for Swift is that it was written in the Swift 2 era, meaning its source code is now outdated and requires translation. Most of the source code in the book is provided in online repositories. However the repositories themselves have not been updated in over a year. Since Mr. Gladman began working at Apple last year, I think there is little hope the book itself will be updated either. We cannot blame book authors for writing books that get outdated. I just finished writing Classic Computer Science Problems in Swift, and with a fast moving target like Swift, it is likely that my book too will have some syntax incompatibilities with the latest version of Swift in a couple years. Xcode 9 is able to translate most of the code from Core Image for Swift into Swift 4 with little manual intervention beyond a lot of clicking “fix.”

Overall, Core Image for Swift is an excellent introduction to Core Image and I highly recommend it to anyone interested in this technology. Since it is free, it is a no brainer to at least download it and checkout the first chapter. Mr. Gladman’s blog is also work checking out. Many of the older posts are about Core Image.

Posted in , , , | Leave a comment

Annoucing Classic Computer Science Problems in Swift

I am pleased to announce the availability of my second book, Classic Computer Science Problems in Swift. Starting today, you can purchase early access to the book from Manning (use promo code mlkopec for 50% off through June 27th). I have completed drafts of the first six of eight chapters; three of which are available today from Manning, with the next three to follow over the summer. The final version of the book will arrive in Fall 2017, shortly after the release of Swift 4.

Classic Computer Science Problems in Swift is a great “second book on Swift.” It is aimed at those with some basic knowledge of Swift’s syntax who want to delve deeper into the covered problem solving techniques, brush up on core algorithms, or learn more Swift using problems familiar to them from other languages. It is suitable for professionals looking to deepen their understanding of the covered topics, students with some programming background looking to expand their computer science knowledge, and anyone preparing for coding interviews.

What is a “Classic Computer Science Problem?” It is a problem one typically finds in an undergraduate computer science curriculum. The topics covered in the book span the gamut from core computer science algorithms you would find in a data structures & algorithms class to artificial intelligence and its sub-discipline machine learning. There are both practical and whimsical problems. They include classic search problems, constraint satisfaction problems, graph algorithms, genetic algorithms, k-means clustering, simple neural networks, and more!

The book is not your typical app development book. You will not find any UIKit, App Kit, or full blown apps. Instead, you will be learning problem solving techniques (in Swift) that will make your apps more powerful, more efficient, and more featureful. All of the code in the book is Linux friendly (server-side Swift friendly) and available for easy perusal via a Playground on GitHub.

To learn more, checkout the Classic Computer Science Problems in Swift page on Manning’s website where you will find a full table of contents and free access to the Introduction and Chapter 2 (Search Problems). If the table of contents looks appealing to you, dive in with promo code mlkopec which will give you 50% off through June 27th!

Remember that you are purchasing a pre-release version of the book, so you will be joining me on the journey to its final release in the fall. You will be receiving rough drafts of chapters before they have been fully developed. I encourage you to send me your feedback, but keep-in mind that these are early days and everything is not yet perfect. You will receive the final version of the book upon publication.

Posted in , , , , , , | 3 Comments

Five Months on the Apple TV App Store

Apple launched the fourth generation Apple TV on October 29th, 2015. That was also the first day of the Apple TV App Store and the first day that my tvOS app, Chess TV!, was available. Chess TV! is an app that I created as a side-project in about 30 hours of my time after receiving a free Apple TV dev kit from Apple prior to the official launch of the device. I have been pleasantly surprised by its sales. This is the story of its first five months.

Building Chess TV!

I have quite a bit of experience with chess programming. I studied chess AI as my culminating experience in graduate school and I have developed prior chess apps as well as the main (only?) chess programming library for the Dart programming language. Yet, I felt there was no reason to reinvent the wheel. My goal was to create a great big screen chess playing experience, not to create a cutting edge AI.

To that end I searched through the repositories of the many open source chess engines. All of them (even the weak ones) are strong enough to be competitive for all but the most elite players. My criteria instead was:

  • Will this engine be easy to integrate with my code?
  • Is this engine well documented (or its source easy to understand enough), so that I will have no problem utilizing its public interface to implement features I want like undo/redo, algebraic move output, etc.?
Surprisingly, many of the popular engines are so concerned with performance that things like ease of integration and documentation take a backseat. I ultimately settled on integrating Mister Queen by Michael Fogleman. Mister Queen is not a well known engine by any means, but in my testing using The Bratko-Kopec Test it scored a 13/24 when provided 8 seconds per position (12 at 4 seconds and still 13 at 16 seconds) which indicates it’s about expert strength (ELO ~2000, stronger than 99+% of users).

Mister Queen is written in clear, concise, C. For a one-man project, as with most of Michael Fogleman’s projects, it’s surprising for its completeness and depth. I think I made a great choice, as it’s been a joy to integrate and has provided several features off-the-shelf (like built-in testing positions (more about that later)) that I would have otherwise needed to write myself. I do not regret at all choosing Mister Queen over the more popular alternatives. Sometimes in programming software, just as in using it, ease-of-use trumps all else.

Because Mister Queen is written in C, I chose to use Objective-C, instead of Swift, in writing Chess TV!. Although Swift has good support for C, it can’t beat Objective-C on that front! Working with UIKit on tvOS is almost identical to working with it on iOS. The main difference is thinking about focus (what UI element is currently selected by the Apple TV’s trackpad like remote). Once I had implemented a chess board using custom UIViews for each square with intelligent focusing behavior, I chose to use off-the-shelf widgets for the rest of the interface. The result is a UI that looks plain and no-nonsense, but also fits well with the rest of tvOS.

I’ve noticed a lot of bugs in other apps with regards to how the remote’s menu button operates. Misbehavior in this regard can even lead to rejections by app review. By using a standard tab bar controller, I’ve managed to avoid this.

I wanted Chess TV! to be more than just a chess playing app. Conveniently, Mister Queen is bundled with ~400 famous chess puzzles (positions where you choose the best move) from famous chess books (you cannot copyright a chess position - that was settled in the legal system). So, I built Chess TV! so that in addition to its playing mode it also has a puzzle mode, something none of its competitors have…


When the app store launched, Chess TV! was the only chess app on the store. By the second day of the store a competitor, also priced at $0.99, appeared. We dueled it out for chess app supremacy. Because there were so few apps on the store at the time, throughout November it was not unusual to find both apps in the top paid apps list.

In the last couple of months two free competitors have also appeared on the store as well as two apps related to chess (a chess clock and a chess watching app). For whatever reason, the two free apps do not seem to have diminished my sales. I have done zero marketing of Chess TV!. I think it may be that users are trying out the other apps and then deciding they want something more substantial. It’s possible that my higher price point (see next section) has actually signalled to the market place that Chess TV! is a premium product. If that theory is true, then the marketing efforts of the free competitors may actually be boosting Chess TV! sales.

I will say that I think Chess TV! is the most featureful (especially considering the puzzles) tvOS chess app. There are a couple features (3D, saving and resuming games) that other apps have that Chess TV! does not. Since launch, I have added features like support for background music, board flipping, and alternative board patterns based on feedback from users and the inclusion of these in competitors’ apps. I have also added Spanish localization, but it’s unclear how much this has boosted sales.

Pricing & Sales

Chess TV! launched at $0.99 cents and sat there for several months. I have experimented with prices ranging from $2.99 to $4.99. I tried each price out for about a week and compared sales to the prior week. Eventually I settled at $3.99, not based on much science other than these weekly examinations. I’m not sure it’s the ideal price, but I do think the signalling of Chess TV! as a premium product has helped it. Units are of course down from the $0.99 price point, but sales (in dollars) are actually stable or up.

Sales average $150-$200/month (before Apple’s cut). It’s not going to make me rich, but if these sales continue for the rest of the year (a big if), then for something I did as a hobby in about 30–40 hours of time (including updates, excluding me thinking about it, talking about it, and checking up on it) I would consider the sales more than satisfactory. They’re certainly higher than I expected, especially considering I’ve done zero marketing.

The tvOS App Store Needs Work

One reason I’ve done zero marketing is that as of now, there’s no way to link to a tvOS only app’s store page (or purchase an app for that matter) from any other device. That’s right, unlike iOS apps which you can link to the store page of in a web browser and purchase through iTunes, there’s no equivalent for tvOS only apps. This is a huge problem. What do you link to (for people to purchase from) on a marketing page? I have a simple page for Chess TV! that I don’t send to anyone since it doesn’t have real links.

I’ve brought up this issue with Apple developer relations and also at the Apple TV Tech Talk in NYC. Apple seemed sympathetic to the issue, but it’s been five months and there’s been no resolution. It’s a major sore point for anyone who wants to develop and market a tvOS only app.

When the tvOS app store launched in October it definitely was not ready for prime time. It didn’t even have categories! Now it has some rudimentary categories, but still not subcategories. This is despite the fact that we are able to select a subcategory for our tvOS apps when we submit them. Perhaps Apple is embarassed by the lack of apps that would appear in some of these subcategories. It definitely hurts Chess TV! which would likely dominate the board game subcategory if the subcategory was browsable by users.

Apple has never featured Chess TV!, which I understand since it’s not graphically impressive nor does it utilize any of the unique features of the Apple TV. The least they could do for us lowly chess developers would be to give us store page links and subcategories.


In building Chess TV! I was able to leverage a great open source chess engine, Apple’s free dev kit (to get a jump on the competition), and my UIKit skills from iOS, to build an app in a relatively short amount of time that resonates with more users than I expected. Thanks must go to Apple, Michael Fogleman, and all of the early adopters who took a chance on Chess TV!. Yet, the tvOS app store needs some tweaks before it will be truly developer friendly.

Posted in , , , , , , , , , , , | 1 Comment

Three Options for App Owners Facing the End of Parse

I originally wrote this post for Crew’s Backstage blog and it originally appeared there on March 1, 2016. Special thanks to Jory Mackay for his many superb edits and improvements. Note that the original audience is non-technical app owners. I have made a few minor edits from the original post here.
If you’re one of the 500,000+ app owners that use Parse—the most popular mobile backend-as-a-service (BaaS)—to power your app, January 28th was a particularly bad day. After half a decade providing app developers with flexible data storage, and everything from user authentication to push notifications, the team behind Parse announced they’d be shutting down their services.

Which should’ve come as a surprise. Since Facebook acquired Parse in 2013, they have only provided positive indications about their commitment to Parse. If you have an app developed using a Parse backend, it’s time you started looking for an alternative.

First off, it needs to be stated plainly that this most likely won’t be a quick and easy fix. The backend is a major component of your app. In many cases, the backend and the code that connects to the backend can make up as much as 50% of your app, especially if your app is a social network, messaging app, or other app centered on storing large amounts of user created data.

Changing backends is obviously a big endeavor. Luckily, you have both time and options. Parse has provided a one year window (until January 28th, 2017) in which its services will continue to operate. If you feel that your app has not yet gained enough traction to warrant a partial rewrite, consider taking a wait-and-see approach. You could wait until the late Spring/Summer with the existing backend and then begin the rewrite if your app has taken off. But keep in mind that the longer you wait, the more dangerous your situation becomes (software development is a fickle business).

So, if it’s time to move, what are your best options?

Option 1: Open Source Parse Server (or the Path of Least Resistance)

Despite shutting Parse down, Facebook has graciously open sourced a large amount of its technology. This will allow you to run your own ‘mini-Parse’ on your own hardware or your own virtualized server (through AWS, Heroku, Azure, Linode, Digital Ocean, etc…).

Unfortunately, it’s not as feature rich as Parse was/is, and of course it comes with no formal support contract. You’ll also have to maintain your own server or virtualized server, which is more than some developers/clients want to do.

But, ultimately, this option will entail the least development work/code changes.

  • Free
  • Complete control of your own destiny
  • Fewest code changes

  • No formal support
  • Have to maintain your own server or virtualized environment
  • Still missing some features other BaaS providers have

Option 2: Switch to Another Established BaaS Provider (CloudKit & Firebase)

Apple provides a comprehensive BaaS known as CloudKit. It offers many of the same services that Parse offered and its resource limits are very similar to Parse.

CloudKit backs Apple’s own services like iCloud Drive and iCloud Photo Library, so you know the infrastructure is industrial strength and unlikely to go away in the near future. There are ample tutorials and book chapters to help developers get up to speed on it.

But, there is a catch. CloudKit has no native SDK for Android (or Windows, Linux, etc…). While the recently introduced webhooks may allow you to cobble together a cross-platform solution, CloudKit is clearly designed only for iOS, Mac, and Web apps (an official JavaScript SDK does exist). If your app is only on these platforms then it may make a lot of sense.

Firebase, acquired by Google in 2014, is perhaps the BaaS most similar to Parse. Like Parse it’s backed by a big company with a great reputation in the field of big data, is feature rich, and works cross-platform.

Firebase offers realtime capabilities that make it ideal for messaging apps and also offers clearly tiered pricing that makes sense for most startups. Firebase is relatively popular and there are many more tutorials available surrounding it than some of the lesser known BaaS providers, so it is likely one of the easier options for a developer to get up to speed on. However, some developers dislike Firebase’s API.

  • Free for apps with a small userbase
  • Backed by Apple or Google
  • Feature rich
  • Well documented
  • Realtime messaging support (Firebase)

  • iOS/Mac/Web only (CloudKit)
  • No built-in support for push notifications (Firebase)
  • At the mercy of another tech giant (like Parse was to Facebook)

Option 3: Roll Your Own Backend

Writing a custom backend can be as daunting a task as writing a mobile app, depending on the complexity of that backend. There are a myriad of frameworks, languages, servers, and development environments to choose from. If your developer does not have previous experience writing a backend, it’s likely to be a laborious, error-prone task.

However, it’s also the only path that puts you completely in control of your own destiny (even beyond the open source Parse Server).

Your custom backend is built specifically for your app. It can include whatever features you need and you can scale it however suits your growth. However, it also means maintaining your own servers. You can somewhat get a jumpstart by utilizing cloud data stores provided by services like Azure, AWS, and Google Cloud Platform.

  • Complete control of your app’s destiny
  • Customized for the features your app needs
  • Cheaper to scale
  • Can use cloud data stores from AWS, Azure, and Google

  • Unsupported by a big company (no Apple or Google backing your server code)
  • Have to maintain your own servers or virtualized environments
  • Highest development cost
  • Longest development time

So what’s the best option?

Choosing what direction to take your Parse-powered app is ultimately both a technical and a business decision. Utilizing Parse’s open source solution will be the least costly in terms of both programmatic effort and maintenance costs. Porting your app to CloudKit, Firebase, or a lesser-known BaaS Provider will be costly and time consuming but will provide you with comprehensive support and eliminate the need to maintain your own server. Finally, building your own custom backend provides the ultimate in control but also will be the most costly and time consuming to develop.

If none of these sound right for you, there are a myriad of lesser known BaaS providers like Kii, Kinvey, FatFractal, and many more out there. The risk, however, is that you build against one of them and then they cease to exist. Using one of these options may make sense for an MVP but is unlikely to make sense for something you expect to scale.

You must consider the development work involved, platform needs, pricing, and your timeline. As well as the future of the platform that you’re building upon.

No option is perfect, but continuing with Parse Server on your own server probably makes sense as the path of least resistance for most apps. If you’re interested in porting your app from Parse, get in touch with me.

Posted in , , , , , , , , , | Leave a comment
Copyright 2012-2018 David Kopec. Powered by Blogger.


Swedish Greys - a WordPress theme from Nordic Themepark. Converted by