7 ms·
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 g
by 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 agoI'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.
- hello_moto 15y agoThe approach in the Java world for many years have been to implement Services (or Repository if it doesn't need a complex operations) and wrap them via facade pattern by utilizing: - JAX-RS (RESTful) - JAX-WS (WebService) - MVC (view-based web-app) And in contrast to what people believe, you don't need to write tons of code and still get full re-usability from the Services/Repositories layer. On the front-end, you have a choice of: - GWT for thick-client via RPC (return serialized Java object) or AJAX (return JSON) - JSP, JSF, any templating available - Mobile, Desktop, anything
- rudy750 15y agoCan you tell me more? I am currently looking for a solution. Looking at jersery. What are you working with?
- hello_moto 15y agoI use jersey (provided by glassfish).
- devs1010 15y agolook at spring roo, its a more modern approach and uses active record rather than the service layers / repositories, it makes generating json api's really simple
- hello_moto 15y agoA few points: 1) Spring Roo is not necessarily a more modern approach. It's more similar to Rails. 2) JAX-RS is more like Sinatra than Rails. Generating JSON api is already simple in JAX-RS. 3) Not everybody wants ActiveRecord http://www.braintreepayments.com/devblog/untangle-domain-and-persistence-logic-with-curator http://www.braintreepayments.com/devblog/untangle-domain-and... https://github.com/braintree/curator#readme https://github.com/braintree/curator#readme 4) JAX-RS comes with standard Java EE (moot point) 5) You can re-use your Servlet knowledge with JAX-RS to some extend (Filter, setting up web.xml, etc) Not to take anything away from Spring Roo which is a wonderful project.
- jshen 15y ago"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." You get better responsiveness if you send down pre-rendered html for the first page load. This means you still need the conditionals, or suffer on responsiveness.
- StavrosK 15y agoIs HTML rendering that much slower on the client than on the server?
- jshen 15y agoI'm serving mostly cached html from the server.
- jashkenas 15y agoNot in the slightest. Speaking categorically, JSON + templates are smaller to transfer over the wire than fully-rendered HTML -- and can be cached in exactly the same way ... even bootstrapped into a single HTTP request. If you care about optimizing it, you can get your JS UI to render faster than the equivalent pre-rendered HTML would have.
- stock_toaster 15y agoDon't you still have to render server side for crawlers and screen readers (accessibility)?
- bill-nordwall 15y agoNope. Screen readers have been able to handle javascript-generated content for years. According to WebAIM's most recent screen-reader survey, 98.4% of screen reader users have javascript enabled: http://webaim.org/projects/screenreadersurvey3/#javascript http://webaim.org/projects/screenreadersurvey3/#javascript
- DodgyEggplant 15y agoThis also requires a different way to work w/ designers. I would love to get parts and chunks designed and delivered ready to inject to existent app (e.g. a js template) rather than the whole page/psd approach.
- rolleiflex 15y agoI am a designer and I already work that way, if I am not misunderstanding you.