
What Comes After MVC - luu
https://push.cx/2015/railsconf
======
zkhalique
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](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](https://github.com/Matt-Esch/virtual-dom) etc.) but it would be nice to
handle other kinds of events besides just "re-rendering".

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

~~~
ac2u
The data dependencies mapping part sounds a little bit like FB's relay
proposal
[https://facebook.github.io/react/blog/2015/02/20/introducing...](https://facebook.github.io/react/blog/2015/02/20/introducing-
relay-and-graphql.html)

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

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

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

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

~~~
derefr
Yes, the point is—depends _on what_? That's the useful conversation to have.

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

~~~
Harkins
[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.

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

~~~
Harkins
Yep. I've also seen a few people using the same strategy I do of
user+sitename.com@example.com 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.

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

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

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

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

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

------
DonHopkins
The 1980's?

~~~
Ace17
You just made my day :-)

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

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

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

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

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

~~~
throwawayaway
YEP:

[https://en.wikipedia.org/wiki/Model_View_ViewModel](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%93presenter)

[http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93adap...](http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93adapter)

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

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

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

~~~
DonHopkins
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](https://news.ycombinator.com/item?id=7756151)

[http://blog.osteele.com/posts/2004/03/classes-and-
prototypes...](http://blog.osteele.com/posts/2004/03/classes-and-prototypes/)

------
solidr53
One word, HMVC.

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

