7 ms·

I built a rather extensive application for a client over the last 18 months using Rails API and Angular, using a number of these sorts of principles. While it i

I built a rather extensive application for a client over the last 18 months using Rails API and Angular, using a number of these sorts of principles. While it is entirely possible to use what the article suggested, I argue it's a premature optimization and may be a detriment to the entire project. We're now actively removing the Angular portion of the project and going back to the good old way. I wouldn't say this decision was made without careful thought nor without weighing many options. But when it comes down to it, many line of business applications (which is what I see a lot of in the market) don't need the level of sophistication the instructions in this article gives. Most applications need to be reasonably fast, reasonably responsive, and extremely easy to maintain and extend. Does working with all of these modern front end tools that change so quickly and given at least one order of magnitude increase in complexity also give the application a equal increase in speed, responsiveness, maintainability, and extensibility? I don't think so. I'm not the first person to say this. Take a look at this presentation by Sam Stephenson, it will be worth your while: https://www.youtube.com/watch?v=SWEts0rlezA https://www.youtube.com/watch?v=SWEts0rlezA

Scarbutt 9y ago
That presentation makes me want to learn Rails but fortunately there is a shortcut, you can use turbolinks on its own (written in coffescript thought).
- tortilla 9y ago
  I'm using turbolinks with my Phoenix/Elixir stack.
- jordanlev 9y ago
  Or use intercooler, which was inspired by turbolinks but is a completely separate (and non-coffeescript) library: http://intercoolerjs.org/ http://intercoolerjs.org/
jfaucett 9y ago
> Most applications need to be reasonably fast, reasonably responsive, and extremely easy to maintain and extend. Exactly this. I do a lot of freelance rails work and have worked on all kinds of ruby/rails projects. I would say for honestly at least 80% probably around 90% of projects, the "old school boring" rails way is by far the way to go. The whole front end heavy craze is really not the right choice unless you need a very high degree of desktop-like interactivity which again is something most i.e. 80/90% of applications I see in the wild do not require.
- criddell 9y ago
  Do you think RoR is a good choice when all you really want is a service with a REST API? I prototyped something in a couple of days with Python and Flask and it made a good enough impression that we are thinking about fully developing the idea. I'm open to just about any tech and am thinking about continuing with Flask (and Flask-restful), using Go, or Ruby on Rails. I have almost no experience with any of these and that's part of the reason they appeal to me.
  - trcollinson 9y ago
    I’ve built rails api only applications for a long time and I find it to be a great experience. Now, to be fair, I pick it because I know Rails very well. But it’s worth taking a look at for sure.
    - and0 9y ago
      Agreed. My latest project has a Vue front-end (it's a small tool) and Rails does a wonderful job just dumping JSON for the front-end to render. Even if it is a little excessive (which I don't think it is), I have features planned in the future where having an ORM like ActiveRecord+Ruby will make things very simple.
      - bpicolo 9y ago
        I'm using Vue + Rails atm as well. Terrific stack, very productive. I still lean on pure-rails for pages that aren't the main, interactive app.
jessewmc 9y ago
When you say you're going back to 'the good old way', out of curiosity, what do you mean? 'Unobtrusive' JS and ajax here and there, but primarily server rendered templates? Or something else?
- trcollinson 9y ago
  We are going back to server rendered templates yes. We are using erb's for templating, jquery, sass and bootstrap, and Turbo Links. It's old and boring and works like an absolute charm. It's not that we don't use JavaScript, we do quite a bit (we're not into CoffeeScript, it's a personal preference). We are using Action Cable for rendering data through web sockets which is one of many examples of a JavaScript heavy portion of our application. We also have a near native mobile application for Android and iOS. Other than the wrapper for the mobile applications, the application is monolithic. Overall, we've seen a substantial increase in speed, responsiveness, and most importantly our ability to maintain and extend the application.
  - tomca32 9y ago
    It's old and boring and sensible. You need a SPA if you're building something like Google Maps, but most products just don't need it. It introduces so much overhead and so many new problems that just don't exist in a server rendered approach. I applaud this approach and would love to have an opportunity to one day work at a company that values reliable and sensible approach to building software instead of just following the latest fashion. As Mikey Dickerson said; what we need is basic, well-known technology, applied correctly.
polysaturate 9y ago
Turbolinks is plenty fast enough and simple enough for most Rails projects. Maybe sure you're relying on the correct Turbolink events and there's pretty much not anything else you need to change to have Rails automatically load server rendered markup through PJAX.
- hyeomans 9y ago
  Any good tutorials/books/resources on Turbolinks?
sillysaurus3 9y ago
By abandoning React, Vue, and Angular, you're excluding yourself from hiring all the webdevs that need a front-end technology on their resumes in order to get hired elsewhere. That's a pretty large swath. But yes, it's nice that the world is finally realizing Arc was way ahead of its time. HN is snappy because the HTML is small, with few network requests. https://rauchg.com/2014/7-principles-of-rich-web-applications https://rauchg.com/2014/7-principles-of-rich-web-application...
- wwweston 9y ago
  Developers need to be a part of successful projects. Specific tech is less important unless you want/need to go to work for/with people to whom "modern" means fashionable. Which, to be fair, is a larger portion of the industry than most of us care to admit, but then again, React and Vue basics can be learned on side projects. (Angular, less so, though these days I do appreciate it when companies are so kind as to list Angular in their job postings; it's a good heuristic for weeding out based on the probability that there's no one with influence at the organization that thinks about the tools they're using carefully.)
- trcollinson 9y ago
  In my area, it doesn’t much matter whether they actually have experience in Vue/React/Angular, all three and more are on their resume anyway and they can easily talk about the technologies. There’s no doubt I have had applicants pass on us because we don’t use one of those frameworks. But there are plenty of other great web devs who do want to work in a reasonable environment and love it. So it’s balanced out. I’d say my greatest selling point for the job is that we deploy all day long to production. Developers love getting features to users.
- deleted 9y ago
  [deleted]
- moron4hire 9y ago
  Used to be a day you could get hired on a C# job with just Java experience, say nothing about the particular libraries you used within those languages.
krrrh 9y ago
I've been noticing the problem of fancy js-driven front-ends on the open web more lately too. I feel like not a day goes by when I don't use some site that just breaks on a certain browser, or exhibits weird unintended ui behaviour with unresponsive buttons or blank page loads. Blogger is a classic example, but I see a lot of sites from travel to banking that used to be perfectly serviceable and boring become unreliable lately and months later the problems don't get fixed. Usually the source reveals angular.js or something like it. This has got to be costing companies money, but it's hard to say when we'll see a return to simplicity as a virtue.
rubyfan 9y ago
Totally agree with the sentiment. I see engineers put to much time and energy focusing on frameworks and architecture and not enough time on building business value. The joy of Rails is that for the most part you can just focus on getting shit done, focus on building value instead of figure out the right directory structure or which latest framework to use (learn) on your project. I have yet to see a demonstrable benefit from the single page app, front end framework, microservice backend that I didn’t have with a Rails monolith 10 years ago. The majority of what I see these days is unwarranted complexity.
- nurettin 9y ago
  making a game in a browser is a nice use case for react.js, I agree that business apps could do with simpler controls. That said, some responsiveness is unavoidable in business apps, because entering data to lists and grids takes time and if the browser crashes or is inadvertently closed, all that work will be gone.
tarsinge 9y ago
This completely reflects my experience too, as I recently got back to building line of business apps and clients were impressed by the snappiness of basic Rails apps with server rendered templates. Like you said the impact on complexity (and also important on productivity) of going the SPA route for this kind of apps is not justified for me.
quantumofmalice 9y ago
I've built a fairly large, modern web app using rails and intercooler (https://github.com/LeadDyno/intercooler-js https://github.com/LeadDyno/intercooler-js) and I've been very happy with the results: simple, feels modern and easy to extend. The two technologies play very well together and I've been able to add AJAX at the high value points in the app, rather than biting off a huge bit of infrastructure that needs to be maintained everywhere.
- brandonmenc 9y ago
  I also endorse Intercooler. It's perfect for small to medium sized apps that need just a little bit of front-end sprinkling.
- 20years 9y ago
  I have used intercooler too for a couple of apps. It is a joy to work with in comparison to some of the Angular apps I have worked with.
- jrobn 9y ago
  I really like intercooler. I’d rather sprinkle UI goodness instead of jumping neck deep into jS frontend quicksand.
noir_lord 9y ago
I feel exactly the same, I use a hybrid approach, Vue/TS on the client (refactoring a legacy mess) and Symfony components (not the entire framework, legacy project) on the back end but not a full SPA, reusable composable components with a single core VM that orchestrates the page. I get a lot of the benefit of a SPA (client side reactivity/UX/UI) with the benefit of a traditional architecture. The "do it all on the server" vs "do it all on the client" approaches never made sense to me, do the bits that each is best at in the correct place.

Scarbutt 9y ago

That presentation makes me want to learn Rails but fortunately there is a shortcut, you can use turbolinks on its own (written in coffescript thought).

tortilla 9y ago
I'm using turbolinks with my Phoenix/Elixir stack.
jordanlev 9y ago
Or use intercooler, which was inspired by turbolinks but is a completely separate (and non-coffeescript) library: http://intercoolerjs.org/ http://intercoolerjs.org/

jfaucett 9y ago

> Most applications need to be reasonably fast, reasonably responsive, and extremely easy to maintain and extend. Exactly this. I do a lot of freelance rails work and have worked on all kinds of ruby/rails projects. I would say for honestly at least 80% probably around 90% of projects, the "old school boring" rails way is by far the way to go. The whole front end heavy craze is really not the right choice unless you need a very high degree of desktop-like interactivity which again is something most i.e. 80/90% of applications I see in the wild do not require.

criddell 9y ago
Do you think RoR is a good choice when all you really want is a service with a REST API? I prototyped something in a couple of days with Python and Flask and it made a good enough impression that we are thinking about fully developing the idea. I'm open to just about any tech and am thinking about continuing with Flask (and Flask-restful), using Go, or Ruby on Rails. I have almost no experience with any of these and that's part of the reason they appeal to me.
- trcollinson 9y ago
  I’ve built rails api only applications for a long time and I find it to be a great experience. Now, to be fair, I pick it because I know Rails very well. But it’s worth taking a look at for sure.
  - and0 9y ago
    Agreed. My latest project has a Vue front-end (it's a small tool) and Rails does a wonderful job just dumping JSON for the front-end to render. Even if it is a little excessive (which I don't think it is), I have features planned in the future where having an ORM like ActiveRecord+Ruby will make things very simple.
    - bpicolo 9y ago
      I'm using Vue + Rails atm as well. Terrific stack, very productive. I still lean on pure-rails for pages that aren't the main, interactive app.

jessewmc 9y ago

When you say you're going back to 'the good old way', out of curiosity, what do you mean? 'Unobtrusive' JS and ajax here and there, but primarily server rendered templates? Or something else?

trcollinson 9y ago
We are going back to server rendered templates yes. We are using erb's for templating, jquery, sass and bootstrap, and Turbo Links. It's old and boring and works like an absolute charm. It's not that we don't use JavaScript, we do quite a bit (we're not into CoffeeScript, it's a personal preference). We are using Action Cable for rendering data through web sockets which is one of many examples of a JavaScript heavy portion of our application. We also have a near native mobile application for Android and iOS. Other than the wrapper for the mobile applications, the application is monolithic. Overall, we've seen a substantial increase in speed, responsiveness, and most importantly our ability to maintain and extend the application.
- tomca32 9y ago
  It's old and boring and sensible. You need a SPA if you're building something like Google Maps, but most products just don't need it. It introduces so much overhead and so many new problems that just don't exist in a server rendered approach. I applaud this approach and would love to have an opportunity to one day work at a company that values reliable and sensible approach to building software instead of just following the latest fashion. As Mikey Dickerson said; what we need is basic, well-known technology, applied correctly.

polysaturate 9y ago

Turbolinks is plenty fast enough and simple enough for most Rails projects. Maybe sure you're relying on the correct Turbolink events and there's pretty much not anything else you need to change to have Rails automatically load server rendered markup through PJAX.

hyeomans 9y ago
Any good tutorials/books/resources on Turbolinks?

sillysaurus3 9y ago

By abandoning React, Vue, and Angular, you're excluding yourself from hiring all the webdevs that need a front-end technology on their resumes in order to get hired elsewhere. That's a pretty large swath. But yes, it's nice that the world is finally realizing Arc was way ahead of its time. HN is snappy because the HTML is small, with few network requests. https://rauchg.com/2014/7-principles-of-rich-web-applications https://rauchg.com/2014/7-principles-of-rich-web-application...

wwweston 9y ago
Developers need to be a part of successful projects. Specific tech is less important unless you want/need to go to work for/with people to whom "modern" means fashionable. Which, to be fair, is a larger portion of the industry than most of us care to admit, but then again, React and Vue basics can be learned on side projects. (Angular, less so, though these days I do appreciate it when companies are so kind as to list Angular in their job postings; it's a good heuristic for weeding out based on the probability that there's no one with influence at the organization that thinks about the tools they're using carefully.)
trcollinson 9y ago
In my area, it doesn’t much matter whether they actually have experience in Vue/React/Angular, all three and more are on their resume anyway and they can easily talk about the technologies. There’s no doubt I have had applicants pass on us because we don’t use one of those frameworks. But there are plenty of other great web devs who do want to work in a reasonable environment and love it. So it’s balanced out. I’d say my greatest selling point for the job is that we deploy all day long to production. Developers love getting features to users.
deleted 9y ago
[deleted]
moron4hire 9y ago
Used to be a day you could get hired on a C# job with just Java experience, say nothing about the particular libraries you used within those languages.

krrrh 9y ago

I've been noticing the problem of fancy js-driven front-ends on the open web more lately too. I feel like not a day goes by when I don't use some site that just breaks on a certain browser, or exhibits weird unintended ui behaviour with unresponsive buttons or blank page loads. Blogger is a classic example, but I see a lot of sites from travel to banking that used to be perfectly serviceable and boring become unreliable lately and months later the problems don't get fixed. Usually the source reveals angular.js or something like it. This has got to be costing companies money, but it's hard to say when we'll see a return to simplicity as a virtue.

rubyfan 9y ago

Totally agree with the sentiment. I see engineers put to much time and energy focusing on frameworks and architecture and not enough time on building business value. The joy of Rails is that for the most part you can just focus on getting shit done, focus on building value instead of figure out the right directory structure or which latest framework to use (learn) on your project. I have yet to see a demonstrable benefit from the single page app, front end framework, microservice backend that I didn’t have with a Rails monolith 10 years ago. The majority of what I see these days is unwarranted complexity.

nurettin 9y ago
making a game in a browser is a nice use case for react.js, I agree that business apps could do with simpler controls. That said, some responsiveness is unavoidable in business apps, because entering data to lists and grids takes time and if the browser crashes or is inadvertently closed, all that work will be gone.

tarsinge 9y ago

This completely reflects my experience too, as I recently got back to building line of business apps and clients were impressed by the snappiness of basic Rails apps with server rendered templates. Like you said the impact on complexity (and also important on productivity) of going the SPA route for this kind of apps is not justified for me.

quantumofmalice 9y ago

I've built a fairly large, modern web app using rails and intercooler (https://github.com/LeadDyno/intercooler-js https://github.com/LeadDyno/intercooler-js) and I've been very happy with the results: simple, feels modern and easy to extend. The two technologies play very well together and I've been able to add AJAX at the high value points in the app, rather than biting off a huge bit of infrastructure that needs to be maintained everywhere.

brandonmenc 9y ago
I also endorse Intercooler. It's perfect for small to medium sized apps that need just a little bit of front-end sprinkling.
20years 9y ago
I have used intercooler too for a couple of apps. It is a joy to work with in comparison to some of the Angular apps I have worked with.
jrobn 9y ago
I really like intercooler. I’d rather sprinkle UI goodness instead of jumping neck deep into jS frontend quicksand.

noir_lord 9y ago

I feel exactly the same, I use a hybrid approach, Vue/TS on the client (refactoring a legacy mess) and Symfony components (not the entire framework, legacy project) on the back end but not a full SPA, reusable composable components with a single core VM that orchestrates the page. I get a lot of the benefit of a SPA (client side reactivity/UX/UI) with the benefit of a traditional architecture. The "do it all on the server" vs "do it all on the client" approaches never made sense to me, do the bits that each is best at in the correct place.