Live data from Hacker News

Escaping the SPA rabbit hole with modern Rails

medium.com

61–70 of 137 posts

Re: Escaping the SPA rabbit hole with modern Rails

#61

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 jQuer…

Sounds like you haven't been introduced to reagent.

https://reagent-project.github.io

Re: Escaping the SPA rabbit hole with modern Rails

#62

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 jQuer…

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.

Re: Escaping the SPA rabbit hole with modern Rails

#63
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.

Re: Escaping the SPA rabbit hole with modern Rails

#64
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?

Re: Escaping the SPA rabbit hole with modern Rails

#65
post #53
post #51

Earlier quoted context omitted.

I totally agree, but I thought it was funny that you invoked the concept of local minima - I have only ever heard that concept in terms of local maxima , ie locally-but-perhaps-not-globally maximal productivity, comfort zone, etc. I assume you are referring to a locally/globally minimal resistance, time taken, or some such? Anyway I just thought it interesting that you might make valid reference to a very useful conc…

Local minima come from optimization problems as you encounter for example in Machine Learning. You usually want to minimize some error function (e.g. misclassified objects). Unless you take great care these functions are riddled with local minima where naive optimization gets stuck.

Ah I see - of course. Should have thought of that.

For comparison, I believe my usage arises from evolutionary fitness, where one might discuss local maxima on a fitness landscape. The challenge is perhaps much the same as in ML, with one strategy being to introduce random mutations in order to escape the same kind of trap.

Re: Escaping the SPA rabbit hole with modern Rails

#66

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 n…

What are the deep flaws in Rails? What's crappy about Basecamp UI?

Re: Escaping the SPA rabbit hole with modern Rails

#67
post #16

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 l…

   > JS is a fast evolving 
Alas, it is more revolving, than evolving :(

Re: Escaping the SPA rabbit hole with modern Rails

#68
post #50

Earlier quoted context omitted.

If you use Rails until you can't and then start making a SPA you'll have the common pattern of an application where you never have any idea whether any given thing is built in the Rails templates or in the JS or in some combination of the two.

Is that really a common problem? Can't say I've ever had much trouble remembering what's doing what. If it really was an issue you could just tell one of the environments to throw a banner up the top of the screen or something in dev mode saying where it's from.

It's a pretty common problem for old legacy apps to have. I don't get the banner thing. Often the same page has functionality interleaved from both sources

Re: Escaping the SPA rabbit hole with modern Rails

#69

Earlier quoted context omitted.

I think that quickly becomes untrue if you have any significant amount of front-end functionality.

Can you expand on significant amount of front-end functionality ?

Writing jQuery to accomplish a feature like hiding one element if another is checked is significantly more code and more error-prone (not to mention difficult to test) than doing the equivalent thing with a tool like Angular is.

Re: Escaping the SPA rabbit hole with modern Rails

#70
post #62

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 jQuer…

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.

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 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.
Post reply on HN