Hacker News Reader

Comment by aikah | Hacker News Reader

> Perhaps there will still be a large demand for sites that aren't SPA applications. Interesting times.

It's isnt perhaps,99% of websites outthere arent SPAs.I'm pretty sure a majority of website you visit arent either.

> I'm curious about the fate of Rails(and other frameworks like Django) in a few years, seeing that many web applications are moving to the Single-Page-Application model and the server simply acts as a rest backend.

Why would you need a different framework for a "rest-backend" and a website that displays html? I dont understand.I pretty sure Rails has a "content negociation" like feature when it comes to json,xml,or html content types.

View on HN

> It's isnt perhaps,99% of websites outthere arent SPAs.I'm pretty sure a majority of website you visit arent either.

Currently 99% of websites are not SPAs, but I think a lot of sites will switch to SPAs in the future, since they offer a better UX(no full reloads, more interactivity etc) in most cases. I'm sure customers will demand these sort of sites once they start using more SPAs.

> Why would you need a different framework for a "rest-backend" and a website that displays html?

A full-stack framework is overkill as a backend for SPAs.

> A full-stack framework is overkill as a backend for SPAs.

A full stack framework doesnt(and shouldnt)force you to use its view layer.I fail to see how it is overkill.

What is overkill is using different frameworks for an app that spits json and an app that spits html.A good framework shouldnt care wether you return one or the other to the client,that's exactly what Rails does.

but I think a lot of sites will switch to SPAs in the future, since they offer a better UX

Actually I suspect that a lot of these kinds of sites will primarily migrate to native mobile apps.

A full-stack framework is overkill as a backend for SPAs.

I'm not so sure. HTML rendering is a pretty small part of what a complex framework like Rails does. You still need a database/ORM layer, user management and auth, routing, caching, etc. The same things that make Rails productive for traditional web apps also make it pretty nice for building REST APIs.

If you switch completely to native mobile applications you disappear from the web. That's a lot of people and a lot of incoming links. Mobile apps are less discoverable and they put the install time between "I want to see this" and "I can see this". Sites are trying hard to shave ms from the home page loading time, go figure how well it fits into the picture the minute it takes to decide to download something and get it installed. I think they'll go for a two pronged approach: traditional web site with content plus a mobile app (actually at least two of them). Furthermore, my phone can display an infinite amount of web sites but it can store only a not so large number of apps. And it doesn't have anything as convenient as start typing the name of a site to have the browser display the right url, inner pages included.

People always seem to prefer Sinatra over Rails for building a SPA backend, because 'rails is overkill'. Then they add Active Record, some autoloader implementation, rspec, caching, sidekiq etc and you end up with a cobbled together version of rails essentially. Rails-API is really nice here, strips out the things you truly don't need for a API in rails but keeps all the other infrastructure.

It works both ways though: I suspect that maybe most people on starting a rails project rip out half the gemfile as soon as 'rails new' has finished. Or they have their own skeleton projects with preferences already sorted out (rails api being a high point of the genre). Deconstructing a web framework isn't necessarily better than reconstructing one.

I'd beg to differ: at the very least it provides hints and conventions on common, useful, well-integrated gems. The Sinatra apps I've seen that had gotten a bit fatter over time tended to be all over the place, dependencies and quality wise (some good, mind you); whereas the deconstructed rails apps tended to be very similar, and easy for other developers to get up to speed with.

It's a small advantage, but it's enough for me to prefer it.

Yeah, I'm partly playing devil's advocate: for my day job I work with node, doing microservice-y stuff; on my own time, I prefer working with a Django or Rails type framework.

I appreciate the benefits of a 'batteries included' approach when, realistically, anything I build on my own is not going to have to horizontally scale across 50 EC2 boxes, although some of Rails's choices in terms of batteries are peculiar to me.

> I think a lot of sites will switch to SPAs in the future, since they offer a better UX(no full reloads, more interactivity etc) in most cases.

I'd argue they're a lot worse. More often than not, these sites kill the back button or the ability to bookmark a piece of content, are slow on barely old browsers and devices (still using an iPad 1st gen), tend to have fixed headers and footers that needlessly take up screen real estate or crazy pagination solutions, override scrolling and make it choppy and dysfunctional as a result, or outright crash mobile Safari by triggering out of memory errors.

> Currently 99% of websites are not SPAs, but I think a lot of sites will switch to SPAs in the future, since they offer a better UX(no full reloads, more interactivity etc) in most cases. I'm sure customers will demand these sort of sites once they start using more SPAs.

I can see highly interactive sites switching, but most sites are not highly interactive and would have no reason to switch to an SPA. For any content (as opposed to interaction) heavy site, like a blog, I can't see any advantage of an SPA. Server rendered pages can be cached and served lightning fast. For an SPA, in addition to the time to transfer the page content and assets (which is required for both server and SPA apps), they have to load a JS framework and then render the page browser side. This will cause slower load times, so I don't see many sites choosing this trade off unless they are highly interactive.

Reply on news.ycombinator.com