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…
Escaping the SPA rabbit hole with modern Rails
61–70 of 137 posts
Re: Escaping the SPA rabbit hole with modern Rails
#62I 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…
Re: Escaping the SPA rabbit hole with modern Rails
#63An 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
#64If 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
#65Earlier 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.
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
#66Rails 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…
Re: Escaping the SPA rabbit hole with modern Rails
#67Like 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
#68Earlier 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.
Re: Escaping the SPA rabbit hole with modern Rails
#69Earlier 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 ?
Re: Escaping the SPA rabbit hole with modern Rails
#70I 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.