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.
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.
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.
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
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.
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.
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.
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".
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
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.
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?"
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 firstname.lastname@example.org to set up a phone call.
- Self-employed – present
- Clean Coders – 5 years
- 8th Light – 2 years
- Big Nerd Ranch – 1 year
- Self-employed - 1 year
- Web: full-stack
- iOS (UIKit)
- macOS (Cocoa)
- REST APIs
- AWS / EC2 / ELB
- HTML5 / CSS
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.
- 2017 — "Clean code" isn't actually clean
- 2017 — Passion in your field is overrated
- 2017 — What I learned in 5 days of writing an experimental website
- 2014 — Age of the Polyglot
- 2013 — How to Program
- 2013 — Ignore the Naysayers
- 2013 — Writing Clearly
- 2012 — Reinvent the wheel
- 2010 — Good usability
- 2009 — Twitter is the wrong tool
- 2009 — We're all pretty bad at driving
- 2008 — Why I Code
|March||Notes on Haskell Extensions|
|February||Second thoughts on front-end tools|
|February||First thoughts on front-end tools|
|February||Some thoughts on GUIs|
|February||First thoughts on OCaml|
|February||First thoughts on Haskell|
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.
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.
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.
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.
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.
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.
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.
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.
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™.
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.
These may be tiny, but they're interesting technical feats.
|Lua4Swift||Swift framework for embedding Lua with a native Swift API.|
|choose||Command line fuzzy-matching tool for macOS that uses a GUI|
|music||Command line music daemon for macOS that only speaks JSON|
|hecto||Command line text editor with an embedded Lua plugin system|
|ZephSharp||Window manager for Windows using Clojure for scripting|
|management||Minimalist EC2 configuration & deployment tool in Ruby.|
|go.assert||Assertion helper package for writing tests in Go.|
|go.shattr||Go library for printing shell-attributed strings to stdout.|
|OCDSpec2||Objective-C based testing framework with Xcode integration.|