Why not just have MVC for the page, and MVC for components?

Each component would render itself.

I personally think that this requires a lot of machinery under the hood, such as caching and batching requests (since no one knows ahead of time what components will need to be rendered).

At least that's what we built in our Qbix Platform (http://platform.qbix.com). Reusable components you just place on a page and they "just work". Unlike React, etc. they support more than just re-rendering. You can of course have a virtual DOM (via a lib like Mithril or https://github.com/Matt-Esch/virtual-dom etc.) but it would be nice to handle other kinds of events besides just "re-rendering".

When I built this a couple companies ago for a charting/dashboarding app, we used components simply had channels to receive events and send events. When a component was to be loaded, it provided a map of its data dependencies so that we could ensure efficient batching and appropriately updated queries. Unloading was resolving that in reverse. Clojurescript + core.async and some macros made this very very easy to implement, use, and extend, but you could easily do it on top of whatever random messaging system and virtual-dom you wanted.

In my app's scenario, we made a render decision based on the input and output for the component render functions. Prior to rendering the view, if the data was identical to what already existed, no updates occurred. cljs made this cheap. After constructing the template (hiccup-style, more cljs data), if it wasn't different, we'd also skip the DOM update.

For methods on the component (handling various events and such), they all take a channel where they could send whatever events it was that they needed to send.

The data service managing a query for one or more components just blocked its goroutine until it received an update to its query data structure, resolved it, and if it was different than the existing query data structure, would debounce for more changes before sending off the request. Requests back to the server were ordered by an atomic counter (atom 0) such that out of order responses could be processed sanely. Everything was one-way.

Additionally, while we could dynamically render everything, pages were a layout data structure containing 0 or more components with associated data services. These were all described in EDN and thus could be serialized, queried, and rendered server side if necessary.

All of this machinery was pretty small, no more than about 1800 LOC building on top of some excellent cljs libraries.

The data dependencies mapping part sounds a little bit like FB's relay proposal https://facebook.github.io/react/blog/2015/02/20/introducing...

Yes. We had a query language that let us string together AND/OR/NOT filters as a tree and then the backend could decompose and query off of it. We'd have a data service per document type being queried. In our situation, customer feedback aggregates, vertical aggregates and customer feedback datums were different. So a page containing components using both would necessarily have two data services working independently.

Any good pointers on reading material for architecturing something like this? Would be interested in more details.

I did some research into MVC a few months ago for a book [1] and my understanding is that this is how it worked when the concept was first devised in those first few Smalltalk releases: something like a textbox would still have the M and the V and the C. React just feels like a simplified version of that to me.

https://www.packtpub.com/web-development/ext-js-application-...

Seaside (http://www.seaside.st/), the Smalltalk web-application framework, does exactly what you're talking about—each component on the page has its own server-side view-controller, much like if you were using a controls library in a native GUI app.

One should also note that Seaside is likely the direct inspiration for Arc's (i.e. HN's) use of links that reference stored server-side closures by ID.

The free Seaside book and also the free Pharo by Example book are great ways to learn MVC. The only downside is that after using Seaside and a Smalltalk environment, you will probably be dissatisfied with not having such awesome features available in modern tools. :)

Edit: It looks like there is a new Pharo book that covers more advanced topics! http://deepintopharo.com/

Is this the same as Hierarchical MVC (http://en.wikipedia.org/wiki/Hierarchical_model–view–control...) ?

Any sentence of the form "everything is an _______" is going to lead you to trouble. It doesn't matter if the _______ is a function or a monolith or an MVC app or a file or an event or a closure or a command. You end up being theoretically correct, but you're really only saying "I want a small toolbox".

The framework you are programming in is the entirity of computer science. Good libraries are the ones that do their job well and don't get in the way of your using other tools to solve other problems.

Once you set up camp inside a framework and declare you're not coming out, whether it's MVC or immutable state or Salesforce or whatever, you're basically guaranteeing that you're going to be spending a big chunk of your day sanding down square pegs to fit in round holes.

This is like attempting to counter a proposed rule/guideline of program design by saying, "You should always use the best tool for the job." While technically true, it doesn't say anything about what makes a tool suitable for a job. Similarly here, maybe there are common patterns/rules followed by libraries that "do their job well and don't get in the way of using other tools." But dismissing any proposed rule just cuts off the conversation without giving a reason. The details really do matter.

I think what bothers me most about this way of thinking (which seems common here and elsewhere in the industry) is that it provides a veneer of credibility to bad developers who don't want to think about design and would prefer to just wing it.

Be pragmatic.. use the best tool at your disposal that suits your larger environment. If the company you work for is all .Net, they bringing in a small utility app that uses Python is a pretty big risk. The same can be said for most things in a given environment.

That said, I gave node a beachhead into a number of projects, because they were web applications and it made sense to do so. Even if not running on node, having the client-side bits using node tools made sense.

It really just depends. All in all, there are at least a dozen options for any given problem, and 4 out of 5 times the closest thing to what you are already doing is likely the right answer.

Yes, the point is—depends on what? That's the useful conversation to have.

"If you’re here at RailsConf today, please come talk to me. This is not reality TV, I am here to make friends."

That sounds great as a first. However, I fail to understand why you want a working e-mail to be able do d/l the slides. No pricavy policy, no word on what happens after you "signup"...

[author here]

Because I'm also sending a lot more info on things I had to cut from the talk for time (eg. samples of test code). I haven't finished or polished the stuff that I knew early I had to cut, so it's coming out as I can finish it.

Sorry it was unclear, I'll improve the text on that pgae.

I think it would be nice to make that clear and allow people to make a choice. Otherwise most people will just use a spam address they never check.

Yep. I've also seen a few people using the same strategy I do of [email protected] so they can recognize when email addresses get abused and trivially filter them.

For what it's worth, I have cleaned up enough servers hacked by spammers that I'll never send one. I guess I should mention that.

That works until someone writes a script that removes any \+[^@]+ from specific email domains :)

I've never seen that (or any other purposeful filtering of address tags.) On the other hand, I can't count the number of sites that were just programmed with an address validation regex that is unaware of the existence of address tags, and therefore thinks your email address with a plus in it is invalid.

You need an address to get the slides download link in his case.

Thanks for your feedback. I was really interested in the slides - but not on a newsletter subscription.

This is a really nice talk, and I wish I had something like it that was language-agnostic (or Java). Though I found it comprehensible as a non-rubyist, I suspect some people might convince themselves that they can't follow it because of the rails jargon.

I've read a lot about the benefits of immutability, but most discussions don't go so far as to describe how to a) refactor existing systems, b) structure the interacting parts that a web app might need.

Thanks, I'm really glad to hear a non-rubyist liked it. You put your finger on a really hard balancing act: the more Rails and Ruby specific it is, the more I can offer really practical steps for how to improve the Rails apps I spend all day in. But the more I talk about the general stuff, the more anyone can see that there's general principles at work that are useful in understanding and improving the design that are more useful than a list of gems to use.

I should say, I've written a few hundred lines of Ruby, am a language geek, and perhaps most importantly, have somehow ended up reading a lot of blog posts by people who write Ruby. I can't speak to how it would come across to someone who didn't have that superficial level of familiarity.

The 1980's?

You just made my day :-)

Found my corner. The first thing I thought when I read the headline was 'what came after MVC' FTFY.

I was literally just playing around with different ways to extract addresses from ActiveRecord models into value objects. I have gotten burned by clumsiness in Rails's `composed_of` before - glad to see that it'll be in attributes in Rails 5. I also think it's great to see alternatives to `include Comparable` in the Equalizer gem.

It's a good talk. Puts together some common themes of the moment: immutability, referential transparency, shrinking the responsibilities of the data, entity-component systems to track aggregations of data, and an "escape hatch" for moving necessarily side-effectful code into the smallest possible context.

Just spell it out, will ya? M-o-n-a-d-s. ;)

After I gave the talk, an audience member came and thanked me for giving such a nice Haskell talk. I said "shhhhhh!"

I'm sure Martin Fowler has an opinion on this.

YEP:

https://en.wikipedia.org/wiki/Model_View_ViewModel

apart from agile manifestos and talking about stuff, do you know what programs has he actually worked on?

other ones:

http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93pres...

http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93adap...

I didn't talk about MVVM in this talk, pretty much all of my examples were about decomposing the M.

That said, I'd love to hear what Fowler thinks of it, too.

I bet he'll respond to emails. Seems like a nice guy from his writing style.

Martin Fowler has two opposing opinions on everything.

UI will be generated dynamically based on the user, context and state of the semantic knowledge graph. No more UI will be built by hand.

Well that's been the holy grail for a long time. But I believe it's also important to put the ability and literacy to build UI, and powerfully compose extensible high level building blocks, into the hands of the user.

The dynamic generation tools should be able to remember and apply the changes and preferences the user and their context require, but the user still needs complete control to easily make one-off special purpose "instance first" interfaces, and then iteratively generalize, abstract and refactor them into reusable specifications, rules, classes and prototypes.

By "instance first" I'm referring to the term Oliver Steele used to describe declarative programming with constraints in OpenLaszlo:

https://news.ycombinator.com/item?id=7756151

http://blog.osteele.com/posts/2004/03/classes-and-prototypes...

One word, HMVC.

Take a look at Apache Sling's content-driven/content-focused way of displaying information. Once you get your head wrapped around it it makes perfect sense for displaying content rather than data, which is better for mvc.