Smalltalk MVC Translated to JavaScript
peter.michaux.ca
peter.michaux.ca
>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.
You can even develop interactively in your browser with "live objects" using an IDE akin to what you'd find in Squeak/Pharo.
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).
Unidirectional JavaScript talk from Raynos:
https://www.youtube.com/watch?v=RLAjMeR8898
The "framework" used is 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...
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-struct
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
See browser.js of todomvc to see time travel in use:
https://github.com/Raynos/mercury/blob/master/examples/todom...
elm-html is also worth checking out:
https://github.com/evancz/elm-html
Both mercury and elm-html rely on virtual-dom:
https://github.com/Matt-Esch/virtual-dom
Anyways, small modular libraries FTW!
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
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...
The article: http://feedmyconstraint.wordpress.com/2011/10/24/is-mvc-the-...
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...
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
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).
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.
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.
/S
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.
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.
How does Backbone relate to the points the original article makes? What are your comments?
I don't want to put a client ( I work as a freelancer ) in the position to look for someone that knows framework "A" or "B". Also I'm pretty sure "A" or "B" will soon be obsolete and the successor will need to change the whole codebase, instead of improving it.
I'm not talking about Ember, actually I'm also using it, but when it happens to go for scalable project I would prefer Backbone, because of team members learning curve and potential developers availability.
The issue with that is that the learning curve is now higher because the chances that a developer knows those missing parts that you added or coded is increasingly small.
Btw, I'm a heavy Backbone.js user so I still think it's a better option compared to other MVC flavours but I do have the problem that a lot of things related to data binding and UI animations is custom built and have the issue described above.
What I see, and this may or may not be the case, is that web development still gets a pretty bad rap among those doing other kinds of software engineering which lead to a lot of isolated development of tools/libraries/etc that didn't give much thought to the patterns of yore/other software crafts.
Mostly because web development believes itself to be drastically different from every type of software in the past.
Of course, it isn't. It's bog-standard business programming piled on with loads of incidental complexity that happens to be 'open.'
The only thing different is everyone feels subject to Internet Time, and speed to ship is valued over everything, including vision, conceptual clarity, and correctness.