Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Escaping the SPA rabbit hole with modern Rails

medium.com

Post reply on HN
Print view View original

11–20 of 137 posts

Re: Escaping the SPA rabbit hole with modern Rails

#11

Post by zdragnar »

FreakyT wrote: post #9
ransom1538 wrote: post #7

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

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.

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.

Re: Escaping the SPA rabbit hole with modern Rails

#12

Post by zdragnar »

Mc_Big_G wrote: post #8

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 .NE…

"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"

Re: Escaping the SPA rabbit hole with modern Rails

#14

Post by schizoidboy »

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

Re: Escaping the SPA rabbit hole with modern Rails

#15

Post by lucidone »

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.

Re: Escaping the SPA rabbit hole with modern Rails

#16

Post by cmjqol »

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.

Re: Escaping the SPA rabbit hole with modern Rails

#17

Post by codingdave »

schizoidboy wrote: post #14

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

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.

Re: Escaping the SPA rabbit hole with modern Rails

#18

Post by sho »

cmjqol wrote: 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…

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.

Re: Escaping the SPA rabbit hole with modern Rails

#19

Post by korm »

Mc_Big_G wrote: post #8

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 .NE…

I think if the conversion is led by a very experienced React developer this could be a good decision. We decided to write all our sites in React a long time ago and couldn't be happier. It doesn't have to be a SPA because it's React, we have static sites too.

Judging by how your org made the decision without the devs input though, I'm not too confident it won't be disaster. It's depressing but I've been offered too many contracting opportunities to rescue a project after a similar conversion that is a total dumpster fire.

Re: Escaping the SPA rabbit hole with modern Rails

#20

Post by woah »

schizoidboy wrote: post #14

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

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