const app = {
lines: document.getElementById('lines'),
textbox: createTextbox(),
lineTemplate: createLineTemplate(),
}

const socket = connect(
`ws://${location.host}/app`,
{

initial({ lines, uuid, charLimit }) {
app.uuid = uuid
app.charLimit = charLimit
lines.forEach(addLine)
},

added(line) {
addLine(line)
},

removed(i) {
app.lines.children[i].remove()
},

server.onclose = (ws) => {
if (ws.line) {
const i = lines.indexOf(ws.line)
lines.splice(i, 1)
server.sendToAll({ removed: i })
}
}

server.commands = {

begin(ws) {
const line = {
hash: ws.hash,
uuid: ws.uuid,
text: '',
}

ws.line = line
lines.push(line)
server.sendToAll({ added: line })
},

run() {
console.log(`Running on port ${this.port}`)

this.wss = new WebSocket.Server({
port: this.port,
verifyClient: this.verify.bind(this)
})

setInterval(
this.prune.bind(this),
this.pruneInterval * 1000
)

this.wss.on(
'connection',
this.connection.bind(this)
)
}

Steven Degutis

Full-stack software developer for hire

A better web

December 10, 2013 — 4 years ago

I propose that we do away with HTML, CSS, and JS for websites.

They're flawed and overly complex. They weren't intended for the kind of flexibility we eventually wanted, and they weren't extensible to allow for it.

Instead of a markup language, I propose we use a simple virtual machine with a small core library. The most important datatype in the VM would be an Object.

An Object would be a hash-map, but any keys which point to functions could be called with the hash-map as the first parameter, emulating methods. There would also be arrays, strings, and numbers.

Virtual Machine

Representing on-screen elements would be done via objects with special properties. Besides this, developers could use objects for other purposes too.

Common properties would be defined for specifying an element's size and shape, its position, its style, and semantics. Semantic properties on an element would replace HTML tag-names such as "a" and "h2", which conflate structure and meaning. Styling properties would replace most (if not all) of CSS.

These objects would be inherently extensible, since new top-level properties can be created at any time for any purpose by any developer. Among other benefits, this replaces "data-" attribute-prefixes in HTML.

I suggest that for simplicity, we leave out inheritance and prototypes. We could use duck-typing to emulate interfaces, and factory functions would simulate constructors. Eventually the idea of type-checking could be used for validation, but for initial simplicity I'm assyming a "dynamically typed" language.

The runtime would provide a few constructors for common types of objects (general-purpose boxes, links, buttons, columned-containers, etc). These would provide default styles as well as default event-handlers (such as navigating to a new page when clicking a link).

One benefit of only mentioning a virtual machine in the spec is that any number of "front-end languages and toolsets" can be created, allowing for survival-of-the-fittest with developer tools.

Browsers

To create a "browser", you'd only have to implement the simple virtual machine and provide the simple runtime library.

This also makes it very easy to simulate and exercise a website. It would be trivial to traverse the element tree to inspect element sizes/positions or perform semantic analysis (like search engines would do).

Feeding the website fake user input would also become much simpler, from both the implementor's and API-consumer's perspectives. The simplified design would also make it lighter on memory and CPU time. This makes it much simpler to write automated tests which won't require running a live browser.

Properties

I'm not sure how layout and positioning would work best. The biggest challenge to me seems to be making sure fluid-height containers (whose heights change based on their width) fit in well with other elements around them.

One solution that might work could be to specify element positions as being "relative" to another (non-containing) element. So if element A has content that may change its height as the window resizes, and element B sits below it, element B's y property is a function that returns a value calculated based on element B's y and height properties.

This technique will move much work off the shoulders of the rendering engine, and put a lot more flexibility into the hands of developers.

Other than that, I imagine layouts will themselves be pretty straight-forward to come up with. Fortunately it seems pretty orthogonal to the rest of the design I'm proposing, giving us time to give it more thought.

Events

I think the way current browsers handle events is pretty good overall and I wouldn't change much about it, if anything. Event-handlers could simply be properties within a top-level "events" property on a relevant element-object.

The hierarchy of elements would be implemented via the "children" property of an element. A property could be dedicated to specifying what semantic "roles" an element has. The virtual machine would know about certain "roles" and find objects matching that role (specified via some property) to delegate certain events to it. For example, every element with a "resizeable" role would get notified when the window resizes.

Portability

Because this is a virtual machine, portability across operating systems isn't a problem; by "portability" I'm talking about how it renders on different devices.

This is very related to "units" (px, em, %). We probably only need two types of units, absolute and relative. The question about absolute units is what to base them on, and I just don't know. This answer requires more experience than I have.

I'm totally unsure how we should handle rendering differently on different devices.

Delivery

Since this sits on top of HTTP, servers could deliver this bytecode along side HTML, maybe on port 2013 or something to start with. Browsers for this web would hide the port just like current browsers hide port 80. The current web would continue on as normal while the new one grows "in the background".

"Normals"

One major benefit of this simplified design is that it gives regular developers like you and me a chance to get our foot in the door helping out. It would no longer take an elite squad of programmers or a powerhouse like Google or Mozilla to create a browser, anyone with a few free weekends could probably do it.

The hardest part would probably be implementing the virtual machine and the runtime functions, but I imagine third-party libraries in all the major languages (Java, C++, Ruby, etc) would start showing up pretty soon, and that's really the brunt of the work. Then we'd just start developing third party tools (which we're already doing quite a lot of) that simplify the development process.

Some questions I've been asked

  1. This sounds similar to Smalltalk Pharo or it's virtual machines.

    Conceptually it's more similar to the DOM, but with the functionality of HTML and CSS built-in, and represented in bytecode instead of raw JS. This partially puts the brunt of optimizing it on the servers rather than the client, but maybe that's a good thing.

  2. This is basically what Java was supposed to be right? Alan Kay would agree with you that what we need is not a browser, but a VM. So I guess the real question is "How do we solve the problems that killed Java on the web?"

    Java tried to be a whole OS, not just a browser. This proposal is conceptually much closer to what the DOM looks like after applying HTML/CSS/JavaScript, and that's why I think it'll work.

About me

My name is Steven Degutis, and I've been writing software professionally for almost a decade. During that time, I've written many apps and websites, quite a few techical articles, and kept up-to-date with the rapidly evolving software industry.

If you have software needs for web, mobile, or desktop, and are looking for a seasoned software professional, please reach out to me at sbdegutis@gmail.com to set up a phone call.

Work Experience

  • Self-employed – present
  • Clean Coders – 5 years
  • 8th Light – 2 years
  • Big Nerd Ranch – 1 year
  • Self-employed - 1 year

Platforms

  • Web: full-stack
  • iOS (UIKit)
  • macOS (Cocoa)
  • REST APIs
  • AWS / EC2 / ELB

Languages

  • JavaScript
  • HTML5 / CSS
  • Swift
  • Objective-C
  • Clojure

Frameworks

  • Node.js
  • Express.js
  • React
  • Vue.js
  • Electron

Technical articles

Over the past decade, I've written a total of 169 technical articles on various programming languages, frameworks, best practices, and my own projects, as I kept up-to-date and active in the software industry.

Subscribe via RSS / Atom.

Chronological

Portfolio

Here are some of the projects I'm most proud of. They were created using a variety of technologies, running on several different platforms and OSes. They're all finished products, and many of them are open source.

CleanCoders.com

Website - Online Video Store

I wrote this web store for Robert "Uncle Bob" Martin, using Clojure for the back-end, and JavaScript for the front-end. Over the course of 5 years, I took the site from a simple three-page website to a full enterprise-ready business solution, with nearly 100% test coverage.

  • Clojure
  • Datomic
  • jQuery / D3.js
  • JavaScript
  • ClojureScript

Docks

macOS app - Dock Utility

I made Docks in 2009 for users who wanted to swap out icons in their Dock with a single click. Its unique functionality and design aesthetic attracted the attention of Apple, Engadget, MacWorld, and led to an acquisition of my start-up by Big Nerd Ranch.

  • Apple.com Staff Pick
  • MacWorld 4/5 Rating
  • MacWorld Gem of the Year
  • Featured on Engadget.com

Leviathan

macOS app - Clojure IDE

Source Code

While working on CleanCoders.com, a website written completely in Clojure, I increased my productivity by building a custom IDE for macOS designed specifically for Clojure projects.

  • Objective-C
  • Clojure
  • C / C++
  • Cocoa
  • Themeable

Zephyros

macOS app - Hackable Automation

Source Code

This began as an experiment to see how many languages I could use to script a custom macOS window manager using our custom TCP protocol. Eventually it had bindings for Clojure, Ruby, Python, Go, JavaScript, CoffeeScript, Node.js, Chicken Sceme, and Racket, as well as other community additions.

  • TCP / Unix sockets
  • Custom protocol
  • Highly Scriptable
  • 10+ language bindings
  • Open source community

Bubble Maker

iOS app - Bubble simulator

This toy was made in a weekend to entertain my 1 year old daughter. It lets you create bubbles with your fingers, which then simulate physics by bumping into each other and falling.

  • SpirteKit
  • Custom art
  • Physics simulation
  • iOS
  • tvOS

Quick List

iOS app - Todo list app

When I couldn't find an app in the App Store that let me make very simple lists extremely quickly, I made one myself. I use it almost every day to organize and track my activities.

  • In-app purchases
  • Custom UI / UX
  • Social media
  • App Store artwork
  • Spring animations

sdegutis.com

Website - Personal Portfolio

Source Code

This very site itself was written from scratch in about a day. It uses best practices for modern responsive web design, and a custom build phase to compile the sources into a single HTML file.

  • Node.js
  • Pug / Jade
  • LessCSS
  • HTML5
  • WebSockets

2048

Java app - Game

Source Code

The game 2048 (created by Gabriele Cirulli) is so fun that my kids wanted their own copy. So I wrote this version in Java 8, using JavaFx for attractive graphics and silky smooth animations.

  • Java 8
  • JavaFx
  • Modular code
  • Customizable
  • Animations

Mjolnir

macOS app - Window Manager

Source Code

I created this app to increase my productivity by letting me move windows around in macOS using keyboard shortcuts. It grew into a community-driven highly extensible app, using Lua for its plugin system.

  • Objective-C
  • Embedded Lua
  • Plugin system
  • Fully documented
  • 5,000 GitHub stars

AffluentConfidante.com

Website - Social Network

Implementing this elite social network gave me experience integrating both Apple Pay and credit card payments (via Stripe.com) seamlessly into web apps, for a frictionless and pain-free payment experience.

  • Clojure
  • Elastic Beanstalk
  • PostgreSQL
  • Stripe.com
  • Apple Pay

HyperChat

Website - Live Chatroom

Source Code

This isn't just any chatroom. In this web app, you can see what everyone is typing while they type it. I made this in order to scratch my itch for making real-time apps and games, and learned how to use WebSockets in the process.

  • JavaScript
  • WebSockets
  • Node.js
  • Vue.js
  • CSS

Bahamut

macOS app - Music Player

Source Code

As iTunes went through many user interface changes, I wanted an app that was consistent, intuitive, and easy to use. So I created Bahamut, a minimal music player for macOS with a custom user interface.

  • Objective-C
  • Custom UI
  • Cocoa
  • Core Data
  • AVFoundation

Chatter

macOS app - Chat (IRC) Client

Source Code

This was written in 2009, before the time of Slack, when IRC was the main way for programmers to get short-term assistance from each other. Its purpose was to be a beautiful app with an emphasis on simplicity and usability over technical power.

  • Async networking
  • Core Animation
  • Core Text
  • IRC Protocol
  • UI Design

AppGrid

macOS app - Window Manager

Source Code

This is an app I actually use every single day. It lets you move windows with global keyboard shortcuts. Since it uses Vim-like key bindings, it should feel pretty natural to any programmer. There's no configuration needed; it Just Works™.

  • Minimalist UI
  • Simple UI
  • Vim-like Hotkeys
  • Global Hotkeys
  • Zero-configuration

Hydra

macOS app - Lua window manager

Source Code

As an evolution of Phoenix, Hydra was my first attempt at embedding a full Lua virtual machine into an Objective-C app, to make a lightweight and efficient window manager that focused on speed, low memory usage, low CPU usage, and overall being gentle on laptop batteries.

  • Embedded Lua
  • Generated docs
  • Lightweight
  • Memory efficient
  • CPU efficient

Phoenix

macOS app - JavaScript window manager

Source Code

As an evolution of Zephyros, Phoenix was my attempt to use Cocoa's native JavaScript bindings to make a more lightweight and efficient window manager, that focused on speed, low memory usage, low CPU usage, and overall being gentle on laptop batteries.

  • JavaScriptCore
  • JavaScript API
  • Lightweight
  • Memory efficient
  • CPU efficient

Smaller projects

These may be tiny, but they're interesting technical feats.

Lua4SwiftSwift framework for embedding Lua with a native Swift API.
chooseCommand line fuzzy-matching tool for macOS that uses a GUI
musicCommand line music daemon for macOS that only speaks JSON
hectoCommand line text editor with an embedded Lua plugin system
ZephSharpWindow manager for Windows using Clojure for scripting
managementMinimalist EC2 configuration & deployment tool in Ruby.
go.assertAssertion helper package for writing tests in Go.
go.shattrGo library for printing shell-attributed strings to stdout.
OCDSpec2Objective-C based testing framework with Xcode integration.