13 ms·

The Sun is Setting on Rails-style MVC Frameworks

222 points by jamesjyu 15y ago

tbatterii 15y ago
"This probably means that 'controllers' need to go away in favor of 'resources', and routes can be vastly simplified, if not completely derived/inferred by the framework." http://docs.pylonsproject.org/projects/pyramid/en/1.3-branch/narr/traversal.html http://docs.pylonsproject.org/projects/pyramid/en/1.3-branch...
- rbanffy 15y ago
  Also, Zope maps URLs to method invocations on objects or their containers - http://server/ob1/ob2/m1 http://server/ob1/ob2/m1 is served by storage['ob1']['ob2'].m1() (there are ways to mess with that, of course)
  - tbatterii 15y ago
    yeah, traversal is one of the nice things pyramid took from zope. Very powerful if your data model fits in a nice hierarchy.
jarrett 15y ago
I'm very much looking forward to (and hoping to help build) thick-client frameworks with the same level of polish and maturity as Rails 3. Obviously there's a long way to go, but I think it will happen. I'm not a Node expert, but I'd be willing to bet we end up with at least one Node framework at the head of the pack, if for no other reason than it enables easy sharing between server and client-side logic. (E.g. write your validation rules only once.) You could of course write the backend in any language, and you could even have some code sharing if you automatically generated JavaScript from your backend language. (E.g. ClojureScript.) But I'm attracted to the simplicity of just using JS, and not having to worry about all the weird little things that can happen when you compile one high-level language to another.
- moe 15y ago
  at least one Node framework at the head of the pack, if for no other reason than it enables easy sharing between server and client-side logic I'm surprised this still hasn't been seriously tackled. The major node frameworks (namely express) all seem to follow the old-fashioned rails-model which seems like an anachronism on that particular platform.
  - AdrianRossouw 15y ago
    Our Bones[1] library for node.js does this, in most applications we have written probably in excess of 90% of the code is shared between server and client. We have written cloud based hosting systems[2], desktop applications[3] and more standard web applications with it. I think it wouldn't be too hard to make it possible to build phonegap'esque apps with it too. It's pretty great stuff, but it opens you up to very new and interesting problems due to the environment being so different. The client side has absolutely no concept of a 'request', and there is a lot of stuff that just can't be done on the client (is this email address unique?). The server side does not have the long running state that the client does, which causes another category of problems. I think it's going to become a more dominant approach, because it's just so damn convenient, but it's going to take a bit more time to properly 'crack' it. [1] bones : http://github.com/developmentseed/bones http://github.com/developmentseed/bones [2] mapbox hosting : http://mapbox.com/tour/ http://mapbox.com/tour/ [3] tilemill : http://mapbox.com/tilemill/ http://mapbox.com/tilemill/
run4yourlives 15y ago
Round and round the mulberry bush we go. Evolution of computing: 1. Direct mainframe access (No client) 2. Networked access via "dumb" terminal (thin client) 3. Client/Server technology (Thick client) 4. Client/Server over the internet (thick client) 5. Browser based applications (thin client) 6. Device specific apps (thick client) 7. Hrm.. If I had to guess, device independent thin clients...
- diminish 15y ago
  7. html5 or mozilla gecko type of app stores? or any other alternatives?
- tomjen3 15y ago
  You missed the round of 'apps that are local on your machine and the data is local on your machine so you better have a backup'. That is the part we are escaping from now.
  - pyre 15y ago
    Straight to the part where: 1) The service is free, so if you're data gets lost, you're out of luck. 2) The government just has to ask nicely to look at the data without a court order. 3) Your data becomes the property of the 3rd party whose service you are using.
    - mnutt 15y ago
      It seems like the ideal scenario is: 1) Your data is stored, encrypted by you, in the cloud 2) In a standards-based service which you pay for 3) And federated to other services by you Mozilla Weave was an instance of a narrow application of this: http://mozillalabs.com/blog/2007/12/introducing-weave/ http://mozillalabs.com/blog/2007/12/introducing-weave/ There is still the issue that once you grant access to a third party you can't revoke it, but that's unsolvable through technical means in somewhat the same way DRM is unsolvable.
- Jare 15y ago
  7 looks a lot like 5 actually. You could say it's already happening in Cloud gaming (Gaikai, OnLive), but for general purpose application I think we need to have either: - new types of (underpowered) devices: body augmentation? - or much larger UI and processing needs: Photo filtering is more and more back in the client... video processing a-la Animoto? Siri? 3D UIs so favored in SF?
lfnik 15y ago
One question for the author. Have you ever written a framework? Yeah that's right. ha.
- lfnik 15y ago
  upvotes are O-V-E-R
  - antidaily 15y ago
    is that a Portlandia reference?
    - lfnik 15y ago
      Indeed it is. And I was sitting next to the author of this blog the entire time.
robfig 15y ago
So MVC frameworks are going away for thick-client apps because their routing is not convenient for defining resources? And that their templating abilities are too powerful (or not powerful enough?). Not sure I get it. (Current routing schemes do not seem overly difficult for this, and depending on your MVC framework, you can plug in your own routing.)
mltcx 15y ago
is this rails bashing week or something?
- grabastic 15y ago
  it's just an echo chamber
- jrockway 15y ago
  Bashing? Nope. Rails is simply not how people write web apps anymore. Most people write a UI-independent API layer, and then write the UI in Javascript. This makes Rails largely unnecessary; you still use the individual pieces, but the framework as a whole no longer makes sense.
  - jcromartie 15y ago
    Which is why it was a good move to modularize Rails as much as they did.
  - gnaritas 15y ago
    None of that is true. If you think it is, you're in a sheltered bubble too focused on the new hotness from the valley. Out in the real world, where there are millions upon millions of business apps being written, most people are still banging out apps server side.
    - jrockway 15y ago
      I am from a sheltered bubble: one where we enjoy engineering efficient systems, and one where I work with the smartest people in the industry. This is how we wrote boring business software at the investment bank where I last worked, and this is how we write software at Google, where I work now. People write apps this way now because it's faster, easier, and more flexible. (For me it means I don't have to tweak UI code anymore, there are lots of people that like to do that and now they don't have to care about the backend. Just use my API!) But sure, I believe that not everyone does this; I still maintain legacy apps too. Why rewrite millions of lines of code nobody really cares about? But that doesn't mean you should write a new web app in 2012 like you did it in 2008. Just like we stopped writing CGI scripts when good frameworks became available.
simonw 15y ago
Only if you think thick JavaScript apps hooked up to JSON APIs are a good way to build for the Web. I don't.
- sopooneo 15y ago
  Why not? I ask sincerely. It seems like a reasonable approach to me for web apps, just NOT for simple sites that rarely change or are not "application" like
  - andybak 15y ago
    Which surely is and will continue to be the majority of sites? HN blinkers aside - aren't most sites still going to be content sites rather than web applications?
  - simonw 15y ago
    Plenty of reasons. Firstly, web app vs web site isn't a binary distinction - it's a gradient. Is Flickr an application or a site? It provides extensive tools for uploading and organising photos... but the bulk of the site is flat pages people use for navigating vast amounts of content. Secondly, URLs really, really matter. Twitter have a big engineering task on now to clean up the mess made when they switched to using broken-URL #!s. The ability to link to things is the most important factor in the Web's success. An application built as a fat JavaScript client that talks to an API is opting out of the URL-driven web. Even if something uses #! or pushState to emulate linkable URLs, if I can't hit a URL with an HTTP client library (not a full-blown JS+DOM implementation) and get back a content representation, it's not a full-blown member of the web - it's no better than content that's been wrapped up in a binary Flash container. Don't think I'm not pro-JavaScript - I'm a big fan of using JavaScript to improve user experience etc (heck, I have code in the first ever release of jQuery). I'm just anti JavaScript being required to consume and manipulate the Web. I'll concede that there are plenty of applications for which a fat client does make sense (image manipulators, data vis tools, possibly interfaces like gmail although I'm continuously infuriated by my inability to open gmail messages in new tabs). But the thinking embraced by the original article, that Rails-style frameworks are on the way out because EVERY site should be built as a fat client, is dangerously short-sighted in my opinion.
tomdale 15y ago
I wouldn't say that the sun is setting on Rails-style MVC frameworks, but I do think their role in the ecosystem is going to change. Before, most people could get away with writing the entirety of their app as a single Rails or Django app. I think the shift first started with the ascendancy of native mobile apps. Now, developers had to seriously start considering their HTTP APIs as first-class citizens and not nice-to-haves. Once that happened, it's not a big leap to realize that treating your web application as somehow different from any of your native clients is a bit, well, insane. You can either choose to write a server that is a mix of JSON API and rendered HTML, with conditionals all about trying to figure out the right thing to render, or you can pull all of that logic out into a stand-alone JavaScript application, with better responsiveness to boot. I think this approach is a winner. The server guys can focus on building a kick-ass server, and the front-end guys can build an awesome UI without having to muck about in the server bits. One thing that still blows my mind is how hard it still is to get data from the server to the client. Everyone is writing custom code specific to their app. As the article says: There's no reason for us to all separately think about these problems and solve them in a million different ways every time we're confronted with them. Aside from the years of wasted time this involves, we've also got a bunch of non-standard and sub-standard APIs to interact with, so all the client code needs to be custom as well and nothing is reusable. I think this is a huge problem, and Yehuda and I are doing our part to try to solve it. Our Ember Data framework (http://github.com/emberjs/data http://github.com/emberjs/data), by default, assumes certain things, such as the names of your routes and how associations should be loaded. We want to enable people to start building apps right now instead of writing hundreds of lines of JavaScript that are custom to their application, and do it in a sufficiently comprehensive way that you very rarely need to drop down "to the metal." For example, we handle things like mutating associations on the client-side even before a guid has been assigned to a record. Personally, I'm excited for how this is going to all shake out. I think Rails will continue to be an important piece in the toolchain, but it will no longer be the primary one, and I can't wait to see how it evolves to fill that role.
- MatthewPhillips 15y ago
  I'd add that when you take this approach there is little reason your myapp.com endpoint needs to be anything more than a resource loader. Nginx + AppCache is all you really need to make your app load instantly with plenty of connections. Your API can, and probably should, set on a completely different server.
bentlegen 15y ago
> Front-end frameworks like backbone.js, as well as advances in web technologies like HTML5's history.pushState are now making server-free views a realistic quality of cutting-edge front-ends. This is not exactly correct. Many web applications are now foregoing client-side templating and are back to doing it on the server. GitHub is a great example of this, and Twitter is going this route too.
- riffraff 15y ago
  I think there are examples in both directions, facebook and more recently linkedin seem to be have embraced "let's build a page out of many different calls in js", if I am not mistaken.
- dmix 15y ago
  Those sites aren't using Rails (edit: too heavily) either, which was the basis of comparison in the article. Github/Twitter are massive with millions of visitors... they need to minimize every millisecond. It's not just about choosing the best developer-friendly or cleanest option. Performance is #1. That's not the case for the average smaller apps. Frameworks like Backbone.js and Ember are growing very quicky and every open example app I've seen uses client-side templating.
  - EvilTrout 15y ago
    Github absolutely uses Rails. Twitter too, although I understand less so than when they launched.
    - dmix 15y ago
      You're right. I stand corrected. I thought Github had moved away from rails but they seem to be still using it along with lots of erlang/js.
    - lapusta 15y ago
      Main Twitter UI is JS talking to api.twitter.com written in Scala. They use Rails for pre-rendering the first page and some non-js pages like user settings & company info for what I can tell looking at their server responses.
wavephorm 15y ago
RPC's over WebSockets is what will replace REST/Ajax. On the client-side you have code like this: clientapp.sendRPC.doSomething(123); And on the server you write code to receive it: serverapp.receiveRPC.doSomething = function(number) { write(number) }; No Ajax, no URLs, no REST-ful religion. In fact ajax just feels wrong now. I unfortunately have to add some backward compatibility to my websocket apps, and I just get this really icky feeling like I really shouldn't be doing this arcane stuff anymore.
- deno 15y ago
  REST is just a layer of indirection over a regular RPC backend anyway. It may be easier to reason about things like caching and side-effects on the HTTP level. Of course HATEOS is mostly useless, unless you can stay within the general purpose protocols, like AtomPub and extensions. > RPC's over WebSockets is what will replace REST/Ajax. If SPDY takes off, there’s hardly any advantage to WS besides push events. Stateless protocols are easier to scale.
- Joeri 15y ago
  You don't need web sockets to do this. Check out ext.direct. It does exactly this over xhr. I do something similar, with json-rpc as intermediate. The problem with REST is that people try to wrap rpc-style api's in a restful container, and it just doesn't do that well enough.
- hello_moto 15y ago
  GWT has been doing RPC for years (since its inception). The best part is that you can have both approaches with GWT (RPC or AJAX).
stephen 15y ago
I don't buy HATEOAS--this notion that clients will be adaptive enough to take advantage of changes in the rel/whatever links seems unlikely. (E.g. I can't see a client going "oh!, there's a new business function I haven't seen yet, let me invoke that!".) With the rels/links, you're just moving the coupling away explicit URLs to the names/identities of rels/links in the response. Unless you anticipate changing your URLs often, I don't see this as being terribly useful.
- bct 15y ago
  > (E.g. I can't see a client going "oh!, there's a new business function I haven't seen yet, let me invoke that!".) Of course not, nobody thinks that. That notion does not exist. > With the rels/links, you're just moving the coupling away explicit URLs to the names/identities of rels/links in the response. I suppose, but that's a much looser coupling than the alternative (i.e. writing in the documentation "the comments URL is http://example.com/comments http://example.com/comments - you can't rearrange your URL structure, you can't start using a different domain (e.g. a CDN) for comments, existing clients can't use other sites that implement the same API, etc). HATEOAS is about building general protocols rather than site-specific APIs. That it makes it easier to change your own URLs is just a bonus.
  - stephen 15y ago
    > Of course not, nobody thinks that. I'm pretty sure Fielding does, see "improved on-the-fly": "The transitions may be determined (or limited by) the client’s knowledge of media types and resource communication mechanisms, both of which may be improved on-the-fly (e.g., code-on-demand)." http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hyperte... Hypermedia is great for intelligent clients (e.g. humans) who can adapt to, say, a webpage changing and new fields suddenly showing up in the hypermedia (HTML) that are now required. However, for an application, it's going to be hard-coded to either do: 1) POST /employee with name=foo&age=1, GET /employee?id=1 Or 2) GET /hateoas-entry-point, select "new employee" link, fill out the 2 fields (and only 2 fields) it knew about when the client was programmed (name, age), post it to the "save employee link", go back to "/hateoas-entry-point", select "get employee" link, fill in the "id=1". (...or something like that). In either scenario, the non-human client is just as hard-coded as the other--it's either jumping to external URLs or jumping to internal links. Either way those URLs/links (or link ids) can't change and the functionality is just as frozen. Perhaps the benefits of hypermedia would be more obvious if Fielding built a toy example or two that we could all touch and feel instead of just dream up. But so far there seem to be a lot of non-HATEOAS REST APIs that are doing just fine sans hypermedia.
gerggerg 15y ago
Sure, I guess if you fundamentally misunderstand MVC but not in the real world. You don't have render your view on the server, using a js framework is perfectly fine in MVC. There are plenty of rails plugins to make this even easier and I whole-heartedly disagree with, "Rails-style MVC frameworks have a horrible routing solution for RESTFul JSON APIs". Rails has simple routing that works great for restful resources and auto renders json that can be easily overridden. Having a unified/standardized REST interface for web services would no doubt be nice, but it's existence has little to nothing to do with MVC.
instakill 15y ago
Yeah, tell that to the overwhelming number of clients worldwide that don't support client-heavy operations (and will probably remain so for the next ~5 years).
singingfish 15y ago
So all I'm seeing is complaints about inflexible URI routing, and excessively opinionated model classes. This stuff is basically solved in at least one other "rails style" framework (https://metacpan.org/module/Catalyst::Runtime https://metacpan.org/module/Catalyst::Runtime). Web controllers are a rat's nest anyway, the whole thing is basically broken, and the only sane thing to do is to seek for an acceptable comprimise.
- LewisCr 15y ago
  Are there any write ups online that explain how catalyst solves these problems?
rubynerd 15y ago
That's all well and good, if you do your API with Rails. Assuming this is an actual API, consider a rouge script slamming your API, whoops, your main app is out as well, nobody is signing up for your service. Assuming this is for backbone/batman/other-generic-clientside-framework, nope. Too much JavaScript makes everything seem sluggish, and I really don't want to reimplement everything twice (once in Rails for conventional browsers and for people who disable JavaScript, second in client-side MVC)
- techiferous 15y ago
  > for people who disable JavaScript I stopped caring about this long ago. I write database-backed web applications that require authentication, and in this context if a user has JavaScript turned off, that's their problem, not mine.
  - pdwetz 15y ago
    Sort of funny; as soon as I hit a new site that requires javascript, I often run away! But of course that's my problem; I get why user preference would get in the way of your clean implementation. :)
    - coderdude 15y ago
      Well, when you cripple your own client there's not much you can ask for.
SideburnsOfDoom 15y ago
Well, the ASP.Net MVC 4,0 beta, released a few days ago, has better support for "Web API" (i.e. Data endpoints) and for Single Page apps so it seem that they are aware of these trends. Links: http://weblogs.asp.net/scottgu/archive/2012/02/19/asp-net-mvc-4-beta.aspx http://weblogs.asp.net/scottgu/archive/2012/02/19/asp-net-mv... http://www.asp.net/single-page-application http://www.asp.net/single-page-application
- shaydoc 15y ago
  I seen this and I downloaded it earlier this week, it wouldn't build straight off, there were bugs in the script references, also EntityFramework 4.1 wouldn't resolve for me locally (had to add web.config ) , etc, not a great start (no biggie, just saying). Resolved these issues anyhow. On review, its fair enough if you love ASP.NET MVC, but I really don't like the mixing of the View Logic with the Model in ASP.NET MVC, like I already said keep it clean. From a View point of view keep it decoupled I say, keep any server side code out of there. At the end of the day , I have to agree ASP.NET MVC has got rich resources and it is a great offering for developers, no doubt. And MVC 4 useS knockout js behind the scenes anyhow, which is really great and personally I think that knockout goes far enough. The only reason I say this, is because I just refactored about 20 Web Form Views to pure HTML/CSS/js on the client side and turned out I had no need for any server side at all except for the restful service (hidden away in my knockout view model, used amplify.js to abstract the service calls) created on top of my domain model. so I am thinking, why do I need MVC if I have Restful WCF/ ASP.NET Web API. Going this way means I am totally decoupled! I am much happier building a restful service, knowing that any client can consume this, and I think I am happy building client side anyway that I so choose and not tying myself into ASP.NET MVC unnecessarily. So here's the deal for me if go pure W3C on the client : 1. No mixing in logic 2. Don't care about the server or server side code. 3. I can mock my backend real easy ( e.g. Amplify.js ) 4. I don't need Visual Studio for client side dev. 5. There's a growing wealth of open source libraries 6. Makes me think more about the structure of my server side behavioural domain model. Anyways, just how I see things..always open to more compelling arguments!
  - SideburnsOfDoom 15y ago
talleyrand 15y ago
Golly, I wish I understood what this is about...because if it means getting rid of MVC, I'm all for it.
Fivesheep 15y ago
recently, I have the idea to move all the ui stuffs to a chrome extension. on the web side, it provides pure data only, like json.
dkharrat 15y ago
I believe SEO is one of the main things that hinder client-thick architecture adoption for many apps that depend on their content showing up on search engines, especially among content-driven websites (e.g. Stackoverflow, Quora, etc.). But I agree, all signs are pointing at the direction of thick-client implementations and eventually search engines will solve the indexing problem.
- swah 15y ago
  But Quora loads HTML chunks via AJAX.
hilti 15y ago
I'm writing my web applications in a "resource like way" since 2009. This small framework supports resources represented as FOOP objects. Look at the wings example over here: http://rundragonfly.com/dragonfly_routes http://rundragonfly.com/dragonfly_routes
- hans 15y ago
  as if we know what Foop is, lol
- hilti 15y ago
  FOOP = a style of functional programming. See here http://www.newlisp.org/downloads/newlisp_manual.html#foop http://www.newlisp.org/downloads/newlisp_manual.html#foop
lukifer 15y ago
Monoculture is a terrible thing. I don't think there are any frameworks or methodologies which should never be used, nor any that should always be used. Learn the advantages and tradeoffs of each, and use the right tool for the job. That said, I've personally found that as nice and clean as MVC frameworks can be, they aren't always necessary. As long as there is a separation between logic and presentation, it's possible to write clean, readable, maintainable code without a formal MVC structure.
shaydoc 15y ago
Personally from an ASP.NET perspective, its the same. To me ASP.NET is done. Mixing in server side with client side UI is just wrong, they should be decoupled completely. I want to build a html5/js/css UI. I want to keep it clean and I want to talk to a data service/ or mocked out data service to do what I need. Starting out with ASP.NET, I used to think this is just totally the wrong way to do things! Then ASP.NET MVC came along which was much nicer than all the pain of web forms ( viewstate etc..) , but now as I said already, I want my client side to be written with no knowledge of the server side workings, just plain old html(5)/css and leverage the power of javascript and associated frameworks ( i like knockout.js and amplify.js). Its the convergence on standards and the sophistication of browsers that really matters. We all use browsers, all the big vendors now are appreciating this, enabling progression to standard presentation technology. Innovative successful businesses are delivering great services and UX using these standards and they are showing the rest that they need to move to keep competing. Responsiveness and performance are strong drivers for a rich/smart/thick client, there really are very little advantages to a thin client in application terms from a UX point of view. Managing upgrades is a sinch with browsers, so if you have a sophisticated client side javascript UI its easy to re-release. All in all, I tend to agree poster here!
SkyMarshal 15y ago
If you poke around the newly redesigned http://html5rocks.com/ http://html5rocks.com/, this is pretty much exactly where they're going with it. Thick rich HTML5 app, cached in the client, and passing data back and forth between the server.
- joemoon 15y ago
  Friendly criticism: The background are really distracting (and not very aesthetically pleasing). There is not enough contrast with the light colored links. These two things combined make the whole sight difficult to read.
jebblue 15y ago
The first problem to solve is to eradicate completely JavaScript from the entire programming world 100%. After that, program the server and the client in Java or if on Windows, C#. GWT works this way although they compile the client code to JavaScript. If we remove JavaScript we get better performance, more deterministic behavior across platforms and totally eliminate one language we have to know making our lives easier and the browser thinner and better performing. When someone comes out with a browser that does that we will be seeing the next killer app.
j_baker 15y ago
I agree with the author, but for diametrically opposed reasons. It's more that I don't think my web framework should decide that I need to be using MVC. If I want to tightly couple my view logic to my model logic, that's my (and my team's) business. If I want to drink the MVC Koolaid, that's my business as well. It isn't the business of the person who wrote my framework. It's much simpler to handle views and view logic in only one place, and that place is slowly moving away from the server side. I see. So one is simpler than two? That's a bit simplistic. Every situation is unique, and it's impossible to make such a sweeping statement that's true in all cases.
programminggeek 15y ago
I don't think Rails-style MVC frameworks are going to disappear for a lot of content heavy internet sites, but API first architectures are going to continue to become popular I think. That is part of the reason I built radial https://github.com/RetroMocha/radial https://github.com/RetroMocha/radial The tooling around rapid API development seems very immature right now, but it's going to keep getting better. Once it is drop dead easy to write API's first, you will see a lot more apps having a HTML5 app, Android app, iOS app, Windows 8 app, Mac app, etc. as more of the standard and less of an edge case.
AlexeyMK 15y ago
One thing I've been playing around with is the idea of coupling ORM-style models with rules about how those models should be presented as a JSON-API. https://gist.github.com/1823921 https://gist.github.com/1823921 The approach breaks a lot of 'separation of concerns' rules between the view and the model, but for certain kinds of APIs (read-only, in particular) this may be fine. Would be interesting in feedback/seeing where similar projects have gone.
rzbn 15y ago
I'm not much of an expert but would putting everything on the client have a security risk? Also it's amazing how fast the we are moving most developers are still using PHP but on HN, the MVC frameworks are already hailed as obsolete
zoul 15y ago
On related note, it surprises me that client-side frameworks like cappuccino.org are not used more often for building full-featured web apps. It seems to me that the abstraction from HTML and CSS is quite a desirable thing, I find the experience of modern desktop frameworks like Cocoa thousand times better than fiddling with HTML. Does anybody here have substantial Cappuccino experience? Why isn't it more successful?
amorphid 15y ago
What I'd love to see is a set up where I log into any computer and my stuff is all right there. Say I borrow your iPhone to do some stuff. Instead of using your setup, I log in and all my apps are right there. Some run from the swrver, some get pushed to the phone and used locally if that's more efficient. Let's call it client & server, anywhere you go computing, or something like that. A client & server setup probably means that you buy access to a mobile carrier's calling/data plan that isn't attached to a data plan. You buy a handset, tablet, laptop, yada yada that is a standalone device or use one at the local Internet cafe. A set of standards are put in place for how code runs on a client and server. Your data may remain on a client, but ideally is stored entirely in the cloud, too. The cloud data is encrypted.and can't be accessed without your permission. This is my dream and I'd be surprised if I'm the first one to think of it.
velshin 15y ago
There's often a distinction between APIs intended for general consumption (platform APIs) and APIs optimized for JavaScript and/or mobile clients ("private" APIs). A platform API tends to be stable, versioned, well documented, and "unoptimized" or strongly RESTful. GETing a resource (noun) returns just that one representation. e.g. GET /v1/user/123/profile or GET api.linkedin.com/v1/people/id=123 "Private" APIs tend to return more data in bulk, optimized to reduce the quantity of remote calls and improve page load times. The responses tend to be structured in a way that's easier for the client (browser/mobile app) to render content, usually by including more tangentially related data than a traditional REST resource would contain. e.g. a browser's load of https://github.com/rails/rails https://github.com/rails/rails does GET github.com/rails/rails/graphs/participation Twitter uses the platform API in the browser. e.g. GET api.twitter.com/1/trends/1.json I'd be interested to hear from others leveraging APIs in their browser/mobile clients what they're using for MVC (e.g. backbone.js vs server side) and whether they've "optimized" their APIs for the client.
Eleopteryx 15y ago
Here's my anecdote: 1. I dumped view helpers for decorators (namely, the Draper gem). I got rid of complex logic in my view templates. Most of the logic I need in my views is transformed object properties. I need a date to appear as mm/dd/yy. I need a filesize in bytes to appear as KB/MB. I want a comment formatted as Markdown to be HTML. So now I'll decorate my objects so I have a nice post.formatted_date instead of needing to write the helper formatted_date(post). At worst I have some conditional statements in my views looking for the existence of a property. CSS also comes into play; the :empty selector allows me to cheat in some cases. 2. I write my view templates in a JavaScript templating language. I am a fan of slim for Ruby, so I went with Jade for JavaScript. I use therubyracer to call on these precompiled templates within Ruby itself, and render them like anything else. I then go on to use these same templates client-side. The reason why I abandoned view helpers to a large extent is because of this. Any logic that I need within a template would have to be duplicated server-side and client-side, which is antithetical to the goal. For my use-cases I've been able to do this successfully. It requires an adjustment to mindset, but is feasible. And really, my templates are a lot cleaner now than they've ever been. 3. When a user lands on a page, they get rendered HTML. Subsequent requests use AJAX and JSON responses to load things dynamically from there. Best of both worlds. Also, users who have JavaScript disabled can use the site albeit with not as much slickness. 4. Using to_json is hell; don't do it. I use the RABL gem for assembling my JSON, and use the same decorated objects. In the case of JSON, depending on your API, you might want to include say an ISO8601 date as well as a formatted date. Not a big deal, just vaguely duplicative. The downside was how much code I had to write for myself. Using JavaScript templates was a biggy. But this is something that could probably be packaged as a gem, if I or someone else took the time. The framework (in my case, Padrino) still provides lots of tools that I need. Ruby ORMs are a big part of this. There's still the issue of duplicative routes. I have routes defined in the app itself, and then within my JavaScript framework (currently Spine, but previously Backbone) I have to hardcode these same routes. I don't like this, however, routes are probably the last thing to change in my app if I put any thought into them ahead of time. This is something that requires additional thought, but I'm thinking there should be a way to get my app routes available client-side.

222 points by jamesjyu 15y ago

"This probably means that 'controllers' need to go away in favor of 'resources', and routes can be vastly simplified, if not completely derived/inferred by the framework." http://docs.pylonsproject.org/projects/pyramid/en/1.3-branch/narr/traversal.html http://docs.pylonsproject.org/projects/pyramid/en/1.3-branch...

rbanffy 15y ago
Also, Zope maps URLs to method invocations on objects or their containers - http://server/ob1/ob2/m1 http://server/ob1/ob2/m1 is served by storage['ob1']['ob2'].m1() (there are ways to mess with that, of course)
- tbatterii 15y ago
  yeah, traversal is one of the nice things pyramid took from zope. Very powerful if your data model fits in a nice hierarchy.

jarrett 15y ago

I'm very much looking forward to (and hoping to help build) thick-client frameworks with the same level of polish and maturity as Rails 3. Obviously there's a long way to go, but I think it will happen. I'm not a Node expert, but I'd be willing to bet we end up with at least one Node framework at the head of the pack, if for no other reason than it enables easy sharing between server and client-side logic. (E.g. write your validation rules only once.) You could of course write the backend in any language, and you could even have some code sharing if you automatically generated JavaScript from your backend language. (E.g. ClojureScript.) But I'm attracted to the simplicity of just using JS, and not having to worry about all the weird little things that can happen when you compile one high-level language to another.

moe 15y ago
at least one Node framework at the head of the pack, if for no other reason than it enables easy sharing between server and client-side logic I'm surprised this still hasn't been seriously tackled. The major node frameworks (namely express) all seem to follow the old-fashioned rails-model which seems like an anachronism on that particular platform.
- AdrianRossouw 15y ago
  Our Bones[1] library for node.js does this, in most applications we have written probably in excess of 90% of the code is shared between server and client. We have written cloud based hosting systems[2], desktop applications[3] and more standard web applications with it. I think it wouldn't be too hard to make it possible to build phonegap'esque apps with it too. It's pretty great stuff, but it opens you up to very new and interesting problems due to the environment being so different. The client side has absolutely no concept of a 'request', and there is a lot of stuff that just can't be done on the client (is this email address unique?). The server side does not have the long running state that the client does, which causes another category of problems. I think it's going to become a more dominant approach, because it's just so damn convenient, but it's going to take a bit more time to properly 'crack' it. [1] bones : http://github.com/developmentseed/bones http://github.com/developmentseed/bones [2] mapbox hosting : http://mapbox.com/tour/ http://mapbox.com/tour/ [3] tilemill : http://mapbox.com/tilemill/ http://mapbox.com/tilemill/

run4yourlives 15y ago

Round and round the mulberry bush we go. Evolution of computing: 1. Direct mainframe access (No client) 2. Networked access via "dumb" terminal (thin client) 3. Client/Server technology (Thick client) 4. Client/Server over the internet (thick client) 5. Browser based applications (thin client) 6. Device specific apps (thick client) 7. Hrm.. If I had to guess, device independent thin clients...

diminish 15y ago
7. html5 or mozilla gecko type of app stores? or any other alternatives?
tomjen3 15y ago
You missed the round of 'apps that are local on your machine and the data is local on your machine so you better have a backup'. That is the part we are escaping from now.
- pyre 15y ago
  Straight to the part where: 1) The service is free, so if you're data gets lost, you're out of luck. 2) The government just has to ask nicely to look at the data without a court order. 3) Your data becomes the property of the 3rd party whose service you are using.
  - mnutt 15y ago
    It seems like the ideal scenario is: 1) Your data is stored, encrypted by you, in the cloud 2) In a standards-based service which you pay for 3) And federated to other services by you Mozilla Weave was an instance of a narrow application of this: http://mozillalabs.com/blog/2007/12/introducing-weave/ http://mozillalabs.com/blog/2007/12/introducing-weave/ There is still the issue that once you grant access to a third party you can't revoke it, but that's unsolvable through technical means in somewhat the same way DRM is unsolvable.
Jare 15y ago
7 looks a lot like 5 actually. You could say it's already happening in Cloud gaming (Gaikai, OnLive), but for general purpose application I think we need to have either: - new types of (underpowered) devices: body augmentation? - or much larger UI and processing needs: Photo filtering is more and more back in the client... video processing a-la Animoto? Siri? 3D UIs so favored in SF?

lfnik 15y ago

One question for the author. Have you ever written a framework? Yeah that's right. ha.

lfnik 15y ago
upvotes are O-V-E-R
- antidaily 15y ago
  is that a Portlandia reference?
  - lfnik 15y ago
    Indeed it is. And I was sitting next to the author of this blog the entire time.

robfig 15y ago

So MVC frameworks are going away for thick-client apps because their routing is not convenient for defining resources? And that their templating abilities are too powerful (or not powerful enough?). Not sure I get it. (Current routing schemes do not seem overly difficult for this, and depending on your MVC framework, you can plug in your own routing.)

mltcx 15y ago

is this rails bashing week or something?

grabastic 15y ago
it's just an echo chamber
jrockway 15y ago
Bashing? Nope. Rails is simply not how people write web apps anymore. Most people write a UI-independent API layer, and then write the UI in Javascript. This makes Rails largely unnecessary; you still use the individual pieces, but the framework as a whole no longer makes sense.
- jcromartie 15y ago
  Which is why it was a good move to modularize Rails as much as they did.
- gnaritas 15y ago
  None of that is true. If you think it is, you're in a sheltered bubble too focused on the new hotness from the valley. Out in the real world, where there are millions upon millions of business apps being written, most people are still banging out apps server side.
  - jrockway 15y ago
    I am from a sheltered bubble: one where we enjoy engineering efficient systems, and one where I work with the smartest people in the industry. This is how we wrote boring business software at the investment bank where I last worked, and this is how we write software at Google, where I work now. People write apps this way now because it's faster, easier, and more flexible. (For me it means I don't have to tweak UI code anymore, there are lots of people that like to do that and now they don't have to care about the backend. Just use my API!) But sure, I believe that not everyone does this; I still maintain legacy apps too. Why rewrite millions of lines of code nobody really cares about? But that doesn't mean you should write a new web app in 2012 like you did it in 2008. Just like we stopped writing CGI scripts when good frameworks became available.

simonw 15y ago

Only if you think thick JavaScript apps hooked up to JSON APIs are a good way to build for the Web. I don't.

sopooneo 15y ago
Why not? I ask sincerely. It seems like a reasonable approach to me for web apps, just NOT for simple sites that rarely change or are not "application" like
- andybak 15y ago
  Which surely is and will continue to be the majority of sites? HN blinkers aside - aren't most sites still going to be content sites rather than web applications?
- simonw 15y ago
  Plenty of reasons. Firstly, web app vs web site isn't a binary distinction - it's a gradient. Is Flickr an application or a site? It provides extensive tools for uploading and organising photos... but the bulk of the site is flat pages people use for navigating vast amounts of content. Secondly, URLs really, really matter. Twitter have a big engineering task on now to clean up the mess made when they switched to using broken-URL #!s. The ability to link to things is the most important factor in the Web's success. An application built as a fat JavaScript client that talks to an API is opting out of the URL-driven web. Even if something uses #! or pushState to emulate linkable URLs, if I can't hit a URL with an HTTP client library (not a full-blown JS+DOM implementation) and get back a content representation, it's not a full-blown member of the web - it's no better than content that's been wrapped up in a binary Flash container. Don't think I'm not pro-JavaScript - I'm a big fan of using JavaScript to improve user experience etc (heck, I have code in the first ever release of jQuery). I'm just anti JavaScript being required to consume and manipulate the Web. I'll concede that there are plenty of applications for which a fat client does make sense (image manipulators, data vis tools, possibly interfaces like gmail although I'm continuously infuriated by my inability to open gmail messages in new tabs). But the thinking embraced by the original article, that Rails-style frameworks are on the way out because EVERY site should be built as a fat client, is dangerously short-sighted in my opinion.

tomdale 15y ago

I wouldn't say that the sun is setting on Rails-style MVC frameworks, but I do think their role in the ecosystem is going to change. Before, most people could get away with writing the entirety of their app as a single Rails or Django app. I think the shift first started with the ascendancy of native mobile apps. Now, developers had to seriously start considering their HTTP APIs as first-class citizens and not nice-to-haves. Once that happened, it's not a big leap to realize that treating your web application as somehow different from any of your native clients is a bit, well, insane. You can either choose to write a server that is a mix of JSON API and rendered HTML, with conditionals all about trying to figure out the right thing to render, or you can pull all of that logic out into a stand-alone JavaScript application, with better responsiveness to boot. I think this approach is a winner. The server guys can focus on building a kick-ass server, and the front-end guys can build an awesome UI without having to muck about in the server bits. One thing that still blows my mind is how hard it still is to get data from the server to the client. Everyone is writing custom code specific to their app. As the article says: There's no reason for us to all separately think about these problems and solve them in a million different ways every time we're confronted with them. Aside from the years of wasted time this involves, we've also got a bunch of non-standard and sub-standard APIs to interact with, so all the client code needs to be custom as well and nothing is reusable. I think this is a huge problem, and Yehuda and I are doing our part to try to solve it. Our Ember Data framework (http://github.com/emberjs/data http://github.com/emberjs/data), by default, assumes certain things, such as the names of your routes and how associations should be loaded. We want to enable people to start building apps right now instead of writing hundreds of lines of JavaScript that are custom to their application, and do it in a sufficiently comprehensive way that you very rarely need to drop down "to the metal." For example, we handle things like mutating associations on the client-side even before a guid has been assigned to a record. Personally, I'm excited for how this is going to all shake out. I think Rails will continue to be an important piece in the toolchain, but it will no longer be the primary one, and I can't wait to see how it evolves to fill that role.

MatthewPhillips 15y ago
I'd add that when you take this approach there is little reason your myapp.com endpoint needs to be anything more than a resource loader. Nginx + AppCache is all you really need to make your app load instantly with plenty of connections. Your API can, and probably should, set on a completely different server.

bentlegen 15y ago

> Front-end frameworks like backbone.js, as well as advances in web technologies like HTML5's history.pushState are now making server-free views a realistic quality of cutting-edge front-ends. This is not exactly correct. Many web applications are now foregoing client-side templating and are back to doing it on the server. GitHub is a great example of this, and Twitter is going this route too.

riffraff 15y ago
I think there are examples in both directions, facebook and more recently linkedin seem to be have embraced "let's build a page out of many different calls in js", if I am not mistaken.
dmix 15y ago
Those sites aren't using Rails (edit: too heavily) either, which was the basis of comparison in the article. Github/Twitter are massive with millions of visitors... they need to minimize every millisecond. It's not just about choosing the best developer-friendly or cleanest option. Performance is #1. That's not the case for the average smaller apps. Frameworks like Backbone.js and Ember are growing very quicky and every open example app I've seen uses client-side templating.
- EvilTrout 15y ago
  Github absolutely uses Rails. Twitter too, although I understand less so than when they launched.
  - dmix 15y ago
    You're right. I stand corrected. I thought Github had moved away from rails but they seem to be still using it along with lots of erlang/js.
  - lapusta 15y ago
    Main Twitter UI is JS talking to api.twitter.com written in Scala. They use Rails for pre-rendering the first page and some non-js pages like user settings & company info for what I can tell looking at their server responses.

wavephorm 15y ago

RPC's over WebSockets is what will replace REST/Ajax. On the client-side you have code like this: clientapp.sendRPC.doSomething(123); And on the server you write code to receive it: serverapp.receiveRPC.doSomething = function(number) { write(number) }; No Ajax, no URLs, no REST-ful religion. In fact ajax just feels wrong now. I unfortunately have to add some backward compatibility to my websocket apps, and I just get this really icky feeling like I really shouldn't be doing this arcane stuff anymore.

deno 15y ago
REST is just a layer of indirection over a regular RPC backend anyway. It may be easier to reason about things like caching and side-effects on the HTTP level. Of course HATEOS is mostly useless, unless you can stay within the general purpose protocols, like AtomPub and extensions. > RPC's over WebSockets is what will replace REST/Ajax. If SPDY takes off, there’s hardly any advantage to WS besides push events. Stateless protocols are easier to scale.
Joeri 15y ago
You don't need web sockets to do this. Check out ext.direct. It does exactly this over xhr. I do something similar, with json-rpc as intermediate. The problem with REST is that people try to wrap rpc-style api's in a restful container, and it just doesn't do that well enough.
hello_moto 15y ago
GWT has been doing RPC for years (since its inception). The best part is that you can have both approaches with GWT (RPC or AJAX).

stephen 15y ago

I don't buy HATEOAS--this notion that clients will be adaptive enough to take advantage of changes in the rel/whatever links seems unlikely. (E.g. I can't see a client going "oh!, there's a new business function I haven't seen yet, let me invoke that!".) With the rels/links, you're just moving the coupling away explicit URLs to the names/identities of rels/links in the response. Unless you anticipate changing your URLs often, I don't see this as being terribly useful.

bct 15y ago
> (E.g. I can't see a client going "oh!, there's a new business function I haven't seen yet, let me invoke that!".) Of course not, nobody thinks that. That notion does not exist. > With the rels/links, you're just moving the coupling away explicit URLs to the names/identities of rels/links in the response. I suppose, but that's a much looser coupling than the alternative (i.e. writing in the documentation "the comments URL is http://example.com/comments http://example.com/comments - you can't rearrange your URL structure, you can't start using a different domain (e.g. a CDN) for comments, existing clients can't use other sites that implement the same API, etc). HATEOAS is about building general protocols rather than site-specific APIs. That it makes it easier to change your own URLs is just a bonus.
- stephen 15y ago
  > Of course not, nobody thinks that. I'm pretty sure Fielding does, see "improved on-the-fly": "The transitions may be determined (or limited by) the client’s knowledge of media types and resource communication mechanisms, both of which may be improved on-the-fly (e.g., code-on-demand)." http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hyperte... Hypermedia is great for intelligent clients (e.g. humans) who can adapt to, say, a webpage changing and new fields suddenly showing up in the hypermedia (HTML) that are now required. However, for an application, it's going to be hard-coded to either do: 1) POST /employee with name=foo&age=1, GET /employee?id=1 Or 2) GET /hateoas-entry-point, select "new employee" link, fill out the 2 fields (and only 2 fields) it knew about when the client was programmed (name, age), post it to the "save employee link", go back to "/hateoas-entry-point", select "get employee" link, fill in the "id=1". (...or something like that). In either scenario, the non-human client is just as hard-coded as the other--it's either jumping to external URLs or jumping to internal links. Either way those URLs/links (or link ids) can't change and the functionality is just as frozen. Perhaps the benefits of hypermedia would be more obvious if Fielding built a toy example or two that we could all touch and feel instead of just dream up. But so far there seem to be a lot of non-HATEOAS REST APIs that are doing just fine sans hypermedia.

gerggerg 15y ago

Sure, I guess if you fundamentally misunderstand MVC but not in the real world. You don't have render your view on the server, using a js framework is perfectly fine in MVC. There are plenty of rails plugins to make this even easier and I whole-heartedly disagree with, "Rails-style MVC frameworks have a horrible routing solution for RESTFul JSON APIs". Rails has simple routing that works great for restful resources and auto renders json that can be easily overridden. Having a unified/standardized REST interface for web services would no doubt be nice, but it's existence has little to nothing to do with MVC.

instakill 15y ago

Yeah, tell that to the overwhelming number of clients worldwide that don't support client-heavy operations (and will probably remain so for the next ~5 years).

singingfish 15y ago

So all I'm seeing is complaints about inflexible URI routing, and excessively opinionated model classes. This stuff is basically solved in at least one other "rails style" framework (https://metacpan.org/module/Catalyst::Runtime https://metacpan.org/module/Catalyst::Runtime). Web controllers are a rat's nest anyway, the whole thing is basically broken, and the only sane thing to do is to seek for an acceptable comprimise.

LewisCr 15y ago
Are there any write ups online that explain how catalyst solves these problems?

rubynerd 15y ago

That's all well and good, if you do your API with Rails. Assuming this is an actual API, consider a rouge script slamming your API, whoops, your main app is out as well, nobody is signing up for your service. Assuming this is for backbone/batman/other-generic-clientside-framework, nope. Too much JavaScript makes everything seem sluggish, and I really don't want to reimplement everything twice (once in Rails for conventional browsers and for people who disable JavaScript, second in client-side MVC)

techiferous 15y ago
> for people who disable JavaScript I stopped caring about this long ago. I write database-backed web applications that require authentication, and in this context if a user has JavaScript turned off, that's their problem, not mine.
- pdwetz 15y ago
  Sort of funny; as soon as I hit a new site that requires javascript, I often run away! But of course that's my problem; I get why user preference would get in the way of your clean implementation. :)
  - coderdude 15y ago
    Well, when you cripple your own client there's not much you can ask for.

SideburnsOfDoom 15y ago

Well, the ASP.Net MVC 4,0 beta, released a few days ago, has better support for "Web API" (i.e. Data endpoints) and for Single Page apps so it seem that they are aware of these trends. Links: http://weblogs.asp.net/scottgu/archive/2012/02/19/asp-net-mvc-4-beta.aspx http://weblogs.asp.net/scottgu/archive/2012/02/19/asp-net-mv... http://www.asp.net/single-page-application http://www.asp.net/single-page-application

shaydoc 15y ago
I seen this and I downloaded it earlier this week, it wouldn't build straight off, there were bugs in the script references, also EntityFramework 4.1 wouldn't resolve for me locally (had to add web.config ) , etc, not a great start (no biggie, just saying). Resolved these issues anyhow. On review, its fair enough if you love ASP.NET MVC, but I really don't like the mixing of the View Logic with the Model in ASP.NET MVC, like I already said keep it clean. From a View point of view keep it decoupled I say, keep any server side code out of there. At the end of the day , I have to agree ASP.NET MVC has got rich resources and it is a great offering for developers, no doubt. And MVC 4 useS knockout js behind the scenes anyhow, which is really great and personally I think that knockout goes far enough. The only reason I say this, is because I just refactored about 20 Web Form Views to pure HTML/CSS/js on the client side and turned out I had no need for any server side at all except for the restful service (hidden away in my knockout view model, used amplify.js to abstract the service calls) created on top of my domain model. so I am thinking, why do I need MVC if I have Restful WCF/ ASP.NET Web API. Going this way means I am totally decoupled! I am much happier building a restful service, knowing that any client can consume this, and I think I am happy building client side anyway that I so choose and not tying myself into ASP.NET MVC unnecessarily. So here's the deal for me if go pure W3C on the client : 1. No mixing in logic 2. Don't care about the server or server side code. 3. I can mock my backend real easy ( e.g. Amplify.js ) 4. I don't need Visual Studio for client side dev. 5. There's a growing wealth of open source libraries 6. Makes me think more about the structure of my server side behavioural domain model. Anyways, just how I see things..always open to more compelling arguments!
- SideburnsOfDoom 15y ago

talleyrand 15y ago

Golly, I wish I understood what this is about...because if it means getting rid of MVC, I'm all for it.

Fivesheep 15y ago

recently, I have the idea to move all the ui stuffs to a chrome extension. on the web side, it provides pure data only, like json.

dkharrat 15y ago

I believe SEO is one of the main things that hinder client-thick architecture adoption for many apps that depend on their content showing up on search engines, especially among content-driven websites (e.g. Stackoverflow, Quora, etc.). But I agree, all signs are pointing at the direction of thick-client implementations and eventually search engines will solve the indexing problem.

swah 15y ago
But Quora loads HTML chunks via AJAX.

hilti 15y ago

I'm writing my web applications in a "resource like way" since 2009. This small framework supports resources represented as FOOP objects. Look at the wings example over here: http://rundragonfly.com/dragonfly_routes http://rundragonfly.com/dragonfly_routes

hans 15y ago
as if we know what Foop is, lol
hilti 15y ago
FOOP = a style of functional programming. See here http://www.newlisp.org/downloads/newlisp_manual.html#foop http://www.newlisp.org/downloads/newlisp_manual.html#foop

lukifer 15y ago

Monoculture is a terrible thing. I don't think there are any frameworks or methodologies which should never be used, nor any that should always be used. Learn the advantages and tradeoffs of each, and use the right tool for the job. That said, I've personally found that as nice and clean as MVC frameworks can be, they aren't always necessary. As long as there is a separation between logic and presentation, it's possible to write clean, readable, maintainable code without a formal MVC structure.

shaydoc 15y ago

Personally from an ASP.NET perspective, its the same. To me ASP.NET is done. Mixing in server side with client side UI is just wrong, they should be decoupled completely. I want to build a html5/js/css UI. I want to keep it clean and I want to talk to a data service/ or mocked out data service to do what I need. Starting out with ASP.NET, I used to think this is just totally the wrong way to do things! Then ASP.NET MVC came along which was much nicer than all the pain of web forms ( viewstate etc..) , but now as I said already, I want my client side to be written with no knowledge of the server side workings, just plain old html(5)/css and leverage the power of javascript and associated frameworks ( i like knockout.js and amplify.js). Its the convergence on standards and the sophistication of browsers that really matters. We all use browsers, all the big vendors now are appreciating this, enabling progression to standard presentation technology. Innovative successful businesses are delivering great services and UX using these standards and they are showing the rest that they need to move to keep competing. Responsiveness and performance are strong drivers for a rich/smart/thick client, there really are very little advantages to a thin client in application terms from a UX point of view. Managing upgrades is a sinch with browsers, so if you have a sophisticated client side javascript UI its easy to re-release. All in all, I tend to agree poster here!

SkyMarshal 15y ago

If you poke around the newly redesigned http://html5rocks.com/ http://html5rocks.com/, this is pretty much exactly where they're going with it. Thick rich HTML5 app, cached in the client, and passing data back and forth between the server.

joemoon 15y ago
Friendly criticism: The background are really distracting (and not very aesthetically pleasing). There is not enough contrast with the light colored links. These two things combined make the whole sight difficult to read.

jebblue 15y ago

The first problem to solve is to eradicate completely JavaScript from the entire programming world 100%. After that, program the server and the client in Java or if on Windows, C#. GWT works this way although they compile the client code to JavaScript. If we remove JavaScript we get better performance, more deterministic behavior across platforms and totally eliminate one language we have to know making our lives easier and the browser thinner and better performing. When someone comes out with a browser that does that we will be seeing the next killer app.

j_baker 15y ago

I agree with the author, but for diametrically opposed reasons. It's more that I don't think my web framework should decide that I need to be using MVC. If I want to tightly couple my view logic to my model logic, that's my (and my team's) business. If I want to drink the MVC Koolaid, that's my business as well. It isn't the business of the person who wrote my framework. It's much simpler to handle views and view logic in only one place, and that place is slowly moving away from the server side. I see. So one is simpler than two? That's a bit simplistic. Every situation is unique, and it's impossible to make such a sweeping statement that's true in all cases.

programminggeek 15y ago

I don't think Rails-style MVC frameworks are going to disappear for a lot of content heavy internet sites, but API first architectures are going to continue to become popular I think. That is part of the reason I built radial https://github.com/RetroMocha/radial https://github.com/RetroMocha/radial The tooling around rapid API development seems very immature right now, but it's going to keep getting better. Once it is drop dead easy to write API's first, you will see a lot more apps having a HTML5 app, Android app, iOS app, Windows 8 app, Mac app, etc. as more of the standard and less of an edge case.

AlexeyMK 15y ago

One thing I've been playing around with is the idea of coupling ORM-style models with rules about how those models should be presented as a JSON-API. https://gist.github.com/1823921 https://gist.github.com/1823921 The approach breaks a lot of 'separation of concerns' rules between the view and the model, but for certain kinds of APIs (read-only, in particular) this may be fine. Would be interesting in feedback/seeing where similar projects have gone.

rzbn 15y ago

I'm not much of an expert but would putting everything on the client have a security risk? Also it's amazing how fast the we are moving most developers are still using PHP but on HN, the MVC frameworks are already hailed as obsolete

zoul 15y ago

On related note, it surprises me that client-side frameworks like cappuccino.org are not used more often for building full-featured web apps. It seems to me that the abstraction from HTML and CSS is quite a desirable thing, I find the experience of modern desktop frameworks like Cocoa thousand times better than fiddling with HTML. Does anybody here have substantial Cappuccino experience? Why isn't it more successful?

amorphid 15y ago

What I'd love to see is a set up where I log into any computer and my stuff is all right there. Say I borrow your iPhone to do some stuff. Instead of using your setup, I log in and all my apps are right there. Some run from the swrver, some get pushed to the phone and used locally if that's more efficient. Let's call it client & server, anywhere you go computing, or something like that. A client & server setup probably means that you buy access to a mobile carrier's calling/data plan that isn't attached to a data plan. You buy a handset, tablet, laptop, yada yada that is a standalone device or use one at the local Internet cafe. A set of standards are put in place for how code runs on a client and server. Your data may remain on a client, but ideally is stored entirely in the cloud, too. The cloud data is encrypted.and can't be accessed without your permission. This is my dream and I'd be surprised if I'm the first one to think of it.

velshin 15y ago

There's often a distinction between APIs intended for general consumption (platform APIs) and APIs optimized for JavaScript and/or mobile clients ("private" APIs). A platform API tends to be stable, versioned, well documented, and "unoptimized" or strongly RESTful. GETing a resource (noun) returns just that one representation. e.g. GET /v1/user/123/profile or GET api.linkedin.com/v1/people/id=123 "Private" APIs tend to return more data in bulk, optimized to reduce the quantity of remote calls and improve page load times. The responses tend to be structured in a way that's easier for the client (browser/mobile app) to render content, usually by including more tangentially related data than a traditional REST resource would contain. e.g. a browser's load of https://github.com/rails/rails https://github.com/rails/rails does GET github.com/rails/rails/graphs/participation Twitter uses the platform API in the browser. e.g. GET api.twitter.com/1/trends/1.json I'd be interested to hear from others leveraging APIs in their browser/mobile clients what they're using for MVC (e.g. backbone.js vs server side) and whether they've "optimized" their APIs for the client.

Eleopteryx 15y ago

Here's my anecdote: 1. I dumped view helpers for decorators (namely, the Draper gem). I got rid of complex logic in my view templates. Most of the logic I need in my views is transformed object properties. I need a date to appear as mm/dd/yy. I need a filesize in bytes to appear as KB/MB. I want a comment formatted as Markdown to be HTML. So now I'll decorate my objects so I have a nice post.formatted_date instead of needing to write the helper formatted_date(post). At worst I have some conditional statements in my views looking for the existence of a property. CSS also comes into play; the :empty selector allows me to cheat in some cases. 2. I write my view templates in a JavaScript templating language. I am a fan of slim for Ruby, so I went with Jade for JavaScript. I use therubyracer to call on these precompiled templates within Ruby itself, and render them like anything else. I then go on to use these same templates client-side. The reason why I abandoned view helpers to a large extent is because of this. Any logic that I need within a template would have to be duplicated server-side and client-side, which is antithetical to the goal. For my use-cases I've been able to do this successfully. It requires an adjustment to mindset, but is feasible. And really, my templates are a lot cleaner now than they've ever been. 3. When a user lands on a page, they get rendered HTML. Subsequent requests use AJAX and JSON responses to load things dynamically from there. Best of both worlds. Also, users who have JavaScript disabled can use the site albeit with not as much slickness. 4. Using to_json is hell; don't do it. I use the RABL gem for assembling my JSON, and use the same decorated objects. In the case of JSON, depending on your API, you might want to include say an ISO8601 date as well as a formatted date. Not a big deal, just vaguely duplicative. The downside was how much code I had to write for myself. Using JavaScript templates was a biggy. But this is something that could probably be packaged as a gem, if I or someone else took the time. The framework (in my case, Padrino) still provides lots of tools that I need. Ruby ORMs are a big part of this. There's still the issue of duplicative routes. I have routes defined in the app itself, and then within my JavaScript framework (currently Spine, but previously Backbone) I have to hardcode these same routes. I don't like this, however, routes are probably the last thing to change in my app if I put any thought into them ahead of time. This is something that requires additional thought, but I'm thinking there should be a way to get my app routes available client-side.