

The Web Is Becoming Smalltalk - zacharyvoase
http://zacharyvoase.com/2013/02/10/smallweb/

======
hcarvalhoalves
> Now that conventions are moving towards ‘single-page’ web apps, the concept
> of a ‘page’ is losing its special meaning.

The web is _so_ broken. The whole "web app" concept is just a giant hack.

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.

It's unbelievable we take as granted reinventing the wheel _over and over
again_ , dealing with weak standards and APIs designed by committee, fighting
browsers into rendering interfaces and invoking the right callbacks.

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.

> 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.

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.

~~~
crazygringo
> _I would rather take a web based on open APIs and rich clients (running
> native code) than the kludges we have today._

But that exists. It's called native programs, which are free to access web
API's and whatnot just as much as any browser is.

The whole point of the web is you _don't_ have to download software, you
_don't_ have to store your data locally. Sure, it's a pain to support the
quirks of different browsers and some badly designed web standards, but I'll
take that any day over having to program for entirely different _operating
systems_. I fail to see how web apps are a hack at all. Sure, they're not the
"original purpose" of the web, but they work awfully well for things like
GMail, GDocs, GMaps, etc. -- I'm awfully happy to have all these inside of
browser tabs, instead of cluttering up my machine with more installed apps.

~~~
hcarvalhoalves
> I fail to see how web apps are a hack at all. (...) Sure, they're not the
> "original purpose" of the web, but they work awfully well for things like
> GMail, GDocs, GMaps, etc.

Well, you realize all the products you mention were only possible because
someone figured out a hack (XMLHttpRequest), and now _everybody_ relies on
something that wasn't thought out in any shape or form? Can you see how
_fragile_ is the software stack an entire web industry is basing itself on?

Also, I don't find GMail, GDocs or GMaps the epitome of good UI and
interaction models, I can point a handful of quirks (GDocs is particularly
bad.). I don't think these products withstand a round of user testing, people
just take it for granted because they are provided for free. When a better
alternative shows up (Sparrow), people flock to it even if it's a paid app. Of
course, Google killed it, they are web app zealots after all and need the
revenue from the ads.

~~~
bad_user
Arguments about the hacky-ness and fragility of web apps are always extremely
silly.

Unix was also a hack. C was also a hack. Windows 95 was also a hack. Windows
NT had better design, but with hacks bolted on to make it compatible with Win
9X. Java was a hack. Linux was a hack. The Internet itself is the biggest hack
of all.

In fact I dare you to name one successful platform that wasn't a hack. Because
from where I'm standing, the platforms that weren't hacks _failed_ , in
addition to being on the whole horrible.

> _I don't find GMail, GDocs or GMaps the epitome of good UI and interaction
> models, I can point a handful of quirks_

With all those quirks, GMail killed the desktop email client for me. For the
last 4 years I haven't been able to use any other client. Even on my iPad,
before the latest "native" GMail on iOS I was using the web version, simply
because Apple's Mail app wasn't doing threaded conversations well.

For all the quirks of the web version of Google Maps, at least it is available
everywhere. Just ask the poor schmucks that were in a hurry to upgrade to iOS
6.

Same argument goes for GDocs. It's available everywhere and it allows for
efficient collaborative editing. You just open a browser and you're good to
go. It doesn't even have to be _your_ browser. I do value this a lot.

> _I don't think these products withstand a round of user testing, people just
> take it for granted because they are provided for free._

I'm a Google Apps customer and I also pay for Google Drive, if it matters. And
quite the contrary, people receiving stuff for free tend to be more self-
entitled and critical. That people don't voice too many negative opinions on
these products is kind of shocking, because either Google has a really good PR
department or these products do in fact satisfy most users.

> _When a better alternative shows up (Sparrow), people flock to it even if
> it's a paid app_

For what is worth, I didn't.

~~~
yuhong
On the Windows 95 "hack": [http://yuhongbao.blogspot.ca/2012/12/about-ms-
os2-20-fiasco-...](http://yuhongbao.blogspot.ca/2012/12/about-ms-
os2-20-fiasco-px00307-and-dr.html)

------
breckinloggins
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.

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.

It feels like we're converging on the ideal solution, but it's happening more
slowly than I think many of us predicted.

~~~
seanmcdirmid
Its not the same. Light Table and Bret's demos go way beyond what Smalltalk
ever did. Its not just about hot swapping, but liveness, and the Smalltalk
community never got that [1]. But it doesn't stop them from saying they've
already done it because they don't understand what they are seeing, and
thinking is hard.

[1] John Maloney got it with Morphic, and even coins the term Liveness at
about the same time Tanimoto does. However, this was originally in Self and
relatively independent from Self's hot swapping capabilities. It also didn't
really map back to code very well (it was very dependent on direct
manipulation via Morphic's edit menu).

~~~
fractallyte
More than (almost) any other language/environment, Smalltalk _is capable_ of
this kind of 'liveness'. That it hasn't been implemented in the way you refer
is due more to a lack of development effort than anything else.

For the last four decades, Smalltalk has been providing a glimpse of the
future. That future is still waiting to happen.

~~~
seanmcdirmid
That's a vacuous statement if I've ever heard one. Nothing in Smalltalk makes
achieving liveness easier than say Java or, more obviously, a language with
very encapsulated state like Erlang, and definitely not various visual
languages where you get liveness for free (Quartz Composer!). It's telling
that Granger et al are basing Light Table on Clojure/Lisp rather than
Smalltalk (it will be interesting to see what Bracha does with Newspeak,
however). Also consider various game editing engines (Unreal, Unity) that
offer live scene scripting capabilities in whatever scripting language and C++
they support.

Smalltalk was crazy innovative, while Self (Smalltalk's only real successor)
gave us the first live graphics toolkit (Morphic). But the future is still
being invented, and it will be a much better experience than Smalltalk ever
was.

~~~
fractallyte
Smalltalk is capable of evaluating statements as they're entered, and it's a
relatively small step to reflect those changes immediately on compilation -
thus, 'liveness', as in Light Table. I can't imagine being able to do that in
Java.

If I'm missing something, can you please provide some more detail?

~~~
seanmcdirmid
Liveness is an experience, hotswapping is a mechanism that gets you 5% of the
way their. Its like saying "we've done 5% of the work ,the rest of the 95%
should be easy right?" Actually, just figuring out what the experience is
difficult. So more details...

Hancock defines the term "live programming" in his thesis [1] and its where I
get my definition from (before Hancock, the term doesn't exist, though
liveness was defined by Tanimoto and Maloney in the 90s). Basically, live
programming is about continuous feedback for which hot swapping might be
useful (though it must be said its not exactly necessary nor is it
sufficient). But there is much more to it: you want continuous feedback about
the code you are editing, not just some idea that the code will run sometime
in the future in a running program. You want to also observe the behavior of
this code in a way that is comprehensible, and map this behavior back to your
code.

I wrote and presented a paper [2] on live programming back in 2007. Ralph
Johnson (a big Smalltalker) was in my audience and had the same complaint: he
only saw hot swapping and not the experience I was presenting. To him, it was
mechanism, not exeperience. I wonder if this is a problem with Smalltalkers in
general.

[1] <http://llk.media.mit.edu/papers/ch-phd.pdf>

[2]
[http://research.microsoft.com/apps/pubs/default.aspx?id=1793...](http://research.microsoft.com/apps/pubs/default.aspx?id=179365)

~~~
fractallyte
I understand the difference between 'hot-swapping' and 'liveness'. However
(admittedly, I may be mistaken) I believe the Smalltalk architecture already
has the requisite functionality (eval and reflection - just like Lisp) to
support this, although no one's actually implemented it yet. (And it ought to
be more straightforward than building it in a Lisp-to-Javascript compiler on
top of a Lisp on top of the JVM!)

Some of the basis for my assertion came from this article:
[http://liveprogramming.github.com/liveblog/2013/01/13/a-hist...](http://liveprogramming.github.com/liveblog/2013/01/13/a-history-
of-live-programming.html)

~~~
seanmcdirmid
Any Turing-complete language has the requisite functionality to support
liveness, but something like Time Warp support by the OS/VM would make it
easier. But honestly, at this point, even designing the experience (vs.
implementing it) is hard enough, and we owe a lot to Bret Victor's talk here.
Hancock's thesis sets high standards on how the feedback must be
comprehensible (as opposed to some random lights flashing on and off).

I wrote a lengthy post in the history article you linked to. Its just not the
live programming history that I'm familiar with, they seem to be falling into
the same smalltalk mechanism trap that I was talking about in this thread.

------
gamache
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.

 _SmallTalk is an uncommon language these days, with the exception of its
half-descendant, Objective-C._

Ruby borrows Smalltalk's OO semantics pretty much completely. Just sayin'

~~~
norswap
You can even do it in Java with Eclipse (Notch did it during his screencast),
although I don't know the specifics.

~~~
seanmcdirmid
Notch used a special programming framework to get their. Many game engines
support similar features; the ability to modify the game world while its
running, and can even do that with C++. The problem is you don't get it for
free (framework transparent hot swapping isn't good enough), and its only
because of special compromises made in the framework that you can get liveness
at all.

------
chewxy
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.

The old page concept is plenty fine in many contexts IMO.

~~~
malandrew

        The Browser — A Lament
    
        *Binstock:* Still, you can't argue with the Web's success.
    
        *Kay:* I think you can.
    
        *Binstock:* Well, look at Wikipedia — it's a tremendous collaboration.
    
        *Kay:* It is, but go to the article on Logo, can you write and execute Logo programs? 
        Are there examples? No. The Wikipedia people didn't even imagine that, in spite of the 
        fact that they're on a computer. That's why I never use PowerPoint. PowerPoint is just 
        simulated acetate overhead slides, and to me, that is a kind of a moral crime. That's 
        why I always do, not just dynamic stuff when I give a talk, but I do stuff that I'm 
        interacting with on-the-fly. Because that is what the computer is for. People who 
        don't do that either don't understand that or don't respect it.
    
        The marketing people are not there to teach people, so probably one of the most 
        disastrous interactions with computing was the fact that you could make money selling 
        simulations of old, familiar media, and these apps just swamped most of the ideas of 
        Doug Engelbart, for example. The Web browser, for many, many years, and still, even 
        though it's running on a computer that can do X, Y, and Z, it's now up to about X and 
        1/2 of Y.
    

ref:
[http://www.drdobbs.com/article/print?articleId=240003442&...](http://www.drdobbs.com/article/print?articleId=240003442&siteSectionName=architecture-
and-design)

------
calinet6
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.

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.

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).

Make the web as easy as smalltalk. For _every_ 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.

Just thought I'd share this thought. Any thoughts or ideas?

~~~
njharman
You just described http. Every URL is am object and the post,put, et al are
the messages.

------
CoryG89
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?

~~~
error54
I'm with you on that. It's the surprising the number of web developers who are
just now finding out about this which leads me to another questions, what
tools do they use if not Chrome Developer tools?

~~~
shurcooL
I imagine a text editor, terminal, browser, and a lot of Alt/Cmd+Tab,
F5/Cmd+R, Ctrl+C+up+enter. But I can't say for sure.

~~~
error54
Those are general tools. I want to know what tools people use for debugging
Javascript that are similar to Chrome Developer tools or Firefox's Firebug.

~~~
cdcarter
I believe the implication there was that the debugging process is "try, try
again".

~~~
error54
Haha ah thanks for the clarification cdcarter. That is a process I know all
too well when debugging code in Internet Explorer 8.

------
phillmv
I felt this way when I first saw better_errors:
<https://github.com/charliesome/better_errors>

It's a little surprising how much we keep reinventing.

~~~
codewright
Stuff like that has been in Python for a long time. (Werkzeug)

~~~
phillmv
That sounds like a clone of Rack, that doesn't support the latest version of
Python.

~~~
codewright
Few that aren't running a charity use Python 3 in production web apps.

Rack <-> WSGI

Werkzeug is just an app server on top of WSGI that happens to be very nice,
with features like the above described.

------
vincie
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.

~~~
doublec
Clamato, also from Avi Bryant, is an interesting approach to in browser
development: <https://bitbucket.org/avibryant/clamato/wiki/Home>

~~~
fractallyte
Clamato has been superseded by Amber: <http://amber-lang.net/>

In particular, check out the tutorial page (Smalltalk in a browser!):
<http://amber-lang.net/learn.html>

~~~
doublec
Oh, very nice, thanks!

------
lispm
The language is written as 'Smalltalk', not 'SmallTalk'.

------
russellallen
Another approach to this type of thing worth checking out is Dan Ingall's
Lively Kernel <http://lively-kernel.org/>

~~~
robertkrahn01
Great to see LK come up here. Yes, the approach of Lively goes towards what is
mentioned in the article, right now however, the client session (what you run
in the JS VM in your browser) is what the image is for Lively. We developed a
persistence mechanism that will read/write a JS object graph so that your
working state of your session can be saved and resumed, just like a Smalltalk
image [1].

We are currently experimenting in distributing LK runtimes in nodejs instances
so that basically a network of active runtimes can be created that communicate
/ exchange objects.

Note that the core development moved to github [2].

[1] [http://www.hpi.uni-
potsdam.de/hirschfeld/publications/media/...](http://www.hpi.uni-
potsdam.de/hirschfeld/publications/media/LinckeKrahnIngallsRoederHirschfeld_2012_TheLivelyPartsBinACloudBasedRepositoryForCollaborativeDevelopmentOfActiveWebContent_IEEE.pdf)

[2] <https://github.com/LivelyKernel/LivelyKernel>

------
shurcooL
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).

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.

~~~
jcromartie
Yeah, Smalltalk and stdin/stdout don't usually go together, unfortunately.
Smalltalk is just not designed to be a part of the UNIX ecosystem, since it's
a big environment and not a small purpose-built program.

And I'd also recommend Pharo over Squeak at this point, since they have been
aggressively improving the Squeak project and creating their own clean modern
Smalltalk.

If you want to use Smalltalk for UNIX-style scripting, I'd suggest GNU
Smalltalk.

------
prodigal_erik
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
_displacing_ 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.

------
_pmf_
> 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.

I cringed.

------
emp
I hate to be picky, but it's Smalltalk, not SmallTalk.

------
p4bl0
I was expecting to see a comparison between stateful object and server and
method calling as message passing and api call.

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).

------
dominic_cocch
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.

[http://docs.unity3d.com/Documentation/ScriptReference/Editor...](http://docs.unity3d.com/Documentation/ScriptReference/Editor.html)

------
wbl
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?

------
mshron
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.

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.

<http://meteor.com/>

------
neil_s
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?

~~~
simon_thepiman
There is something called firefile that will save your css changes made in
firebug but when I used a year or so ago it was a little buggy and stripped
comments out of css (breaking WP Sites).

I'm working on a WordPress editor called WPide, live css/less editing is
something I have planned. When your code editor is part of your website/app I
think there is a lot more scope for improving the editing process.

With the current code on github I'm in the middle of implementing git
functionality, just struggling with the push/pull side of things, ssh keys
specifically.

I did have a concept in place for live editing of css without constant round
trips to the server by passing data over cookies. This was some time back,
I've since realised HTML 5 has much better ways to achieve that communication.
That was when I planned to have the css editor in a different browser window
but it might be easier to move the css editor panel onto the front end as a
small panel like firebug/inspector. I've got code completion for PHP and
WordPress so don't see why css can't be auto completed as well.

I kind of thought creating an editor built with PHP, HTML, javascript and css
would make it easier for people to get involved and create a really good
editor that was moldable by any develope but as yet no one really seems to get
excited about a Web based editor and probably think I'm wasting my time but
I'll plod on..

------
dusty_dex
Web development is nuts! We _need_ new web tools and stop trying to fit round
pegs into square holes.

Too much effort is wasted working around old obstacles.

Javascript was meant as a bridge to a Java based browser. That never happened
and we're just left with the afterbirth.

------
mistercow
>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.

Where does version control fit in this vision?

~~~
shurcooL
Assuming you have access to the repo, it can be pushed either to master or
another branch of your choice.

If you don't, a fork is automatically created.

------
jc00ke
Tim Felgentreff did some cool work on remote debugging with MagLev. The video
is pretty sick: <http://blog.bithug.org/2011/09/maglev-debug>

------
jhonicker
You might try looking at <http://amber-lang.net/> as a test for your ideas.
It's a Smalltalk implementation running in JavaScript.

------
gregmuellegger
So you want your live editing beeing persistent? What about testing? I think
you should first write a test that fails before attempting to fix it...

~~~
emp
Writing a test that fails is a subset of what you can do. Pharo (and other
Smalltalks) support writing traditional test cases and running them in a test
runner. However you can also:

    
    
      - write snippets in a workspace, as vincie mentioned.  
      - write code against an API that doesn't exist, run it, have it fail, and then fill in the API and implementation.  
      - write stubs that fail automatically, and then fill them out (similar to above).
    

The difference is, when things fail:

    
    
      - you get to play with the live objects in a work space.  
      - fill in missing implementation.  
      - fix any errors.
    

And then much of the time continue execution from the point of failure. No
need to restart anything. I simply could not appreciate the variety of options
available in a Smalltalk environment until I used it for some fun projects
over a few months.

Be warned, you might hate your so called modern environments once you get back
to them. For Objective-C coders there is hope: <http://injectionforxcode.com>

------
sutongorin
Are you looking for <http://amber-lang.net/> by chance?

------
indubitably
WebDAV?

Heaven help us…

~~~
DoubleCluster
Why the dislike? It's not a bad protocol.

~~~
chubot
From what I remember, it's pretty chatty. It appears to be on its way out. Is
there any new software that's using it?

WebDAV had some varying levels of support in Windows and Mac desktops. But
AFAIK the Windows stuff got broken; not sure about Mac. I think that access
from a GUI file browser was one of its main use cases in the 90's. If nobody
does that anymore, and I don't think they do, then the protocol will need a
new app or it will continue to die.

~~~
DoubleCluster
I've used it to bolt file storage on a REST API for enterprise stuff. It seems
to be a good fit. I'm even using the Windows WebDAV implementation... working
around its quirks is madness: [http://www.greenbytes.de/tech/webdav/webdav-
redirector-list....](http://www.greenbytes.de/tech/webdav/webdav-redirector-
list.html) Note that XP SP3 has the port-handling bug even though it's not on
that list.

