> Now that conventions are moving towards ‘single-page’ web apps, the concept of a ‘page’ is losing its special meaning.<p>The web is <i>so</i> broken. The whole "web app" concept is just a giant hack.<p>The job of us web developers today consists in employing a never ending pile of hacks (e.g. AJAX, long-pooling, semi-broken languages and implementations, non-standard vendor APIs) to fight a browser into submission so it can be used to run a general application instead of simply navigating hypertext, it's original purpose. All that because there's incentive in keeping users inside walled gardens and holding a ransom on their data.<p>It's unbelievable we take as granted reinventing the wheel <i>over and over again</i>, dealing with weak standards and APIs designed by committee, fighting browsers into rendering interfaces and invoking the right callbacks.<p>I would rather take a web based on open APIs and rich clients (running native code) than the kludges we have today. The trend around mobile apps and some very successful native apps on the Mac App Store that consume web services seems to me as a best-of-two-worlds approach.<p>> I have a hunch that WebDAV combined with standard HTTP authentication could be the answer. I’m not 100% sure on it, but I can easily envision a world where you fix bugs in your website by opening it up in a browser, reading a stack trace, fixing the JS in that same browser and persisting your changes back to the server.
> I dream of the days when the Web truly does resemble SmallTalk.<p>This would be more like a world with 5 different SmallTalk implementations, each slightly different, and all with a crappy/non-existant standard library and security model.
Chris Granger's Light Table is also trying to do it. Of course, Bret Victor's talk breathed new life into this whole thing. But everything old is new again.<p>People want to build software from a small kernel that scaffolds itself. They want to immediately switch between "testing the app" mode and "building the app" mode. They want something more than a text file, a tool pipeline, and an executable at the other end. On the other hand, they don't want their code to turn into an opaque binary blob that can't be diffed, can't be read by text tools, and can't be shared with people who don't feel like using your sweet "Invented on Principle" tool.<p>It feels like we're converging on the ideal solution, but it's happening more slowly than I think many of us predicted.
This kind of hot-swapping can be achieved on quite a few languages; certainly Perl and Ruby in addition to JS, and I'm sure there's a dozen more languages that allow you to redefine at runtime. The difference is that Smalltalk made hot-editing
the default.<p><i>SmallTalk is an uncommon language these days, with the exception of its half-descendant, Objective-C.</i><p>Ruby borrows Smalltalk's OO semantics pretty much completely. Just sayin'
It only makes sense if you talk about utility webapps (like twitter). Not everything is a webapp though. Wikipedia for example, is just a display of documents. Should it become a fancy webapp? I don't see much benefit in it.<p>The old page concept is plenty fine in many contexts IMO.
I read the title and had some first thoughts spring to mind, and didn't reach the same conclusion as the author. While cool it was, it was limited in reach, and I think you could go further with this analogy.<p>Treat every web site or address or endpoint as an object. Allow message passing as though the web were simply a single object-oriented system resident on the same computer. The definitions of the APIs are kept as standard, so the system "just works" with any site.<p>This is, of course, the vision of APIs. But could we do better? Could we make it closer to a true object-oriented system, even simpler to use? Not sure if it would make a big difference, but as we know, sometimes a simple thing that makes connections easier can make a huge difference (eg: XmlHttpRequest).<p>Make the web as easy as smalltalk. For <i>every</i> API, and eventually, every site. Not just the ones we decide to make language-specific libraries for. One library per language just interfaces with "the web" as a fully-generic API you can access as easily as any object.<p>Just thought I'd share this thought. Any thoughts or ideas?
I can't believe that the fact that Chrome can hot-swap code is surprising to anyone... Have you never been working on an app, opened up the console, changed a variable or function definition and seen the effect in real time?
I felt this way when I first saw better_errors: <a href="https://github.com/charliesome/better_errors" rel="nofollow">https://github.com/charliesome/better_errors</a><p>It's a little surprising how much we keep reinventing.
Check out Seaside, the Smalltalk web framework. It has a edit-in-the-browser mode, where you can pretty much edit anything to make your web app work. Seaside itself is a component-centric framework, not page-centric as most web frameworks are. You build independent components, which you place here and there to make your app.
Another approach to this type of thing worth checking out is Dan Ingall's Lively Kernel <a href="http://lively-kernel.org/" rel="nofollow">http://lively-kernel.org/</a>
I recently tried out the binary at squeak.org. It was recommended to me when I described to some people what I'm trying to create (a system for building software using which you can improve itself).<p>It was very neat, and so easy to try out. You essentially download it, run it, and it's like a mini-operating system running. You can inspect the system itself and make changes, and then save/load these images. Basically what the article described. There are definitely some very good ideas there. Unfortunately, it wasn't easy for me to figure out how to write some simple programs that print stuff to standard output, and I couldn't really find any samples online. It really makes me appreciate golang.org's Hello World sample right on the front page.
It's not the web. The web is presentation-independent semantic information rooted at stable URLs. Single-page javascript is a poorly-planned delivery platform for applications with essentially siloed state that is steadily <i>displacing</i> the web, and no amount of grafted-on functionality can enable the kinds of repurposing and unanticipated reuse we started building before writing off the web as insufficiently shiny.
> Well, the way I (and Roy Fielding) see it, the browser is a stateful agent that just renders HTML to a viewport, and executes JavaScript.<p>I cringed.
I was expecting to see a comparison between stateful object and server and method calling as message passing and api call.<p>So I was surprised but also disappointed: to anyone who has worked with a REPL for instance it's not a big deal to hot swap piece of code. Many programmers use Emacs and do that almost daily in their text editor… And that's how the web was first designed (the first web browser, Mosaic, allowed to edit the page you were visiting, much like giant and distributed wikis or, with nowadays dynamism in web pages and services, much like giant and distributed Lisp machines or Smalltalk images).
An editor that might no be too well known in the web world, Unity3D's editor, has an awesome way to edit code on the fly. Public variables are represented as generalized form controls like sliders and dropdowns. Very nice for the later phases of development. Tweaking the timing and speed of an animation or the effects of some physics float can be a pain without being able to change on the fly. I wish the web tools had a similar setup.<p><a href="http://docs.unity3d.com/Documentation/ScriptReference/Editor.html" rel="nofollow">http://docs.unity3d.com/Documentation/ScriptReference/Editor...</a>
And this makes Cross-Site Scripting even more fun then it already is! We can't even make the browser limit sharing across websites securely: what makes you think that this edit mode will not be a target?
I'm surprised nobody has mentioned Meteor yet. As far as I understand, developing for Meteor means having a single codebase that erases the distinction between server and client.<p>Your web pages become live views of the underlying controllers. Modifying state in one client automatically modifies it in another. And I'm pretty sure it supports hot-swapping.<p><a href="http://meteor.com/" rel="nofollow">http://meteor.com/</a>
While a lot of the comments here are focussing on other aspects of the article, I think the most basic actionable takeaway is we need a simple method of persisting changes made in Firebug/Developer Tools to the code. Once mentioned, it seems like a no brainer - why doesn't this already exist?
Web development is nuts! We <i>need</i> new web tools and stop trying to fit round pegs into square holes.<p>Too much effort is wasted working around old obstacles.<p>Javascript was meant as a bridge to a Java based browser. That never happened and we're just left with the afterbirth.
>I’m not 100% sure on it, but I can easily envision a world where you fix bugs in your website by opening it up in a browser, reading a stack trace, fixing the JS in that same browser and persisting your changes back to the server.<p>Where does version control fit in this vision?
Tim Felgentreff did some cool work on remote debugging with MagLev. The video is pretty sick:
<a href="http://blog.bithug.org/2011/09/maglev-debug" rel="nofollow">http://blog.bithug.org/2011/09/maglev-debug</a>
You might try looking at <a href="http://amber-lang.net/" rel="nofollow">http://amber-lang.net/</a> as a test for your ideas. It's a Smalltalk implementation running in JavaScript.