HN Theater @HNTheaterMonth

They could simply solve this with a PWA, no?

They already have a web client which is all server rendered with Rails and uses Turbolinks. If I'm not mistaken they also use this approach for the Basecamp iOS app [1].

[1] https://www.youtube.com/watch?v=SWEts0rlezA

⬐ paulgb

iOS remains a holdout on the Push Notifications API, which is pretty important for an email app.

https://caniuse.com/#feat=push-api

⬐ pier25

Ah yes that's why. Thanks for pointing it out.

⬐ wayneftw

I was wondering... Can there be a native app on iOS that sets up notifications for all participating PWAs and then when a notification comes in, when the user views it - the native app simply launches the URL of the PWA?

It could be called "Web Events Notifier" or something. Perhaps it could include a UI for managing which PWAs you want to receive notifications for and maybe even a catalog of publicly participating PWAs.

⬐ Joeri

Any feed reader can be set up like this. Publish the notifications to an rss feed on a unique url, with each entry containing a link back to the pwa, have the feed reader app subscribe to it and use the notifications of the feed reader app.

It is somewhat cumbersome though.

⬐ claytongulick

This is a really good idea. Maybe even a business model.

⬐ perryizgr8

That would work great until Apple rejects it. You cannot get around Apple's intentions with technical loopholes.

⬐ wayneftw

Yeah I'm just wondering - on what grounds would they reject it?

I don't see any TOS that would forbid it.

⬐ crispyporkbites

Technically yes, it’s a great idea- but Apple will just block it at some point. Or at least the threat of it being blocked is enough to make it a non starter.

⬐ jdxcode

it wasn't clear to me trying to skim the video, but is this the strategy where you add an app from safari to the home screen? That was always clunky and I don't think you can get notifications that way

⬐ pier25

The video is about turbolinks, which basically makes a request with JS to the server and then replaces the HTML in the body of the page. This results in a performance increase. Turbolinks is heavily used in Rails sites like Github for example.

It also showcases a Turbolinks version for iOS which works differently as it connects with the native app for changing views etc.

The guy in the video still works at Basecamp and worked on HEY too so I assume they used Turbolinks for iOS.

⬐ jdxcode

I think I'm missing something. It's still in the App Store, right? Seems to me that they'd still happily reject it even if the rendering is done server-side.

⬐ pier25

My initial point was that since they are already using web technology they could probably move it to a web app for mobile outside the AppStore.

But, as paulgb pointed out in another comment, Safari for iOS hasn't implemented push notifications from web apps which is probably a deal breaker for most users of an email app.

⬐ lukifer

Apple has not exactly been friendly to PWA architecture, and their incentives against improving that feature-set are pretty obvious. While web sites/apps can be saved to the home screen, have some data persisted [0], etc, iOS PWA capabilities aren't comparable to Android. And of course, there are all the standard objections to web apps / hybrid apps, re: performance, design language, etc.

[0] Although local storage is actually now considered volatile in iOS: https://www.itnews.com.au/news/apple-cops-flak-for-deleting-...

If you are a Rails developer, this Turbolinks presentation makes a strong case to be used for mobile apps. https://m.youtube.com/watch?v=SWEts0rlezA

It seems like there is a strong productivity gain from using rails here since it’s extremely productive and you can make simple wrapper apps to release to the Play and App Store that really just wrap the web view.

The biggest gain is obviously reusing most of the web app across three different platforms, and the ability to add native navigation and interaction as needed, later. You also avoid needing a big javascript library.

⬐ yeskia

I’ve looked at this before, but it seems to require you use remote forms. And when you use remote forms there’s no out of the box solution for displaying errors. Am I missing something here? Were you able to successfully build a Turbolinks app off a Rails app?

That's brilliant! Have you had the opportunity to play with Turbolinks 5? It sounds like there will be some crossover with what you have already done, but if you're intellectually curious, you might pick up some good tricks, too.

https://github.com/turbolinks/turbolinks

https://www.youtube.com/watch?v=SWEts0rlezA&t=3m22s

TL5 just happens to pair beautifully with a tiny library called Stimulus, which would be YAF except that it's a) by the same team as TL5 and b) that team is also behind Rails, so there's some claim to legitimate best practices.

https://stimulusjs.org/

⬐ keanebean86

This is awesome! Thanks!

I keep looking at C# and Blazor myself

If you want an SPA type Rails way of doing things, you can use Turbolinks. This talk at RailsConf 2016 is really an eye opener.

https://www.youtube.com/watch?v=SWEts0rlezA

I urge/beg you to check out the Turbolinks 5 + StimulusJS libraries, which are by the same (Rails team) people, which is no coincidence.

https://youtu.be/SWEts0rlezA?t=203

⬐ frou_dh

There's a great podcast interview about the what/why of Stimulus: https://changelog.com/podcast/286

Okay, I have lots of good news for you.

First, CoffeeScript is formally deprecated. Turbolinks sucked, but Turbolinks 5 is an entirely new beast and it rocks. You need to give it a second look. I recommend this talk, sped up to 1.5x:

https://www.youtube.com/watch?v=SWEts0rlezA&t=3m22s

Finally, there absolutely is an opinionated client library that is designed to pair beautifully with Turbolinks 5. It's called Stimulus and it rocks.

https://stimulusjs.org/

You can play with all of these frameworks using the --webpack parameter:

rails new future --skip-sprockets --skip-coffee --webpack=stimulus --database=postgresql --skip-test

As a bonus for anyone starting a new Rails project today, you're going to want to bookmark https://gist.github.com/andyyou/834e82f5723fec9d2dc021fb7b81...

Let me know if you have any questions.

⬐ revskill

Thanks, it's an almost complete guide. But there's one important missing piece: Universal routing. How about taking the routing config which can be applied for both server and client ?

⬐ peteforde

If you're talking about React-style routing via navigation or whatever, then yeah, you need to evaluate what's best for you.

One reason I love Stimulus + Turbolinks 5 is that you don't have to think in terms of client-side routing.

I'm a rails dev too, last year I was making a mobile web app where I was concerned about frontend, so I started making a SPA in mithril.js and using Rails as the API.

Later I abandoned the SPA and went back to rails views, using turbolinks to make it fast. In reality rails + turbolinks is fast enough for most cases, and then I can sprinkle in extra javascript or use SPA on one or two pages as needed.

The reason I think it's almost better to avoid SPA + API approach is to keep the codebase simple and easier for one person to maintain.

https://www.youtube.com/watch?v=SWEts0rlezA http://masilotti.com/beermenus-and-turbolinks/

I urgently encourage you and anyone else reading this to check out Turbolinks 5, ideally in tandem with Stimulus.

https://www.youtube.com/watch?v=SWEts0rlezA&t=3m22s

https://github.com/turbolinks/turbolinks

https://stimulusjs.org/

You can get all of the benefits of server-generated pages with the speed of an SPA. 90%+ of the sites built using SPAs would be better served by Turbolinks and Stimulus.

⬐ pklee

Just looked at stimulus. Really cool framework. circa 2008 or so there was this concept of non-intrusive javascript where you bind js to elements. So you could wysiwyg html and then inject js where you need it. Thought that was a neat idea and like what stimulus does it. Any real life experience from anyone ?

⬐ TomK32

Yes, I'm using it in the budgeting webapp that I develop and here's one little component that I shared, a calculator for input boxes https://tomk32.de/2018/08/04/stimulus-component-calculator.h...

Really should add a gif or something.

⬐ pklee

pretty cool.. thanks for sharing... I could not work on the app itself, but that is ok.

⬐ peteforde

Just for context, Stimulus is written by the same people who make Rails, Turbolinks etc - Basecamp. In fact, primary author Sam Stephenson was the author of Prototype, which was the library that inspired the creation of jQuery.

Stimulus and Turbolinks 5 don't have to be used together, but when they are it's a beautiful thing. That's because Stimulus uses the MutationObserver API to observe for DOM changes (eg. loading a new view in response to a click). It is the nicest event handling concept I've ever worked with.

⬐ kevintb

I've never heard of either before, and they've really caught my attention. Thanks for bringing this up.

⬐ peteforde

Let me know if you need any help getting up and running. I'm not involved but I'm a big fan.

For what it's worth, if you are impressed by the reasoning and design-thinking that created these libraries, I encourage you to try Rails sometime as well. I still consider it the best way to build a web application for 90% of use cases. I'm happy to answer any questions you might have.

https://www.quora.com/Why-do-so-many-startups-use-Ruby-on-Ra...

⬐ mcintyre1994

This all looks really nice - any idea if there's anything comparable that works with Django?

⬐ collinmanderson

Turbolinks has out-of-the-box support for Rails, but should theoretically work with any backend without much work. Just install via npm.

⬐ peteforde

Stimulus will work with any (or no) backend.

Turbolinks will work great with Django, but I recommend configuring your stack to automate the inclusion of the Turbolinks-Location header in your responses.

I just did a quick Google and this came up: https://stackoverflow.com/questions/47240766/to-use-turbolin...

Let us know how you make out!

⬐ snazz

I’ve never used Stimulus, but I can concur that Turbolinks is magic, at least for the simpler Rails app I made. It took load times from over one second to feeling like a native app, didn’t require any changes on the backend (it’s enabled by default in Rails), and the site works just fine without it, for those of us who like blocking third-party JavaScript.

I found this video and talk to be very enlightening. I know it's not the neatest, most exciting framework, but Rails with Turbolinks sure can do the trick. My last two mobile applications were built in the same way that Sam Stephenson describes here.

https://www.youtube.com/watch?v=SWEts0rlezA

Rails Turbolinks utilizes this technique for iOS: https://github.com/turbolinks/turbolinks-ios

Video explanation/demonstration: https://youtu.be/SWEts0rlezA

You achieve the same thing with Rails and Turbolinks. Watch this presentation by Sam Stephenson to see what I mean.

https://www.youtube.com/watch?v=SWEts0rlezA

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

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.)

⬐ GordonS

At my day job, I mainly build web apps for enterprise customers, and for maybe 90% of them we use ASP. NET MVC or ASP.NET Core MVC, with a smattering of jQuery and vanilla JavaScript on the client side. This is a tried and tested stack that works well, has a huge ecosystem, and has great development and debugging stories.

There seems to be an awful lot of devs now that only know and use JavaScript, consider server-side technologies to be 'old skool', and prefer to use whichever SPA library is the new hotness - but IMO, most web apps just don't have UIs that are complex enough to warrant using a SPA.

⬐ emodendroket

.NET is just as well suited for SPAs as any other technology.

⬐ mercer

I generally agree with you, and as a front-ender-first that feels kind of uncomfortable to say. In my personal projects I do often go for a more conservative server-side first approach.

That said, it really feels like a chasm that quite often I choose to cross simply because it'll be easier down the line. I've been bitten more than once by server-side-first projects where going full-on client-side with the server-side as an API would've probably been better.

Whether it was because I needed a mobile app to communicate with said API, or whether the complexity ended up being more of a client-side thing, the result was often that I had to focus on the back-end as as API and go for the full complexity of a front-end app anyways.

I'm enough of a fan of my preferred back-end languages (Ruby, but mostly Elixir these days) that I try to find ways to keep the complexity there, but truthfully I often opt for going for the full complexity of a client-side JS/TS stack because I'm likely to end up needing it eventually anyways.

I've looked into things like Drab (https://github.com/grych/drab), but ultimately there are many reasons why 'going with the flow' seems like the better solution (even if just because it's so much easier to find JS devs than Elixir ones).

So far I'm not confident enough to make any sweeping statements, but from that lack of confidence I tend to opt for the 'safer' option, which seems to be the SPA route much of the time.

⬐ noxecanexx

+1 for the last paragraph. I used that technique to quell my desire to use event sourcing everywhere

⬐ pier25

Thanks for sharing the video. It's really good.

⬐ divs1210

Sounds like you haven't been introduced to reagent.

https://reagent-project.github.io

⬐ y4mi

sounds like you didn't actually understand the parents point.

⬐ hashkb

Or that you need to be introduced to Reagent. Simple doesn't even begin to describe it.

⬐ peteforde

I'll give it a shot if there's a stable build of the Reagent<->BrainFuck transpiler working.

⬐ peteforde

Okay, I admit it: I honestly can't tell if you're joking or not.

I think that you're joking, but if you're not joking, well, we have different definitions of simple.

⬐ divs1210

I'm not joking. Spend some effort. Challenge me. You build a UI in your favorite framework. I'll use reagent. Document the code. Compare the code then.

⬐ peteforde

Dude, I've got work to do.

You threw down a URL to a framework I don't know that is apparently similar to a framework I don't use and runs on Clojure, which I don't work in and none of my codebases run in. You did that with no context or even taking the time to explain why I would do such a thing.

Objectively, there's nothing simple or expressive about the samples on their homepage. Their demos are simplistic (todo?! seriously?) and do nothing to convey why someone would express a complex web app in this manner.

It seriously looks like Matrix code to me.

⬐ divs1210

So just because you don't know German and I ask you to read some German text, you will say this looks super complex, even if it's a simple line saying "Good day!".

Wow! Indeed our definitions of simple are different.

⬐ peteforde

If you want to spend your days learning flavor of the minute web frameworks instead of actually building stuff, knock yourself out.

If you have anything more substantial to add to the conversation that actually relates to my original comment, I'll be here.

⬐ divs1210

Well, I've built stuff in reagent, enjoyed it immensely, and been paid for it. Enjoy your jquery! (and your ignorance!)

⬐ cm2187

As a user my main beef against SPA is that most of the time they break basic browser functionalities, like the ability to open links in a new tab, or using the back button. When the UI doesn’t simply break with part of the content off-screen.

⬐ emodendroket

That's exactly the reason to use a SPA framework where all these problems are solved for you.

⬐ thesephist

Having built some SPA's, I'd argue that at least those two things that you mentioned are the fault of whoever built bad SPA's, rather than issues with SPA's as a whole. It's possible to build an SPA that works well with the browser controls because modern browsers expose a lot of their functionality to JavaScript (like it or not). You can use <a> tags for buttons and links in an SPA (and keep the link functionality) -- you can just intercept the clicks when the link is being opened in the current tab, and you can always hook onto pushState/popState to make the back/forward button work.

⬐ temporaryacc62

Would you say Youtube works better now as it is fully SPA?

⬐ Rjevski

It does not. The SPA is so sluggish I’ve learned to just force a page refresh after clicking on anything because a full page load is actually faster than their bullshit SPA.

⬐ fny

There's an army working on YouTube, and it has the traffic levels to justify the investment. They can actually put in the required effort to ensure the application functions seamlessly and meets accessability standards.

⬐ acdha

It is an issue with SPAs as a concept because part of that concept is that you’re taking on responsibility for things the browser traditionally did for you.

That’s not a bad thing but it’s extra work which someone has to be responsible for, similar to how e.g. using a complex custom widget means you’re on the hook for accessibility rather than the browser vendors.

⬐ baddox

Surely most creators of SPAs are using some routing library, and I’m not aware of any routing libraries that don’t handle this anchor tag click behavior by default. It’s really a trivial amount of “responsibility” to take on.

⬐ acdha

Perhaps, but it’s something I encounter fairly regularly, especially when an unreliable network connection or other JavaScript failure breaks something with poor error handling. Again, not a showstopper but it’s a decision point: if you aren’t committed to testing this kind of thing on every release, you don’t have the resources to build an SPA.

⬐ emodendroket

It's no different than stuff like not trusting browser input or avoiding a massive session when you're working on a Web app: it's simply basic best practice stuff that you don't even have to think about if you have an idea what you're doing.

Exactly what Sam Stephenson talked about here: https://youtu.be/SWEts0rlezA?t=6m36s

there was a talk at RailsConf 2016 by Sam Stephenson about how Basecamp used Turbolinks to create version 3 of their, an android and ios version in 18 months.

https://www.youtube.com/watch?v=SWEts0rlezA

Managing complex DOM transformations and avoiding pageloads on every change do carry benefits.

Some examples: chat, Facebook-like functionality, complex custom interfaces.

There is however a strong tendency to build complex front-end apps because of the trend to do so. This increased complexity results in higher costs without significant benefits (I’m very open to changing my mind).

Turbolinks for example is a fantastic backend-agnostic library which eliminates the pageloads in CRUD apps at close to zero development costs and makes the speed almost indistinguishable from SPA implementations.

I highly recommend this talk on managing the complexity of basecamp and sharing a codebase between web and native apps.

https://m.youtube.com/watch?v=SWEts0rlezA

Unless you’re building extremely complex interfaces and if you are able to correct for trendiness you may conclude that a monolithic app with possibly Turbolinks and some front end sugar is the best choice.

You can always offload some work to the client once you get to a billion users and servers become too expensive. Until then maybe focus on launching.

https://www.youtube.com/watch?v=SWEts0rlezA

if you haven't seen Sam Stephenson Turbolink talk from RailsConf 2016, you should give it a watch. What they did in a year with a small team is amazing.

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

⬐ quantumofmalice

I've built a fairly large, modern web app using rails and intercooler (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

I also endorse Intercooler.

It's perfect for small to medium sized apps that need just a little bit of front-end sprinkling.

⬐ 20years

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

I really like intercooler. I’d rather sprinkle UI goodness instead of jumping neck deep into jS frontend quicksand.

⬐ rubyfan

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

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.

⬐ krrrh

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.

⬐ jessewmc

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

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

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.

⬐ noir_lord

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.

⬐ tarsinge

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.

⬐ polysaturate

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

Any good tutorials/books/resources on Turbolinks?

⬐ Scarbutt

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

I'm using turbolinks with my Phoenix/Elixir stack.

⬐ jordanlev

Or use intercooler, which was inspired by turbolinks but is a completely separate (and non-coffeescript) library: http://intercoolerjs.org/

⬐ sillysaurus3

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-application...

⬐ trcollinson

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.

⬐ None

None

⬐ moron4hire

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.

⬐ wwweston

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.)

⬐ jfaucett

> 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

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

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

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

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.

⬐ pdkl95

One note about RoR: it's very opinionated about using convention over configuration. It's very efficient if you generally work with it's convention. However, if you design and/or goals are regularly in conflict with those conventions, RoR might not be the best tool to use for that project.

⬐ stevenwoo

I'm just learning Flask myself - are you using a database for storage? That's my next step. I've done full apps with RoR and this would not be a question at all with RoR, it's already built in, just toying with Python/Flask to learn stuff.

⬐ criddell

For the prototype, I just put my data into some json files. Connecting to some kind of database would be my next step if I continue on with it. Probably would use SQLAlchemy.

I'm a bit of a REST newbie and so some concepts (esp HATEOAS) are still a bit blurry. I would probably take a little time to dig into just what goes into a well-structured REST service.

⬐ mctx

Check out Django Rest Framework - it uses Django’s ORM and adds some really nice features for building a decent sized API

⬐ jfaucett

> Do you think RoR is a good choice when all you really want is a service with a REST API?

I'm going to be honest with you. I love building pure REST apis in rails. The experience is so clean and effortless.

That being said there is at least one caveat to using RoR for the first time, and thats that the learning curve is probably going to be a little steeper than a rest lib like flask where things are more explicit, since there is a lot of convention over configuration in RoR. Once you learn the conventions, the development speed is ridiculously fast, but until then things can be pretty opaque and take some time to get used to, especially for people who don't understand well how the ruby runtime works. I've witnessed this on multiple occasions with multiple projects, if there are more advanced/not-stack-overflowable things that need to be done, devs who are working in RoR and ruby for the first time, will run into a lot of roadblocks. This has little if anything to do with their particular skills as a programmer and more to do with the dynamic nature of ruby and a lot of very tricky hacks rails does under the surface to make the end-user api clean and succinct.