I’m feeling the programming buzz this morning – not only was Joe Hewitt doing what I’m doing now with DOMBuilder templates-in-code 5 years ago with FireBug’s DomPlate – which I wish I’d known about long before yesterday – but it sounds like he’s looking at some of the same problems I’m looking at now with respect to chasing what, for me, has become a JavaScript web development obsession when my interests shift back towards coding – sharing as much code as possible between the backend and frontend.

The old psynapses started firing when he made these tweets last night:

The new way I’m making web apps is you don’t get to author an HTML file. The “page” is just a JS file. Static markup is pointless now. Then if I need HTML for the Google crawler or something, I run the JS through Node.js to generate the page. Works really well.

In @replies, people are starting to ask the same questions I’ve been asking myself about the best way to set this up:

How do you best generate markup on both ends?

Do you use DOM? HTML? Both?

How do you best hook up events when generating markup from the server side when the code which will run in the browser already knows what the markup will look like?

How do you cleanly handle generating partial changes and rich feedback on the frontend vs. full pages with the same codebase on the backend?

How do you cleanly handle talking to the server for persistence vs. just doing it when you’re running on the server?

In my own attempt to explore some of these questions with Sacrum, I haven’t yet hooked up history on the front end, true persistence on either end, or even a proper model layer yet, but I have a demo written in the style of your standard synchronous web framework which serves you full, working pages from Node.js when you browse with JavaScript turned off and hijacks links and form submissions to do everything with JavaScript when available.

I haven’t yet experimented with how you could nicely handle the approach where you have particular UI components which tightly reflect the current state of a model instance which behaves in the dynamic way you expect of single-page webapps, or even just doing progressive enhancement/registering event handlers for doing so – perhaps it’s enough to get the basic fallback for free via Node.js, I just don’t know how far you can push it yet.

Aside: Fear of Programming

My own investigations are going to force me to finally climb the async wall, lest I hit it. As comfortable as I am with async in the browser, I haven’t yet got my hands truly dirty with the different flavour of async Node.js necessitates, which is going to take some time and motivation to get into (or will it? Perhaps it’s much simpler than I’ve personally built it up to be, a slightly different approach…). I feel like I have a touch of the fear, which is silly in the context of personal projects, but I think it’s rooted in not being able to guarantee that I’ll have the free time and that when I have the time, that I’ll also have the motivation.

I have similar issues with getting into games programming, so it was inspiring to watch notch livestream some utterly fearless coding recently when he was creating his latest Ludum Dare entry. I’m just trying to internalise some of the things I felt while watching that:

It doesn’t have to be right first time.

You don’t need to agonise over every design decision up front – sometimes just doing what feels obvious is all you need to get started, and things will roll naturally from there.

Get something working now, then decide if it’s any good or make it so.

Even if I can’t get there, I’m glad that I’ll at least be able to follow along with someone of Joe’s calibre to see how far the concept can be pushed.