Perhaps there will still be a large demand for sites that aren't SPA applications. Interesting times.
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..
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?
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.
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 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)
- back-end requests - preferably swap-in-out (http, websockets)
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.
[1] - http://homing-on-code.blogspot.com/2014/11/dart-one-year-lat...
We use it in combination with Cordova and some other stuff like Haml Coffee Assets and Fastclick.js.
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.
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.
http://emberjs.com/api/classes/Ember.EachProxy.html
See the EachProxy class? Click on the class it extends.
http://emberjs.com/api/classes/Ember.Object.html
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...
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.
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'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.
It's a small advantage, but it's enough for me to prefer it.
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 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.
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.
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.
I could be very wrong, but I feel more comfortable keeping as much code on the server as possible.
tl;dr Wake me up when even 5% of sites are SPA.
5% of all web apps or new build apps?
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.
I'd say it's quite common to have clients in JS/iOS/Android, and still use a Rails-backend.
However SPA are the future. Maybe Angular 2 will be good enough to switch. Maybe something build after Angular 2.
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.
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.
[1] https://news.ycombinator.com/item?id=8671590 [2] 10 years ago it was a big thing. At that time typical app is was a bunch of PHP files.