
Smalltalk MVC Translated to JavaScript - tonyg
http://peter.michaux.ca/articles/smalltalk-mvc-translated-to-javascript#r
======
muraiki
If you like Smalltalk and JS, it's worth checking out Amber Smalltalk:
[http://amber-lang.net/](http://amber-lang.net/)

You can even develop interactively in your browser with "live objects" using
an IDE akin to what you'd find in Squeak/Pharo.

------
klibertp
> It is particularly odd to me that the dependents of all instances are stored
> in a dictionary that is a class variable.

Just a note: these are class variables, not class instance variables. Class
variables are a strange thing which is available from both class-side and
instance-side methods. It's nice if you want to have a clean interface to both
single element (via an instance) and to a collection (via a class).

------
DonHopkins
In another post, the author wrote more about his opinions of MVC: Introducing
Maria: The Real MVC [http://peter.michaux.ca/articles/introducing-maria-the-
real-...](http://peter.michaux.ca/articles/introducing-maria-the-real-mvc)

>Why no one else chose to write an true MVC framework, I cannot figure.

Many people have chosen to write true MVC frameworks, so go figure again.

>There is no doubt that the early Smalltalk MVC architecture inspired today’s
MV* frameworks for JavaScript.

Of course, so why did you just figure otherwise?

>My take on it was straight forward.

And wrong.

>The MVC architecture has withstood a 30 year test.

And failed.

>It has passed that brutal test.

How do you reconcile that with your claim that "nobody chose to write an true
MVC framework"? If it passed, then why isn't everyone using it? If people are
only using "impure" MVC frameworks, then why did all those people choose not
to implement "pure" MVC frameworks?

>It is still used for application programming.

So is goto and waterfall design methodology. That's not a good argument.

>It is very useful for browser programming.

As Alan Kay says about MVC programming, "Things seem to hang on in computing
just because they work a little bit."

>Why not take this time-tested architecture and make a JavaScript framework
true to the MVC that is implemented in Squeak Smalltalk and written about in
Design Patterns? My experience with Maria has shown it was a good choice.

No reason why not to try again. Maybe you will be the first person in 40 years
to get it right by being sufficiently "pure"! But on the other hand, maybe
this is a textbook example of "cargo cult programming".

"Pure Smalltalk MVC" in the browser is interesting in the same way that
running UCSD Pascal in an Apple ][ emulator in the browser is interesting.

------
malandrew
Very relevant:

Unidirectional JavaScript talk from Raynos:

[https://www.youtube.com/watch?v=RLAjMeR8898](https://www.youtube.com/watch?v=RLAjMeR8898)

The "framework" used is mercury:

[https://github.com/Raynos/mercury](https://github.com/Raynos/mercury)

I use "framework" in quotes because it's really just a collection of libraries
that work well together.

Here's the todomvc:

[https://github.com/Raynos/mercury/tree/master/examples/todom...](https://github.com/Raynos/mercury/tree/master/examples/todomvc)

All the state in a mercury app is set up first using lenses
(bidirectional/bijective data structure) implemented use:

[https://github.com/Raynos/observ](https://github.com/Raynos/observ)

[https://github.com/Raynos/observ-struct](https://github.com/Raynos/observ-
struct)

[https://github.com/nrw/observ-varhash](https://github.com/nrw/observ-varhash)

If you have any application with state, these three libraries work extremely
well together.

Basically all the views are pure functions that receive the current state of
the app. You can even do "time-travel":

[https://github.com/Raynos/mercury/blob/master/time-
travel.js](https://github.com/Raynos/mercury/blob/master/time-travel.js)

See browser.js of todomvc to see time travel in use:

[https://github.com/Raynos/mercury/blob/master/examples/todom...](https://github.com/Raynos/mercury/blob/master/examples/todomvc/browser.js)

elm-html is also worth checking out:

[https://github.com/evancz/elm-html](https://github.com/evancz/elm-html)

Both mercury and elm-html rely on virtual-dom:

[https://github.com/Matt-Esch/virtual-dom](https://github.com/Matt-
Esch/virtual-dom)

Anyways, small modular libraries FTW!

------
DonHopkins
I asked Alan Kay about his thoughts on MVC:

From: Don Hopkins

I'm interested in knowing more about the evolution of MVC and Morphic, and any
other approaches that people have taken to user interface programming that you
think are important. I've heard about Morphic, but I haven't been able to find
out too much about it on the web. My understanding is that it was originally
written for Self, then ported to Smalltalk. Is it still in development, or has
it morphed into something else? I don't know much about how it works or the
ideas behind its design. What makes it unique and interesting?

There was a discussion on Reddit about "Is MVC the best pattern for web
development", which is something I have strong opinions about and like to
discuss!

I've drawn a lot of my opinions from this fascinating discussion on C2:
[http://c2.com/cgi/wiki?WhatsaControllerAnyway](http://c2.com/cgi/wiki?WhatsaControllerAnyway)

Here's the reddit discussion, which is about how MVC applies to web
development:
[http://www.reddit.com/r/programming/comments/lovjq/is_mvc_th...](http://www.reddit.com/r/programming/comments/lovjq/is_mvc_the_best_pattern_for_web_development/)

The article: [http://feedmyconstraint.wordpress.com/2011/10/24/is-mvc-
the-...](http://feedmyconstraint.wordpress.com/2011/10/24/is-mvc-the-best-we-
can-do-on-the-web/)

I posted a comment whose TLDR summary was "Fuck MVC!" \-- It has a totally
different meaning for web server programming, and in the 32 years since the
term was coined, there have been better ideas.
[http://www.reddit.com/r/programming/comments/lovjq/is_mvc_th...](http://www.reddit.com/r/programming/comments/lovjq/is_mvc_the_best_pattern_for_web_development/c2ug2tp)

There are two different meanings that MVC has these days: user interface MVC,
and web server MVC. User interface MVC has its own problems, the least of
which is being 32 years old. And nobody can agree on what a controller is,
anyway, except that it's the dumping ground for all the brittle junk and
dependencies that none of the other well defined classes wanted.

From: Alan Kay

Things seem to hang on in computing just because they work a little bit.

MVC was originally done at PARC almost 40 years ago. The good part was
philosophical -- the idea to adapt the notion of "cameras" and "worlds" in the
original 3D graphics stuff I participated in at Utah 45 years ago. The bad
part of MVC was how we implemented it -- much too much machinery, etc.

We (my various groups since then, including Viewpoints Research) have not
thought about MVC since, but have used and devised various viewing methods
over the last 20+ years. I like to do views as "watchers" which do not affect
what they are viewing. There are lots of ways to do this. Similarly, I like to
also use "watchers" (context sensitive to the views) to catch needed inputs.
We have never done a really satisfactory automatic inverter for dealing with
the loss of "dimensions" that happen when a view is made (but we have done
some experimental ones).

One important criterion is for end-users of all kinds to be able to easily
make their own views in a very powerful ad hoc way via construction. We have
done a number of adaptations and generalizations of how this can be done in
Hypercard -- and this seems to work well (enough).

Since we always roll our own languages and development systems, we don't care
about problems that other systems might have. For example, we have very little
knowledge about C#, etc. We do try to learn from the few good systems that are
out there.

From: Don Hopkins

When I was living with David Levitt, who worked with Alan Kay at Atari
Cambridge Research, I was snooping around his bookshelves and read through
some of the fascinating notebooks, in which Alan Kay wrote about the idea of a
two way mapping/projection between the model and the view.

It's always seemed to me that the "controller" was just extra baggage, because
the view knew the most about drawing the model, and naturally would also know
what it needed to reverse that projection back from user input through to
manipulating the model. But right now we usually meticulously write the view
drawing and mouse tracking code by hand, without a lot of help from the
system. (That's something I consider a high art form, which I enjoy diong, so
I'd probably be horrified and out of a job it it were too easy! ;)

I think Ben Shneiderman's term "direct manipulation" describes the style of
user interface that Alan Kay was getting at -- or at least DM has to deal with
a lot of the same problems: "continuous representation of objects of interest,
and rapid, reversible, incremental actions and feedback" according to
[http://en.wikipedia.org/wiki/Direct_manipulation_interface](http://en.wikipedia.org/wiki/Direct_manipulation_interface)

By that I mean DM user interface programming could benefit from some kind of
automatic inverter, but usually it's just implemented in an ad-hoc manner,
usually by input tracking code in the view.

I think the way Smalltalk and Self/Morphic use reflection to present editable
user interfaces to objects is another example of a two-way mapping between
projecting the view on the screen, and editing the model via user input.
Booleans whose values you can toggle, numbers whose values you can drag up and
down, color pickers and things like that are all fine and good, but for many
properties it has to fall back to standard widgets that don't know much about
the semantics of the data they're viewing or editing.

I had the opportunity to play around with Sk8 when I was at Kaleida. That
certainly let you drill down, see and modify everything there was in the
system, and it was totally prototype based! Plus it had cool looking windows
with neat shapes, which I like! ;)

I'm curious about what Kay meant by "projection", and what successful examples
there are of automatic bi-directional mapping, and powerful user composition.
I take it that projection is the problem that you lose dimensions and have to
hide information by flattening the structure out onto the screen (via a 3d
projection or scaling or filtering or whatever infovis technique you're
using), and there's no visible place to click or affordance to edit some every
property of an object (or you have to build scaffolding in the form of clumsy
indirect manipulation techniques like browsers, outliners and pop-up menus).

~~~
doublec
I was curious about the thoughts of Morphic vs MVC as well given that Squeak
seems to have gone Morphic based and the Self GUI was entirely Morphic.

I do like the reflection approach of presenting editable user interfaces to
objects that Self provides that you mention. Using that interface feels very
much like manipulating a soup of objects vs using an application.

------
mrcwinn
I really hope the JavaScript community (or especially a smaller universe
within that, framework developers) would step back and focus on simplicity,
small codebases, thoughtful patterns, tried and true methods.

The good news is the JS community is filled with young developers with a lot
of enthusiasm and new ideas. The bad news is young developers tend not to have
the advantage that comes with experience or a respect for the history of
previous implementations.

I'm often horrified by some of the JavaScript I see - including very popular
frameworks that developers "love" written by engineers people respect. The
complexity is frightening, and every month there's some new word or phrase
describing a programming concept I've simply never seen before.

Maybe some of it is necessary - an honest attempt to satisfy the needs of a
browser client, rather than a server. But my gut tells me this over-complexity
is the result of not yet finding the answer to a question, or having the
burden of satisfying backwards compatibility to last week's crap idea.

A rich, vibrant ecosystem is great, but I would love to see a more stable,
thoughtful one as well. I'd love to see a community as committed to
maintaining things that work, as they are to creating new things. I'd love to
see young developers put a premium on using what is proven, not just what is
exciting.

In other words, it's up to all of us to be careful with our votes. In some
societies, you "vote" in the marketplace with the money that you spend. In our
world of engineering, we cast a vote every time we star a repo, create a new
fork, issue a pull request, or make a GET request to pull down the library
into our project. Take the time to honestly assess how good something is, and
whether you think it'll still be around in 5 or 10 years. It's really
important we take the time to craft wonderful software.

~~~
drinchev
I fully agree.

That's one of the reasons when I'm a part of a team and I need to make a
decision about a framework, I usually go with Backbone. It's source code
consists of one file that can be understood for less than an hour.

Last non-sense in this complexity is the boom of JavaScript framework specific
languages that pop up. Like ReactJS and recently Angular 2.0 is preparing
their own language for using it's platform.

~~~
mrcwinn
I completely agree about Backbone. Backbone is a very simple tool. You can do
a lot of damage if you're not yet a very good developer (or a very good
Backbone developer), but if you care about your craft and the design of your
application, it's fantastic. In fact, having the flexibility to make decisions
about your application, forces you to make good design decisions. _That_ is
the mark of a great developer.

With these other frameworks, which might be very large or very slow or very
complicated, they enforce that design on you. For most projects, who cares?
Use whatever is fun for you to use. Learn 'em all. But at a certain scale, it
matters deeply what you hitch your wagon to.

~~~
jashkenas
As the person who has been resisting adding more magic to Backbone for several
years ... it's awfully nice to hear this sort of thing. Cheers.

~~~
ak39
Hi, thanks for the great work on Backbone! Appreciate it.

How does Backbone relate to the points the original article makes? What are
your comments?

