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.
Perhaps there will still be a large demand for sites that aren't SPA applications. Interesting times.
I've been doing web dev for 6 years, full stack, back and front, mostly somewhere in the middle and front end.
From what I've seen, backend rendering ain't going no where.
This SPA trends is still wild west. Angular 1 is kind slowing down imo cause of the drastic changes in Angular 2. Ember is bloat. The javascript eco system is meh right now.
NodeJS people probably will argue against this. But seriously, javascript needs a module system. RequireJS kinda suck with grunt, it doesn't work so well other grunt modules. Most of the frontend people I've met barely even use Bower. Sure maybe one that it'll be the future but right now it's unclear whose the winner and if people are willing to invest in something that can be obsolete in 1 or 2 years. Seeing how angular 2 is going to come out eventually a year or two, why learn angular 1?
Oh there's the react library and other stuff going on too. I haven't use that but it's getting traction...
Grunt and Glup are duking it out. In general it's just meh. I wouldn't bet on Angular or Ember anymore. Rails and Django or whatnot at least they're stable enough and have tons of people using it.
I'm kinda sick of it and moving toward backend really. It'll be fun architecturing stuff mesos, dockers, etc..
Not to one-up you, just since apparently it's worth mentioning, I've been doing webdev for about 9 years, and at least from my perspective backend rendering is definitely going out the window.
I started as a Rails dev in 2008, did ASP.Net before that, and last year I've moved from Rails to a pimped up Grape, which is a framework suited more for developing API's. Maybe it's just the sort of apps I'm building (basically SaaS) but I don't see any backend rendering in my feature, if I'm building it, it's going to be either a SPA, or a static site. (I built my sisters' band a single page static site, very nice).
Latest project is using Polymer, and no Javascript framework at all. I think you're right, Angular is extremely ugly, and Ember seems to do too much. But plain Javascript has become very powerful and HTML5+CSS3 reduce the need for UI toolkits.
Maybe I'm crazy, but I don't see a super hard need for modules either, I define all dependencies at a single location, and just bind everything to window. The not binding things to window rule is only for library/component developers, if you're an app developer you should own window, make it your home and have everything as you expect it to be.
Anyway, what I'm hoping is that new Rails editions focus more on the SPA experience, they have been reluctant to. I use Grape, but I immediately pimped it out with all the niceties Rails has, including ActiveSupport and ActiveRecord, but also a console and decent logging.
What I do worry about is the amount of people embracing Node.JS over Ruby. It's crazy people would chose Javascript over any language at all in an environment they're not absolutely forced to. My fear is one day I'll be seeking a job, and all there is is shops building webapps in vanilla Javascript, wouldn't that just be a plain horror story?
Bind everything to window is the same as "put everything in global".
It simply is not a long term viable strategy, we've been there, we've done that, it does not work. Perhaps that's not what you mean.
Also plain javascript doesn't have observables in most browsers, and any SPA without an observable system can only reach a certain level of complexity.
TBH, what you write is still so far from reality, that plain javascript is enough, that I am a little hesitant to take your comment seriously.
To be fair, I live a bit in the future. I build apps for tech people who are running up to date browsers, and that don't face the consuming billions. On top of that, Polymer polyfills webcomponents and two-way databinding of templates.
Perhaps my apps haven't gotten big enough to see this binding in global thing fail, but I'm not sure how it would ever. You properly namespace everything right?
I recently came to a similar opinion[1] of Angular like both of you though I was evaluating AgnularDart.
I decided to stick with plain Dart mostly of the reasons you mentioned (JavaScript ecosystem feeling like a mess). Polymer does look great but feels a bit unstable (at least for Dart).
What I would really love to see is a simple front-end framework handling:
- routing
- view encapsulation
- basic animations (when views are altered/loaded)
I ended up basically doing the above by hand in plain Dart. The only part that I found ready made and working nicely so far is the routing part[2] from Angular.
Is this stack something you'd consider documenting? Coming from Rails, but increasingly moving towards SPAs with Rails as the API (hard to give up all the OOTB niceties), this sounds intriguing.
I definitely am going to do that as soon as we're going to start marketing the app. But at the moment the way we built it is not very repeatable, I'd love to see a project that builds out grape to be more like a standalone framework like rails is, maybe if we get time we could do that.
> I'd love to see a project that builds out grape to be more like a standalone framework like rails is
You should check out Napa by Bellycard. It takes Grape and brings it together with things we all love from Rails like ActiveRecord, Rake and generators that make for a productive framework.
Sorry I missed your comment at the time you posted, and given the structure of HN, no sure you will see this reply, but thanks for posting that. Looks sure to make the transition smoother.
Ember, more strongly than any of the other solutions mentioned, pushes you to a browser application (or SPA) architecture. Usually developers who complain about bloat aren't thinking of web development in that context.
The number of challenges a framework should help a developer manage for a long-lived client-side JavaScript application is not trivial. It is absolutely true that Ember is heavier than other frameworks, but it has a specific style of development in mind. If someone chooses to build their app with an alternative, they often end up with a similar amount of code in other dependencies and application code.
And though we aren't there yet, we're working on ideas for modular loading of application code (via the pods patterns) and of Ember itself via tree shaking. This latter strategy leverages the fact that Ember's code and much app code is written in ES6, and thus we can identify and drop un-referenced code.
Oh look that object extends another class... apparently it uses Mixin to extend these classes maybe the apply function? If it's using prototype inheritance than looking up the prototype chain would be a performance hit IIRC.
I was doing Ember while during beta though. But during that time they were marketing Ember as smaller library and more performance than Angular.
The last bench mark I've seen, Ember library is much bigger and the performance was not that great compare to Angular...
I'm not certain if it's bloated, and if I was building a regular CRUD app I would probably have selected it over Angular. It just implemented some things I had the feeling I would do differently, i.e. I didn't want to pick a framework I would have to fight to get to work the way I wanted it to. Ember is being developed by some very smart guys so I would never dismiss it out of hand.
> 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.
> 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.
> 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.
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.
> 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.
> 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.
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.
I really don't think SPAs are very common, though following news of what's hot wouldn't suggest that. Honestly, I'd bet 95% of all web apps being built every day are traditional full request/response apps.
I think you really need to differentiate between web applications and websites. Websites still are a lot better off with primarily static websites in terms of SEO and performance (caching static pages is easier). For web applications a SPA approach definitely has advantages; for the biggest part in usability. Given that a vast majority of content on the web are pretty plain websites I'm sure Rails will stay relevant for quite a while longer.
I was always under the impression that these server based frameworks are better for two reasons, the code is safe, so you're leaking less of your code, and that the size of the website on the client is reduced allowing for faster downloads.
I could be very wrong, but I feel more comfortable keeping as much code on the server as possible.
Personally I think they're going to remain strong. More single page apps? Fine, but they still need to be backed by an API and, in most cases, a relational database. Yes there will be more frontend templating, and yes more mature fuller stack JS alternatives will emerge, but those role those frameworks fulfill is still needed, backend template rendering or not.
For over a decade I've heard that SPA and server-side JavaScript is the future. I always believed JavaScript would carve out a place on the server side, but I've always been skeptical about SPA given the often terrible UX and SEO. And besides that, most sites are better off being served statically from a cache.
Probably he doesn't mean only JavaScript SPAs. The term was introduced around 2010, but the concept is older. Flex is from ~2004 and is typically used for SPAs which behave like the modern JavaScript applications - they just target the Flash platform instead.
I think Javascript frameworks (like Meteor) will grow in prominence given the promise of code sharing between client and server, better integration with single-page applcation and better libraries for server-side processing.
That looks really interesting! Are there comparable approaches using python? I know there are multiple python-to-javascript compilers that could fit the role of opal, but I'm not aware of a whole framework.
The browser is becoming more of a platform to deploy to like Android or iOS, instead of a document viewer. I think it is still the wild wild west on the client side for now, but once winners emerge there will be a much larger group of developers creating SPA's. It seems Angular 2.0, Ember 2.0, and React 1.0 are all headed in similar directions with their emphasis on components, so a winning concept might emerge some time soon. That said, development trends on the web slowly play out over years. I expect Rails and Django to have a massive user base for 5+ years at least.
Rails works quite nicely as a REST backend. Its also much faster in my experience to render json than HTML templates. Rails is great as a general starting point, letting you choose SPA at the start or later.
Rails isn't going away, as there are plenty of sites on the internet that use it. Everything I build is in rails, and i like it that way. And it makes my life pretty awesome, and is enjoyable to work with. I really can't complain.
Single page is an option for some people, and there are several ways to get you there as well. But that's the great thing about the web: we have all kinds of ways to deliver an end product.
That doesn't make other rendering methods go away, though. Flash is still around, for example. And there's really no reason to project that rails will suffer some terrible fate in a few years time. It's been around for several years now and has done nothing but grow, so as long as it solves a problem and people go to it, it and other frameworks will hang around.
Ruby on Rails is still the most productive why to build web apps. Turbolinks prolonged Rails life cycle, as the best web framework, by two or three years.
However SPA are the future. Maybe Angular 2 will be good enough to switch. Maybe something build after Angular 2.
Probably because you haven't really provided any supporting evidence for your conclusions. Always show your working out. (Also, for many people, the first thing they do on a Rails project is disable Turbolinks.)
I actually happen to agree that Rails is still a supremely productive way to build certain types of web sites and/or applications. An experienced Rails guy, leveraging the vast array of gems out there which can solve many different problems with just a few lines of code, can get an MVP out of the door extremely quickly.
Two years ago I built an app using Angular. Of curse using Rails as the back-end. As a whole this wasn't a good experience. A such simple thing like authorization took a day or two to implement, solution looked like a one big hack.
However some SPA/Angular features worked beautiful. Two way data binding and local templates allow to build complex forms very easy. Data validation of one to many associations was straightforward. In Rails we have to use accepts_nested_attributes_for. It is so 'nice' that some people want to move nested attributes functionality to an external gem.
The biggest thing Rails is missing: components. There is a discussion today on HN [1] about this. Angular, web components, HTTP2 might really allow to build real object oriented web apps. In Rails there is a view.erb file and that's it [2].
I guess that competition will force developers to build even more user friendly and responsive apps. By that I mean no more separate pages to add a simple record. New apps will allow to click on a record, edit it in place and save with enter. And to do that well we need SPA architecture.
> Rails 5.0 is in most likelihood going to target Ruby 2.2. There's a bunch of optimizations coming in Ruby 2.2 that are going to be very nice, but most importantly for Rails, symbols are going to be garbage collected.
I'm looking forward for Rails 5 and Ruby 2.2 and the expected performance improvements.
Active Jobs, at least how implemented in 4.2 is not its own background processor. Its just a common api for using the background processor of your choice (Sidekiq, Resque, Delayed job etc).
ActievJob actually does default to :inline, which uses the Rails process to execute the job, so in a way, it kind of is it's own background processor, but you can easily swap out, as it implements an API for creating and scheduling jobs.
I've moved on to Napa by Bellycard. It takes Grape and brings it together with things we all love from Rails like ActiveRecord, Rake and generators that make for a productive framework.
Perhaps there will still be a large demand for sites that aren't SPA applications. Interesting times.