15 ms·

Escaping the SPA rabbit hole with modern Rails

274 points by mparramon 8y ago

cutler 8y ago
Turbolinks to the rescue. Slay the Javascript overlords!
deleted 8y ago
[deleted]
3pt14159 8y ago
I was initially skeptical, but this article nails the issues 100%. His experience mirrors my own and I don't think I even had a single place where I disagreed with him. All I would add is that rails can be made to work wonderfully with SPAs if you're willing to do some metamagical programming to auto-follow standards like JSON API.
everdev 8y ago
Anyone have good experiences with an SPA architecture?
- coldseattle 8y ago
  We used Elm + Erlang and have been very happy
- kkrs 8y ago
  Elm + Scala works for me. I'm using the same elm source with minor variations for both web & mobile (wrapped with cordova). So far, it's been working wonderfully.
  - virtualwhys 8y ago
    That's an odd choice given Scala.js, any reason you're not all-in on Scala?
    - kkrs 8y ago
      The elm architecture removes the need to make decisions when it comes to structuring the app. The tooling is first class. While I'm not sure, I think elm has a larger community.
- Roboprog 8y ago
  Yes. I/we are using AngularJS to update some applications (apps, NOT sites) that manage state forms from initiation within private organizations with a workflow through the counties up to the state. There is quite a bit of interactive validation and input formatting / lookup support in a small number of very long forms, so it helps to have most of the interaction on the client side. Also on the plus side, the back end requires less code now. IMHO, where Java is concerned, less of it is better. (There is still WAAAAAAAY too much of it, compared to equivalent Rails code) Javascript might not be quite as good of a “Simula 67” as Java is, but it’s a much better Smalltalk or Scheme than Java is :-). (A comparison which probably doesn’t hold for JS vs Ruby)
- adjkant 8y ago
  Yep, it's my go-to for any not huge web project. Plays well with any server-side tech you want, though I find Python (Flask, again with the right architecture, is a good experience) to be quite easy and enjoyable. The key is a sane and simple enough architecture from the start, which comes with experiences (aka making mistakes). But I personally go with Vue/Angular 1 consistently, trying to go more Vue now that Angular 2+ has IMO gone off the rails (heh).
- zenbai 8y ago
  Try developing Slack or Discord with Rails and turbolinks. The point is, some apps are naturally SPAs. For those that aren't then it is unneeded complexity to make them SPAs. Also personally, I have had great experience with Vue in an SPA.
- vmware513 8y ago
  Ember.js follows similar principals than Rails. Modern, matured, great ecosystem. You can move really fast with a Rails API and Ember.js frontend. Really, really fast.
wjossey 8y ago
To the author of the article- Kudos! Well written, well reasoned, with minimal hyperbole or unnecessary “X is dead” style declarations. Hope we see more writing like this bubble up to the top on HN. I’m not swayed by the argument, but that’s personal bias. I’m the technical cofounder / solo coder of a venture backed startup, and I built our platform on rails 5. I migrated our front end to Vue over the winter and couldn’t be happier. When we started (my cofounder and I) our company in early 2017, it had been a few years since I coded daily, and I’ve never been a front end programmer. I’m not well skilled in JS, so I punted on using any front end frameworks for the first six months. Our entire MVP was rails 5 server side rendered pages, with a dusting of jQuery when needed. It definitely got me as far as I needed it to, but I felt a lot of pain once I began to try to mix in a lot more interactivity in the app. For me, migrating to Vue made a lot of sense and continues to pay dividends. For others, the author’s arguments are probably far more applicable. One area where I deeply agree with the author is around how in JS I often don’t know exactly where I should write certain parts of my code. For a long time, I had a lot of model logic in my Vue components, but that quickly became a nightmare and I’ve abandoned that. Now I use ES6 classes to wrap a bunch of my logic, but even then I still find stuff bleeding places that seem wrong. One thing I also avoided so far was using any state management (a la Vuex). In some rare examples I use a message bus to send information around, but even then that usually triggers a component to go refetch information from the source of truth (the API endpoint). So far this pattern helps to restrict me from making certain lazy choices which will feel good in the moment but become maddening in the future. My app, as such, is not as maximally performant as it could be, but the trade off for the rare update has so far felt worth it. So, to sum it up, as a veteran coder who spends 12 hours a day writing code, but knew rails really well and not any SPA frameworks, I’m sympathetic to the article but respectfully have a different experience.
- sho 8y ago
  > I felt a lot of pain once I began to try to mix in a lot more interactivity in the app I don't think you're actually disagreeing at all. You're using the right tool for the job. You started with one job and the right tool, and when the job changed you switched tools. That's as it should be! Use Rails until you can't. That's what you did and I can't see the author disagreeing. You can generalise this to most technology. I know someone who has gotten it into his head that he needs to write his entire new web app using golang and microservices. I'd suggest that when he actually outgrows Rails enough to require that then he can suggest it to his 50-person-plus engineering team, but in truth I don't think he'll ever actually finish it.
ransom1538 8y ago
Has anyone used jquery mobile? It was an amazing project that let you write normal css/html/js without modifications THEN rendered the html+js into a SPA. It was fast, preloaded pages, clean, easy to write and really well documented - and maintained the root dom element. BUT! The project is mainly(opinion) dead. Instead people want to write in a new language (react,vue,etc) then deal with adding a massive layer of complexity.
- FreakyT 8y ago
  I dunno, my experience was that JQuery mobile was slow, bloated, and glitchy. Perhaps it was simply ahead of its time, and 2011-era browsers couldn't keep up with it, but either way I much prefer using its successors.
  - zdragnar 8y ago
    This is the first time I've ever heard of jquery mobile described as fast, and I used to work for a medium sized consultancy / agency (as in upwards of 50 front-end devs) that did a lot of projects with it. In fact, I don't really recall anyone speaking positively at all; at best it was a necessary evil.
- schizoidboy 8y ago
  I've used JQM for a SPA for years and it's old but works fine. I'm dreading the day they release the new version and finally remove deprecations (for good reason: to improve performance) because many add-ons and hacks will surely break. > The project is mainly(opinion) dead. I don't think it's dead so much as they are really worried about backwards compatibility (rightly so), so they're taking their time. It could also be argued that, for its purposes, it's not so much dead as nearly complete. On top of JQM, there's PhoneGap which I've also used for years and created both an Android and iOS app in the app stores. It allows you to access most native APIs through JavaScript shims. Overall, I've enjoyed the simplicity of JQM+PhoneGap (I use Rails as the backend). You can still layer on any other JS framework on top, so it's not limiting. My friends and I use the app daily and performance is fine on a modern phone. Having the same code (and I'd argue, look and feel as well) for web, mobile, and native is the best way to go for a small project trying to contain time and costs.
Mc_Big_G 8y ago
Without any input from me and several other js devs in our org, it was decided that we'll do a complete rewrite of our Ember.js app in React. The primary reason stated was hiring and the secondary was build times. The first should have been performance but they've been pretending like performance doesn't matter and that it's good enough. It's not. Since it's easier to develop, our backend admin system is built in .NET's MVC framework and it's lightning fast compared to our frontend. Like ridiculously fast. I'm not currently a backend dev but I have extensive experience with Rails and I've seen the same with Rails. It's fast. Despite the fact that I'm a front-end dev and it's not in my best interest, my un-requested recommendation was to do the rewrite in MVC, thus delivering everything from the server side. Here are my stated reasons: • The site will load and responds incredibly fast • The "build time" problem disappears • The "hiring a lot of specialized javascript developers" problem disappears • Backend devs suddenly become full-stack devs • Deploying is easier • Testing, both automated and manual, is easier • SEO is easier • You can now hire junior developers who are productive and don't create a mess in a new js framework • It's going to be supported for a long time, unlike the latest javascript-framework-of-the-day • Our website is a website full of mostly content and CRUD forms, not an app. We actually have very little "highly interactive" parts of our site and those that we do have can be a light-weight framework or simply a sprinkling of javascript. It should have never been an app in the first place. If everything had been build in Rails from the beginning, instead of .NET and Ember, we would have been twice as productive with half as many developers and wouldn't need QA at all if we wrote tests. This opinion was basically scoffed at with no valid counter-arguments given. They will move forward with a complete rewrite in React, which will solve none of their problems, except MAYBE hiring, and likely create more. They'll also probably do it without me. I'm not against SPAs or React when used for the correct reasons, especially considering I've been focused on front-end for the last 5 years, but I am vehemently opposed to bad decision making.
- zdragnar 8y ago
  "We actually have very little "highly interactive" parts of our site" That should have been your determining factor as to whether or not a SPA was appropriate. We've had the opposite experience; our new react SPA is noticibly faster than our current rails site, but it is due to the nature of the pages, not "X is always Y compared to Z"
schizoidboy 8y ago
> For your SPA logic, you will want a rich model of objects that represent your domain and its rules. And you still need the same for your server logic. And this recipe is just a duplication waiting to happen. Great article overall but one premise I question is: how often do you really need a non-jQuery JS framework at all in the client? It seems to me that most apps are simple CRUD apps and server-side rendering is sufficient. Sprinkle in jQuery for simple client functions. Use jQueryMobile for the SPA framework which improves performance by making an AJAX request for any navigation and replacing the page body (instead of doing a full page reload). I recommend only moving to a full non-jQuery based framework if the design or functions require it (and question that) or the app evolves to require it. As fast as computers, phones, and the internet are today, doing server-side rendering seems good enough for most apps.
- codingdave 8y ago
  You can go one step further and ask, if jQuery does the job for you, why do even need it? The core problems it solved (cross-browser reliability and DOM selections) aren't really problems anymore. Not that your point is invalid - many people do jump into modern frameworks for sites and apps that are simple enough to not need them. And SPAs don't need to be anywhere near as complex as this article proposes. But if you are going to go down the road of recommending simpler architectures, without a framework approach, then commit to it fully, and just go with vanilla JS.
  - mythrwy 8y ago
    jQuery makes it easier though, particularly if you know it well.
- woah 8y ago
  In jquery programming there’s a huge difference between how the stuff that shows up when loaded is programmed (on the backend) and how the changes you make after it’s loaded are programmed. This leads to a lot of weird inconsistency if you’re doing anything more than showing and hiding existing content. Also, with jquery everything involves a lot of imperative programming and stashing state in random places in the DOM. If you’re doing anything more complex than drop downs and modal windows, use a frontend framework or your code will devolve into a huge pile of spaghetti.
lucidone 8y ago
Are you building a website? The practices espoused by the author will be ideal. Are you building a web app? Will you have a mobile client alongside your web app? Using a javascript framework for your client(s) and decoupling your data from it's presentation will be a fruitful investment. All of these frameworks and their associated happened for reasons, and they didn't involve traditional MVC being good enough for everything. As an aside, I find this viewpoint prevalent in the Rails community and the Rails job I had (so, caveat, I'm coloured by my personal experience). It also lead to a culture of staunch refusal to learn or do anything new in that job, and the quality of the product suffered. It consequently led to me leaving the job, and being much happier for it.
- sho 8y ago
  > decoupling your data from it's presentation will be a fruitful investment Very good point. You'll be building an API anyway if you want a mobile app. However, you can probably get away with a much smaller one, for only the most interactive parts of the app - I've gotten a lot of mileage out of simply embedding web pages for fiddly things like settings pages and other complex forms in mobile apps, saving the native API-driven section for only when needed. The hybrid approach can actually save on mobile implementation time in that way, too. > a culture of staunch refusal to learn or do anything new in that job Sigh. I have encountered this too. But I think it's mainly a person-by-person, or perhaps team culture, issue, coupled with the fact that Rails has been around a long time. I've been using Rails since it's in beta and am very happy to use React et al when called for. Sadly, when (if?) React gets to 10 years old, you're going to see the same thing on that side of the fence! There's a certain type of person who's always going to be grumpy about learning something new.
  - mooreds 8y ago
    > There's a certain type of person who's always going to be grumpy about learning something new. I resemble that remark :). But I hear you, sometimes you have to invest to figure out if something is any good, and one way to do so is to build something real with it. However there's danger on the other side too--a company with 5 different apps in 5 different frameworks or languages that all have to be supported by a small team of developers. That can't leverage deployment or performance tuning knowledge across apps. Where work is siloed because "Dev X doesn't know golang and Dev Y doesn't know rails". And where you can't rewrite the app because the business leaders wonder what they'd get.
cmjqol 8y ago
Like others comments , Kudos to the authors. I'm an SPA Lover ( Angular , Vue ) , but still most of the points raised here a coherent from a back end perspective. That said , a lot of the arguments are basically summed up as : "I don't like Front End Dev. because it's not as mature as Back End". I will not lie on this point , JS is a fast evolving ecosystem that sometimes has issues to stabilize. Hence , there is a lot of marketing and self promotion mixed with frameworks sometimes ( Growth Hacking ) pushing for unnecessary tech that dies a few days after they have leaved the Github Trending page. For beginners , when a framework reach a certain threshold ( Github Stars most of the time) they feel like they should hurry and use the framework to stay relevant while most of the time they don't need to and the tech is just fluff. My point here is very simple, you are ROR or Django or ASP.NET dev and you love what you do ? As long as you find jobs keep doing this , don't bother with Full Stack Fluff. Now that said , I can only encourage the author to do the Angular or Vue tutorial to discover something different. Rails is great ( it's empowering a lot of website Github , Airbnb etc... ) but SPA are different and when used properly it's hard to go back , the experience is delightful. Most importantly we are getting closer to the serverless era where backend will be completly different from what it is compared as now, and SPA and SSR will likely be the standard in the future.
- sho 8y ago
  I think you've missed the article's point: > I don't like Front End Dev. because it's not as mature as Back End No, he says don't do FE and BE when the tools for back end-only (well, Rails is full stack, actually) are so useful and productive. And in the rest of your comment you seem to forget that a front end is completely useless without a back end. > you are ROR or Django or ASP.NET dev and you love what you do ? As long as you find jobs keep doing this , don't bother with Full Stack Fluff. Rails is the "Full Stack Fluff". > SPA and SSR will likely be the standard in the future How, exactly? What serves your SPA? And who is using "serverless" for anything other than querying other backends (eg Slack bots) or accessing AWS services? I mean, sure, it's nice to not have to stand up a server to resize images coming from S3 but it's hardly going to replace, well, servers. You couldn't implement even the simplest CRUD app.
  - 8y ago
zmmmmm 8y ago
I have to admit, I do not know Turbolinks well, but I feel like the author misses something fundamental about the benefits of modern frameworks. It's not just about building a giant SPA - component-based design is a huge value proposition. The problem I see at the moment is that client side "apps" - however they are rendered - hit a wall in complexity that is really hard to overcome without a a sane and sensible way to break them down into pieces. Just like every sane regular programming language has concepts of classes or modules or some kind of system for divide-and-conquering problems into pieces, your front end needs that too once it gets complex. And that's what these React/VueJS frameworks are doing for me. What I like is that they make the right solution - breaking a piece of logic or code into its own component - the easiest solution. So I tend to do the right thing, not because it's "the right thing" but because it happens to be the easiest thing to do. I know this is a bit of a parallel argument with respect to whether you build a SPA or not (especially Vue can live in either world just fine). But I feel like the author is throwing out the component-baby with the SPA bathwater.
- simplecomplex 8y ago
  Components aren’t a well defined thing. Most people mean “React class” when they say component. React apps are much more than components. Some components have their own state, some don’t, some touch global state, routing and data fetching are often not components. “Component” web apps are by no means simple.
- acdha 8y ago
  > Just like every sane regular programming language has concepts of classes or modules or some kind of system for divide-and-conquering problems into pieces, your front end needs that too once it gets complex. And that's what these React/VueJS frameworks are doing for me. One question which should be included in that is whether you need a huge framework and supporting toolchain or just ES6 classes. There’s a good argument that using standard features will last you longer than frameworks which rapidly go in and out of vogue, and it avoids the constant frictional support costs of regular forced upgrades and debugging complications.
- noxecanexx 8y ago
  You can do the same with server rendered apps. I don't think reacted and co invented components
meesterdude 8y ago
A very well thought out and articulated article. I love Rails and the power it offers in development productivity and quality. It's code is very maintainable and actually enjoyable to develop in; even when it's someone elses codebase. Oddly enough, I finally came upon a use case in a project where an SPA frontend (Vue) / ruby backend make more sense given the platform nature and operational needs (runs on a pi, no "models") 9/10 Rails is the way to go though for developing something.
Illniyar 8y ago
Replacing the entire body with every request seems a bit overkill. If you want SPA interactivity without moving control to the client side, try intercooler.js http://intercoolerjs.org http://intercoolerjs.org
swlkr 8y ago
I had this same experience. SPAs, especially for small teams and solo developers, hurt more than they help.
peteforde 8y ago
I have nothing against SPAs for complex UI interactions. It's sort of like taking anti-biotics; there should be a moment of reflection when you should justify your true need, lest the cure be worse than the disease. Most developers of a certain age have come up when it's SPA by default, and can't truly defend why they need it. In this thread, there are several claims that it's impossible to write well-organized jQuery. That sounds an awful lot like dogma to me. Also, your inability to write well-organized code says more about your coding and team-management skills than it does about any one approach. Any tech is only as good as the team using it. A few years ago, Sam Stephenson (who originally wrote the Prototype library, before jQuery was a thing) gave an excellent talk on Turbolinks at RailsConf. I recommend the whole talk (turn it up to 1.5x speed, of course) but at 4:12 he does an amazing job of showing how the SPA path leads to insanity. https://www.youtube.com/watch?v=SWEts0rlezA https://www.youtube.com/watch?v=SWEts0rlezA Here's a mental exercise for you: the next time you start a new project, instead of deciding which SPA framework to use, start with an assumption that an SPA is wild overkill for the first iteration of your application - especially if few people on your team have working expertise with the SPA in question. Then see if you can argue FOR the tech. It's much harder to justify something you don't need if you start with an honest conversation about how you probably don't need it. (This works for throwing out CDs, too: start with the assumption that they are all garbage, they all go. Then force yourself to make logic-based arguments for each one you keep. Your outcome will be night and day from if you start with everything in a keep pile.)
- divs1210 8y ago
  Sounds like you haven't been introduced to reagent. https://reagent-project.github.io https://reagent-project.github.io
  - y4mi 8y ago
    sounds like you didn't actually understand the parents point.
    - hashkb 8y ago
      Or that you need to be introduced to Reagent. Simple doesn't even begin to describe it.
stevebmark 8y ago
Rails is a deeply flawed framework, and we need to stop using Basecamp as the example of a well designed monolith. Basecamp is terrible software, and the crappiness of the user interface appears to be a direct result of not being able to build rich interfaces as its coupled to legacy Rails designs like this article suggests. Basecamp being fast while getting a trickle of traffic and working with very little data is not a selling point against SPAs (I'm not pro or con SPA).
- rimliu 8y ago
  What are the deep flaws in Rails? What's crappy about Basecamp UI?
Dirak 8y ago
I honestly feel this article is everything that's wrong with web development and this attachment that older developers have for MVC is a ghost that really needs to be addressed once and for all. Seriously. MVC is dead and we need to let it stay dead. SPA architectures are so braindead easy to implement, maintain, and understand that it's ridiculous that developers are still clinging on to their monolithic event driven server-side MVC monstrosities. An SPA architecture is very simple and it does a great job of implementing a strong degree of separation of concerns and maintainability. Essentially, a proper SPA architecture looks like: one backend server that exposes a CRUD REST API (that could call lambda functions here and there when you need to do complex calculations), and then you have your SPA which is hosted on a static file storage service and it's literally just a bundle of html, css, and JS files. Example architecture: EC2 (Backend) <-> S3 (Frontend) <-> Cloudfront It's that simple. Our backend is a feature complete version of our application that we can interface using HTTP methods, which is incredibly powerful because it means we can have multiple clients (native, mobile, web) that all interface the backend instead of coupling the view to the server as we would do using what you suggest in your article. And building an SPA that interfaces a REST API doesn't mean reinventing the wheel. You and other developers who are too stubborn to look past their MVC bubble are just ignorant of the massive amounts of progress over the last ~5 years that the web development community has made in enabling SPA best practices. Just look at Vue-Cli or Create React App. They're incredibly well documented resources and it's incredibly easy to onboard an engineering team onto a SPA project because of how developed the front-end ecosystem is. Everything you would ever want to do has been done before and theres an infinite number of resources to consult when trying to decide what's best practice. The web development community is bar-none the biggest open source community right now and it shows. I've on boarded teams of developers to using SPAs and when they come from a background of MVC they tend to fall in love with the idea of components and encapsulation and philosophies of React and they become agile like you would not believe. Also it's funny you praise the model-2 variant MVC pattern. I just moved a team away from an architecture like that to a SPA one and the difference in productivity from the team was night and day. That architecture was fucking disgusting monstrosity and it should stay in 2008.
- GordonS 8y ago
  > this attachment that older developers have for MVC is a ghost that really needs to be addressed once and for all. Seriously. MVC is dead and we need to let it stay dead What needs to die is this grounded-in-fantasy contempt for mature, very much alive, performant technologies with huge ecosystems.
fred123 8y ago
I wonder how the argument changes if you know you need an API for your mobile application that's almost identical in features to the web page. If you go the "Rails/Django way" with server side rendered templates and, say, a bit of jQuery for fancy stuff -- you'll end up duplicating lots of code for the API (validation, routing, maybe even business logic). Anyone got experience with swapping your models/controllers for an API while keeping the rest of Django's/Rails' niceties? (authentication/sessions, Django's forms system, CSRF, etc.) OTOH having Django/Rails merely as a template system you probably could also go for very simple, self-contained client-rendered JS pages (e.g. .vue files). Not much difference there I guess?
- noxecanexx 8y ago
  I think it should still be possible to seperate view from the service at the backend, even if that means defining more routes. I am talking from the hiccup(clj) point of view though
_pdp_ 8y ago
Speaking of code duplication in a traditional web app every page is an example of code duplication. How about that?
PythonicAlpha 8y ago
The main problems addressed in my opinion: - Code duplication between server and client side - Added complication threw data transmission between server and client (REST/json) I think, both problems can be addressed by: - having (a single) code that works both on server and client-side - having transparent transport mechanisms for information between client and server. I am sure, I could implement such a thing for Python/Django, using the already existing tools. But I am not sure, if such a thing would be appreciated by the community. What do you think?
arwhatever 8y ago
Using a framework like the F#-to-JavaScript transpiler Fable, along with an application framework like Elmish, provides a really good solution to some of the pitfalls cited in the article (prescriptive architecture, front + back-end code sharing) and gives you some moderately strong type safety to boot. However, the article author's list of SPA pitfalls is really good, and are probably not all surmountable by a framework/platform.
Bizarro 8y ago
There was probably a few valid points, but the article was too long with too many flimsy, "try-hard to convince" arguments.
randop 8y ago
I feel like seeing more and more post about criticisms for workflow or framework that it is becoming unhealthy with the developer community. There is always short comings on every tool and library, and part of responsibility of a good developer is discerning trade-offs.

274 points by mparramon 8y ago

cutler 8y ago

Turbolinks to the rescue. Slay the Javascript overlords!

deleted 8y ago

[deleted]

3pt14159 8y ago

I was initially skeptical, but this article nails the issues 100%. His experience mirrors my own and I don't think I even had a single place where I disagreed with him. All I would add is that rails can be made to work wonderfully with SPAs if you're willing to do some metamagical programming to auto-follow standards like JSON API.

everdev 8y ago

Anyone have good experiences with an SPA architecture?

coldseattle 8y ago
We used Elm + Erlang and have been very happy
kkrs 8y ago
Elm + Scala works for me. I'm using the same elm source with minor variations for both web & mobile (wrapped with cordova). So far, it's been working wonderfully.
- virtualwhys 8y ago
  That's an odd choice given Scala.js, any reason you're not all-in on Scala?
  - kkrs 8y ago
    The elm architecture removes the need to make decisions when it comes to structuring the app. The tooling is first class. While I'm not sure, I think elm has a larger community.
Roboprog 8y ago
Yes. I/we are using AngularJS to update some applications (apps, NOT sites) that manage state forms from initiation within private organizations with a workflow through the counties up to the state. There is quite a bit of interactive validation and input formatting / lookup support in a small number of very long forms, so it helps to have most of the interaction on the client side. Also on the plus side, the back end requires less code now. IMHO, where Java is concerned, less of it is better. (There is still WAAAAAAAY too much of it, compared to equivalent Rails code) Javascript might not be quite as good of a “Simula 67” as Java is, but it’s a much better Smalltalk or Scheme than Java is :-). (A comparison which probably doesn’t hold for JS vs Ruby)
adjkant 8y ago
Yep, it's my go-to for any not huge web project. Plays well with any server-side tech you want, though I find Python (Flask, again with the right architecture, is a good experience) to be quite easy and enjoyable. The key is a sane and simple enough architecture from the start, which comes with experiences (aka making mistakes). But I personally go with Vue/Angular 1 consistently, trying to go more Vue now that Angular 2+ has IMO gone off the rails (heh).
zenbai 8y ago
Try developing Slack or Discord with Rails and turbolinks. The point is, some apps are naturally SPAs. For those that aren't then it is unneeded complexity to make them SPAs. Also personally, I have had great experience with Vue in an SPA.
vmware513 8y ago
Ember.js follows similar principals than Rails. Modern, matured, great ecosystem. You can move really fast with a Rails API and Ember.js frontend. Really, really fast.

wjossey 8y ago

To the author of the article- Kudos! Well written, well reasoned, with minimal hyperbole or unnecessary “X is dead” style declarations. Hope we see more writing like this bubble up to the top on HN. I’m not swayed by the argument, but that’s personal bias. I’m the technical cofounder / solo coder of a venture backed startup, and I built our platform on rails 5. I migrated our front end to Vue over the winter and couldn’t be happier. When we started (my cofounder and I) our company in early 2017, it had been a few years since I coded daily, and I’ve never been a front end programmer. I’m not well skilled in JS, so I punted on using any front end frameworks for the first six months. Our entire MVP was rails 5 server side rendered pages, with a dusting of jQuery when needed. It definitely got me as far as I needed it to, but I felt a lot of pain once I began to try to mix in a lot more interactivity in the app. For me, migrating to Vue made a lot of sense and continues to pay dividends. For others, the author’s arguments are probably far more applicable. One area where I deeply agree with the author is around how in JS I often don’t know exactly where I should write certain parts of my code. For a long time, I had a lot of model logic in my Vue components, but that quickly became a nightmare and I’ve abandoned that. Now I use ES6 classes to wrap a bunch of my logic, but even then I still find stuff bleeding places that seem wrong. One thing I also avoided so far was using any state management (a la Vuex). In some rare examples I use a message bus to send information around, but even then that usually triggers a component to go refetch information from the source of truth (the API endpoint). So far this pattern helps to restrict me from making certain lazy choices which will feel good in the moment but become maddening in the future. My app, as such, is not as maximally performant as it could be, but the trade off for the rare update has so far felt worth it. So, to sum it up, as a veteran coder who spends 12 hours a day writing code, but knew rails really well and not any SPA frameworks, I’m sympathetic to the article but respectfully have a different experience.

sho 8y ago
> I felt a lot of pain once I began to try to mix in a lot more interactivity in the app I don't think you're actually disagreeing at all. You're using the right tool for the job. You started with one job and the right tool, and when the job changed you switched tools. That's as it should be! Use Rails until you can't. That's what you did and I can't see the author disagreeing. You can generalise this to most technology. I know someone who has gotten it into his head that he needs to write his entire new web app using golang and microservices. I'd suggest that when he actually outgrows Rails enough to require that then he can suggest it to his 50-person-plus engineering team, but in truth I don't think he'll ever actually finish it.

ransom1538 8y ago

Has anyone used jquery mobile? It was an amazing project that let you write normal css/html/js without modifications THEN rendered the html+js into a SPA. It was fast, preloaded pages, clean, easy to write and really well documented - and maintained the root dom element. BUT! The project is mainly(opinion) dead. Instead people want to write in a new language (react,vue,etc) then deal with adding a massive layer of complexity.

FreakyT 8y ago
I dunno, my experience was that JQuery mobile was slow, bloated, and glitchy. Perhaps it was simply ahead of its time, and 2011-era browsers couldn't keep up with it, but either way I much prefer using its successors.
- zdragnar 8y ago
  This is the first time I've ever heard of jquery mobile described as fast, and I used to work for a medium sized consultancy / agency (as in upwards of 50 front-end devs) that did a lot of projects with it. In fact, I don't really recall anyone speaking positively at all; at best it was a necessary evil.
schizoidboy 8y ago
I've used JQM for a SPA for years and it's old but works fine. I'm dreading the day they release the new version and finally remove deprecations (for good reason: to improve performance) because many add-ons and hacks will surely break. > The project is mainly(opinion) dead. I don't think it's dead so much as they are really worried about backwards compatibility (rightly so), so they're taking their time. It could also be argued that, for its purposes, it's not so much dead as nearly complete. On top of JQM, there's PhoneGap which I've also used for years and created both an Android and iOS app in the app stores. It allows you to access most native APIs through JavaScript shims. Overall, I've enjoyed the simplicity of JQM+PhoneGap (I use Rails as the backend). You can still layer on any other JS framework on top, so it's not limiting. My friends and I use the app daily and performance is fine on a modern phone. Having the same code (and I'd argue, look and feel as well) for web, mobile, and native is the best way to go for a small project trying to contain time and costs.

Mc_Big_G 8y ago

Without any input from me and several other js devs in our org, it was decided that we'll do a complete rewrite of our Ember.js app in React. The primary reason stated was hiring and the secondary was build times. The first should have been performance but they've been pretending like performance doesn't matter and that it's good enough. It's not. Since it's easier to develop, our backend admin system is built in .NET's MVC framework and it's lightning fast compared to our frontend. Like ridiculously fast. I'm not currently a backend dev but I have extensive experience with Rails and I've seen the same with Rails. It's fast. Despite the fact that I'm a front-end dev and it's not in my best interest, my un-requested recommendation was to do the rewrite in MVC, thus delivering everything from the server side. Here are my stated reasons: • The site will load and responds incredibly fast • The "build time" problem disappears • The "hiring a lot of specialized javascript developers" problem disappears • Backend devs suddenly become full-stack devs • Deploying is easier • Testing, both automated and manual, is easier • SEO is easier • You can now hire junior developers who are productive and don't create a mess in a new js framework • It's going to be supported for a long time, unlike the latest javascript-framework-of-the-day • Our website is a website full of mostly content and CRUD forms, not an app. We actually have very little "highly interactive" parts of our site and those that we do have can be a light-weight framework or simply a sprinkling of javascript. It should have never been an app in the first place. If everything had been build in Rails from the beginning, instead of .NET and Ember, we would have been twice as productive with half as many developers and wouldn't need QA at all if we wrote tests. This opinion was basically scoffed at with no valid counter-arguments given. They will move forward with a complete rewrite in React, which will solve none of their problems, except MAYBE hiring, and likely create more. They'll also probably do it without me. I'm not against SPAs or React when used for the correct reasons, especially considering I've been focused on front-end for the last 5 years, but I am vehemently opposed to bad decision making.

zdragnar 8y ago
"We actually have very little "highly interactive" parts of our site" That should have been your determining factor as to whether or not a SPA was appropriate. We've had the opposite experience; our new react SPA is noticibly faster than our current rails site, but it is due to the nature of the pages, not "X is always Y compared to Z"

schizoidboy 8y ago

> For your SPA logic, you will want a rich model of objects that represent your domain and its rules. And you still need the same for your server logic. And this recipe is just a duplication waiting to happen. Great article overall but one premise I question is: how often do you really need a non-jQuery JS framework at all in the client? It seems to me that most apps are simple CRUD apps and server-side rendering is sufficient. Sprinkle in jQuery for simple client functions. Use jQueryMobile for the SPA framework which improves performance by making an AJAX request for any navigation and replacing the page body (instead of doing a full page reload). I recommend only moving to a full non-jQuery based framework if the design or functions require it (and question that) or the app evolves to require it. As fast as computers, phones, and the internet are today, doing server-side rendering seems good enough for most apps.

codingdave 8y ago
You can go one step further and ask, if jQuery does the job for you, why do even need it? The core problems it solved (cross-browser reliability and DOM selections) aren't really problems anymore. Not that your point is invalid - many people do jump into modern frameworks for sites and apps that are simple enough to not need them. And SPAs don't need to be anywhere near as complex as this article proposes. But if you are going to go down the road of recommending simpler architectures, without a framework approach, then commit to it fully, and just go with vanilla JS.
- mythrwy 8y ago
  jQuery makes it easier though, particularly if you know it well.
woah 8y ago
In jquery programming there’s a huge difference between how the stuff that shows up when loaded is programmed (on the backend) and how the changes you make after it’s loaded are programmed. This leads to a lot of weird inconsistency if you’re doing anything more than showing and hiding existing content. Also, with jquery everything involves a lot of imperative programming and stashing state in random places in the DOM. If you’re doing anything more complex than drop downs and modal windows, use a frontend framework or your code will devolve into a huge pile of spaghetti.

lucidone 8y ago

Are you building a website? The practices espoused by the author will be ideal. Are you building a web app? Will you have a mobile client alongside your web app? Using a javascript framework for your client(s) and decoupling your data from it's presentation will be a fruitful investment. All of these frameworks and their associated happened for reasons, and they didn't involve traditional MVC being good enough for everything. As an aside, I find this viewpoint prevalent in the Rails community and the Rails job I had (so, caveat, I'm coloured by my personal experience). It also lead to a culture of staunch refusal to learn or do anything new in that job, and the quality of the product suffered. It consequently led to me leaving the job, and being much happier for it.

sho 8y ago
> decoupling your data from it's presentation will be a fruitful investment Very good point. You'll be building an API anyway if you want a mobile app. However, you can probably get away with a much smaller one, for only the most interactive parts of the app - I've gotten a lot of mileage out of simply embedding web pages for fiddly things like settings pages and other complex forms in mobile apps, saving the native API-driven section for only when needed. The hybrid approach can actually save on mobile implementation time in that way, too. > a culture of staunch refusal to learn or do anything new in that job Sigh. I have encountered this too. But I think it's mainly a person-by-person, or perhaps team culture, issue, coupled with the fact that Rails has been around a long time. I've been using Rails since it's in beta and am very happy to use React et al when called for. Sadly, when (if?) React gets to 10 years old, you're going to see the same thing on that side of the fence! There's a certain type of person who's always going to be grumpy about learning something new.
- mooreds 8y ago
  > There's a certain type of person who's always going to be grumpy about learning something new. I resemble that remark :). But I hear you, sometimes you have to invest to figure out if something is any good, and one way to do so is to build something real with it. However there's danger on the other side too--a company with 5 different apps in 5 different frameworks or languages that all have to be supported by a small team of developers. That can't leverage deployment or performance tuning knowledge across apps. Where work is siloed because "Dev X doesn't know golang and Dev Y doesn't know rails". And where you can't rewrite the app because the business leaders wonder what they'd get.

cmjqol 8y ago

Like others comments , Kudos to the authors. I'm an SPA Lover ( Angular , Vue ) , but still most of the points raised here a coherent from a back end perspective. That said , a lot of the arguments are basically summed up as : "I don't like Front End Dev. because it's not as mature as Back End". I will not lie on this point , JS is a fast evolving ecosystem that sometimes has issues to stabilize. Hence , there is a lot of marketing and self promotion mixed with frameworks sometimes ( Growth Hacking ) pushing for unnecessary tech that dies a few days after they have leaved the Github Trending page. For beginners , when a framework reach a certain threshold ( Github Stars most of the time) they feel like they should hurry and use the framework to stay relevant while most of the time they don't need to and the tech is just fluff. My point here is very simple, you are ROR or Django or ASP.NET dev and you love what you do ? As long as you find jobs keep doing this , don't bother with Full Stack Fluff. Now that said , I can only encourage the author to do the Angular or Vue tutorial to discover something different. Rails is great ( it's empowering a lot of website Github , Airbnb etc... ) but SPA are different and when used properly it's hard to go back , the experience is delightful. Most importantly we are getting closer to the serverless era where backend will be completly different from what it is compared as now, and SPA and SSR will likely be the standard in the future.

sho 8y ago
I think you've missed the article's point: > I don't like Front End Dev. because it's not as mature as Back End No, he says don't do FE and BE when the tools for back end-only (well, Rails is full stack, actually) are so useful and productive. And in the rest of your comment you seem to forget that a front end is completely useless without a back end. > you are ROR or Django or ASP.NET dev and you love what you do ? As long as you find jobs keep doing this , don't bother with Full Stack Fluff. Rails is the "Full Stack Fluff". > SPA and SSR will likely be the standard in the future How, exactly? What serves your SPA? And who is using "serverless" for anything other than querying other backends (eg Slack bots) or accessing AWS services? I mean, sure, it's nice to not have to stand up a server to resize images coming from S3 but it's hardly going to replace, well, servers. You couldn't implement even the simplest CRUD app.
- 8y ago

zmmmmm 8y ago

I have to admit, I do not know Turbolinks well, but I feel like the author misses something fundamental about the benefits of modern frameworks. It's not just about building a giant SPA - component-based design is a huge value proposition. The problem I see at the moment is that client side "apps" - however they are rendered - hit a wall in complexity that is really hard to overcome without a a sane and sensible way to break them down into pieces. Just like every sane regular programming language has concepts of classes or modules or some kind of system for divide-and-conquering problems into pieces, your front end needs that too once it gets complex. And that's what these React/VueJS frameworks are doing for me. What I like is that they make the right solution - breaking a piece of logic or code into its own component - the easiest solution. So I tend to do the right thing, not because it's "the right thing" but because it happens to be the easiest thing to do. I know this is a bit of a parallel argument with respect to whether you build a SPA or not (especially Vue can live in either world just fine). But I feel like the author is throwing out the component-baby with the SPA bathwater.

simplecomplex 8y ago
Components aren’t a well defined thing. Most people mean “React class” when they say component. React apps are much more than components. Some components have their own state, some don’t, some touch global state, routing and data fetching are often not components. “Component” web apps are by no means simple.
acdha 8y ago
> Just like every sane regular programming language has concepts of classes or modules or some kind of system for divide-and-conquering problems into pieces, your front end needs that too once it gets complex. And that's what these React/VueJS frameworks are doing for me. One question which should be included in that is whether you need a huge framework and supporting toolchain or just ES6 classes. There’s a good argument that using standard features will last you longer than frameworks which rapidly go in and out of vogue, and it avoids the constant frictional support costs of regular forced upgrades and debugging complications.
noxecanexx 8y ago
You can do the same with server rendered apps. I don't think reacted and co invented components

meesterdude 8y ago

A very well thought out and articulated article. I love Rails and the power it offers in development productivity and quality. It's code is very maintainable and actually enjoyable to develop in; even when it's someone elses codebase. Oddly enough, I finally came upon a use case in a project where an SPA frontend (Vue) / ruby backend make more sense given the platform nature and operational needs (runs on a pi, no "models") 9/10 Rails is the way to go though for developing something.

Illniyar 8y ago

Replacing the entire body with every request seems a bit overkill. If you want SPA interactivity without moving control to the client side, try intercooler.js http://intercoolerjs.org http://intercoolerjs.org

swlkr 8y ago

I had this same experience. SPAs, especially for small teams and solo developers, hurt more than they help.

peteforde 8y ago

I have nothing against SPAs for complex UI interactions. It's sort of like taking anti-biotics; there should be a moment of reflection when you should justify your true need, lest the cure be worse than the disease. Most developers of a certain age have come up when it's SPA by default, and can't truly defend why they need it. In this thread, there are several claims that it's impossible to write well-organized jQuery. That sounds an awful lot like dogma to me. Also, your inability to write well-organized code says more about your coding and team-management skills than it does about any one approach. Any tech is only as good as the team using it. A few years ago, Sam Stephenson (who originally wrote the Prototype library, before jQuery was a thing) gave an excellent talk on Turbolinks at RailsConf. I recommend the whole talk (turn it up to 1.5x speed, of course) but at 4:12 he does an amazing job of showing how the SPA path leads to insanity. https://www.youtube.com/watch?v=SWEts0rlezA https://www.youtube.com/watch?v=SWEts0rlezA Here's a mental exercise for you: the next time you start a new project, instead of deciding which SPA framework to use, start with an assumption that an SPA is wild overkill for the first iteration of your application - especially if few people on your team have working expertise with the SPA in question. Then see if you can argue FOR the tech. It's much harder to justify something you don't need if you start with an honest conversation about how you probably don't need it. (This works for throwing out CDs, too: start with the assumption that they are all garbage, they all go. Then force yourself to make logic-based arguments for each one you keep. Your outcome will be night and day from if you start with everything in a keep pile.)

divs1210 8y ago
Sounds like you haven't been introduced to reagent. https://reagent-project.github.io https://reagent-project.github.io
- y4mi 8y ago
  sounds like you didn't actually understand the parents point.
  - hashkb 8y ago
    Or that you need to be introduced to Reagent. Simple doesn't even begin to describe it.

stevebmark 8y ago

Rails is a deeply flawed framework, and we need to stop using Basecamp as the example of a well designed monolith. Basecamp is terrible software, and the crappiness of the user interface appears to be a direct result of not being able to build rich interfaces as its coupled to legacy Rails designs like this article suggests. Basecamp being fast while getting a trickle of traffic and working with very little data is not a selling point against SPAs (I'm not pro or con SPA).

rimliu 8y ago
What are the deep flaws in Rails? What's crappy about Basecamp UI?

Dirak 8y ago

I honestly feel this article is everything that's wrong with web development and this attachment that older developers have for MVC is a ghost that really needs to be addressed once and for all. Seriously. MVC is dead and we need to let it stay dead. SPA architectures are so braindead easy to implement, maintain, and understand that it's ridiculous that developers are still clinging on to their monolithic event driven server-side MVC monstrosities. An SPA architecture is very simple and it does a great job of implementing a strong degree of separation of concerns and maintainability. Essentially, a proper SPA architecture looks like: one backend server that exposes a CRUD REST API (that could call lambda functions here and there when you need to do complex calculations), and then you have your SPA which is hosted on a static file storage service and it's literally just a bundle of html, css, and JS files. Example architecture: EC2 (Backend) <-> S3 (Frontend) <-> Cloudfront It's that simple. Our backend is a feature complete version of our application that we can interface using HTTP methods, which is incredibly powerful because it means we can have multiple clients (native, mobile, web) that all interface the backend instead of coupling the view to the server as we would do using what you suggest in your article. And building an SPA that interfaces a REST API doesn't mean reinventing the wheel. You and other developers who are too stubborn to look past their MVC bubble are just ignorant of the massive amounts of progress over the last ~5 years that the web development community has made in enabling SPA best practices. Just look at Vue-Cli or Create React App. They're incredibly well documented resources and it's incredibly easy to onboard an engineering team onto a SPA project because of how developed the front-end ecosystem is. Everything you would ever want to do has been done before and theres an infinite number of resources to consult when trying to decide what's best practice. The web development community is bar-none the biggest open source community right now and it shows. I've on boarded teams of developers to using SPAs and when they come from a background of MVC they tend to fall in love with the idea of components and encapsulation and philosophies of React and they become agile like you would not believe. Also it's funny you praise the model-2 variant MVC pattern. I just moved a team away from an architecture like that to a SPA one and the difference in productivity from the team was night and day. That architecture was fucking disgusting monstrosity and it should stay in 2008.

GordonS 8y ago
> this attachment that older developers have for MVC is a ghost that really needs to be addressed once and for all. Seriously. MVC is dead and we need to let it stay dead What needs to die is this grounded-in-fantasy contempt for mature, very much alive, performant technologies with huge ecosystems.

fred123 8y ago

I wonder how the argument changes if you know you need an API for your mobile application that's almost identical in features to the web page. If you go the "Rails/Django way" with server side rendered templates and, say, a bit of jQuery for fancy stuff -- you'll end up duplicating lots of code for the API (validation, routing, maybe even business logic). Anyone got experience with swapping your models/controllers for an API while keeping the rest of Django's/Rails' niceties? (authentication/sessions, Django's forms system, CSRF, etc.) OTOH having Django/Rails merely as a template system you probably could also go for very simple, self-contained client-rendered JS pages (e.g. .vue files). Not much difference there I guess?

noxecanexx 8y ago
I think it should still be possible to seperate view from the service at the backend, even if that means defining more routes. I am talking from the hiccup(clj) point of view though

_pdp_ 8y ago

Speaking of code duplication in a traditional web app every page is an example of code duplication. How about that?

PythonicAlpha 8y ago

The main problems addressed in my opinion: - Code duplication between server and client side - Added complication threw data transmission between server and client (REST/json) I think, both problems can be addressed by: - having (a single) code that works both on server and client-side - having transparent transport mechanisms for information between client and server. I am sure, I could implement such a thing for Python/Django, using the already existing tools. But I am not sure, if such a thing would be appreciated by the community. What do you think?

arwhatever 8y ago

Using a framework like the F#-to-JavaScript transpiler Fable, along with an application framework like Elmish, provides a really good solution to some of the pitfalls cited in the article (prescriptive architecture, front + back-end code sharing) and gives you some moderately strong type safety to boot. However, the article author's list of SPA pitfalls is really good, and are probably not all surmountable by a framework/platform.

Bizarro 8y ago

There was probably a few valid points, but the article was too long with too many flimsy, "try-hard to convince" arguments.

randop 8y ago

I feel like seeing more and more post about criticisms for workflow or framework that it is becoming unhealthy with the developer community. There is always short comings on every tool and library, and part of responsibility of a good developer is discerning trade-offs.