The Web is the most approachable application platform I have used, at least when it comes to customizing the look of an application. HTML gives you structure, CSS gives you presentation and JavaScript lets you manipulate both dynamically.
The Web is far from perfect however, as you dig deeper and deeper into Web APIs and the tools available for the platform, you quickly find potential pitfalls and gotchas in both the apis and the tools.
You can tell there is still quite a lot of work to be done to make the platform more productive for development.
These are some ideas and observations that have been floating around me head for some time.
Exportable developer console logs.
I was surprised to find out that neither Chrome nor Firefox provides a way to download console output other than copy and paste.
This is disappointing, after all when browsers crash users are prompted to send an error report to the vendor. So it’s known how important getting back that stack trace is.
It may be time for a more advanced client side logging system on the whole. Something that can not only export logs, but with persistence as well.
Aside from localStorage, browsers could reserve some disk space so applications can save their
log output for future debugging. Say 1-2MBs rotated
at regular intervals with a 3 month retention period.
Web apps that want more space or don’t want their logs overwritten could have the browser prompt the user.
I have confidence though, that as the Web platform matures, we will see some development in this area.
After all developer tools have come a long way in both Chrome and Firefox.
Built in modals dialogs
We all hate visiting a site and a window pops up; blocking the page content, demanding we pay attention to something we don’t care about.
Modal dialogs in front of copy is like someone snatching a newspaper from you to ask you to sell you Organo Gold.
Not very user friendly.
However, in the context of Web applications, they are very much welcomed as they help us keep interfaces cleaner, inform users of errors, warnings or results in a way they can’t overlook.
Which is why it’s a shame all browsers give us
are alert(), prompt() and confirm().
I mean it’s great they exist but they are not very customisable.
You can’t style these dialogs and in the case of confirm() you are limited to a single text field for input.
Use the CSS
Sure, you can create your own dialogs via CSS with a little JavaScript here and there. But that’s work.
Now the developer has to worry about crap like responsive design, positioning and the various bugs you run into when implementing modals.
Of course there are libraries/frameworks that handle all this for you, but finding the right third party web framework can be a nuisance.
This ties into the next point:
A browser SDK
The DOM should be abstracted away!
Application developers should not have to deal with DOM manipulation directly.
document.getElementElementById, DOMElement.innerHTML etc. contaminate the flow of your business logic if you ask me.
That’s why we utilize frameworks like Angular, React, Ember and so on, because they help us focus on business logic and abstract away the parts that get messy easily.
Great!
However if Web browsers are to be really seen as an application platform they need to do more in this area.
I’m not suggesting browsers replace or bundle popular frameworks (though I do think it’s time Web browsers come with package managers) but rather provide a default SDK over the DOM so developers can start building useful apps without having to go framework hunting.
Ideally, that SDK would be standard across all browsers to avoid as much as possible, incompatible apps.
Let’s not recreate the situation with browser addons.
On the surface, the DOM and JavaScript APIs feel like an SDK, however the deeper you dive the more you realize that it’s just a collection of code.
Barely a library in some parts.
I imagine a JavaScript browser SDK might allow us to write something like this:
import {editors} from '<browser>';
import {html} from '<browser>';
import {layouts} from '<browser>';
var editor = new editors.Markdown(this);
var output = new html.IFrame(this, options);
var view = new layouts.Grid(2);
view.add2Row(0, editor);
view.add2Row(1, output);
document.render(view);
In the above code, ‘
The code that follows would create a 2 row grid
where the first row is a markdown editor and the
second an iframe that displays what the user types.
The styles and associated html would be built in already.
If you develop mobile apps, this syntax may seem familiar. Mobile platforms usually have SDKs to help developers adopt them as quickly as possible.
The Firefox OS SDK is the closest thing the Web has to match this (from what I have used) and hopefully it really grows beyond mobile phones.
Get out of the way mode.
This sort of already exists in the form of the Manifest for Web application spec.
This is great! Not much to talk about since there is some activity in this area.
Basically Web applications should have some way of telling browsers “I am a Web application not a Web page. So please treat me like a Web application!”.
What I’d like to see though, is rather than having to depend on specifications like CORS applications just ask the user if it’s ok to send http requests where ever and whenever we want.
Regular TCP won’t hurt either.
Apparently FireFox OS does support this but it’s not on the standard track just yet.
Let’s hope this changes in the future.
Some of the points of the above ideas are already being addressed in Mozilla’s Firefox OS push.
It will be interesting to see how things turn out, as the often considered broken Web continues to smoothen itself out and take Web browsers along with it (Or maybe it’s the other way around).
Abstraction and tooling are to me, the most important aspects of building powerful software. Hopefully we see more of both on the Web platform.