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

121–130 of 137 posts

Re: Escaping the SPA rabbit hole with modern Rails

#121

Post by _Tev »

GordonS wrote: post #87
emodendroket wrote: post #69

Earlier quoted context omitted.

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.

It's 1 line with jQuery, so I guess "significantly more" is relative?

Every spaghetti ball starts with these one liners. Using just one line implies no structure or separation of concerns (needed for anything complex), which is why nobody is talking about this case, and immediately jumping to theoretical "SPA-like functionality, but implemented in jQuery".

EDIT: as for your original question ("significant amount of FE functionality"), from my experience jQuery loses a lot of its appeal when you have over 1k lines of JS, and I guess over 5k JS frameworks (React, Ng, Ember, Vue) start to be significantly better. When over 10k jQuery would be crazy mess (I have seen one such project, it was fun trainwreck).

Re: Escaping the SPA rabbit hole with modern Rails

#122

Post by divs1210 »

peteforde wrote: post #119
divs1210 wrote: post #61

Earlier quoted context omitted.

Sounds like you haven't been introduced to reagent. https://reagent-project.github.io

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.

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.

Re: Escaping the SPA rabbit hole with modern Rails

#123

Post by peteforde »

divs1210 wrote: post #122
peteforde wrote: post #119

Earlier quoted context omitted.

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.

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.

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.

Re: Escaping the SPA rabbit hole with modern Rails

#124

Post by divs1210 »

peteforde wrote: post #123
divs1210 wrote: post #122

Earlier quoted context omitted.

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.

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

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.

Re: Escaping the SPA rabbit hole with modern Rails

#125

Post by emodendroket »

cm2187 wrote: post #62
peteforde wrote: post #52

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.

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

Re: Escaping the SPA rabbit hole with modern Rails

#126

Post by emodendroket »

GordonS wrote: post #86
peteforde wrote: post #52

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…

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

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

Re: Escaping the SPA rabbit hole with modern Rails

#127

Post by wjossey »

andrei_says_ wrote: post #95
wjossey wrote: post #31

Earlier quoted context omitted.

Good point, and this is exactly what I did. I actually was running the SPA + the rails app side by side. Took me about 6 months, but I cut over every page / app one by one till I was done. And, to the parent commenter, good point. I do think the gist of the author is to use the right tool for the job, and they are not dogmatic about "never write an SPA". Thanks for keeping me honest.

I’m curious, what was the change in the UI which required the move away from Rails? What are you accomplishing with Vue which was impossible before? Would love to get a glimpse of the app.

Our core product offering is a fully white glove 360 review process for small to medium business (mostly startups between 10 and 300 employees).

The objective of our process is to deliver highly actionable feedback for each and every participant, so the “review” you fill out for yourself, your manager, and your peers, feels different than a normal form based review. We ask a series of questions, adjust what we ask on the fly, and try to help encourage writing high quality feedback along the way.

We do a part of this process during a workshop we run on site, and that tends to mean a bunch of people packed on a single WiFi node. Having the app as an SPA allows the user to fill out their 360s, even on a dreadfully slow network, and not notice. This could have been achieved with jQuery, but given how complex I know this code is under the hood, I shiver at the thought.

To the questioner, my email is in my profile. Shoot me an email and I’ll point you towards our demo.

Re: Escaping the SPA rabbit hole with modern Rails

#128

Post by emodendroket »

acdha wrote: post #116
tshaddox wrote: post #105

Earlier quoted context omitted.

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.

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.

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.

Re: Escaping the SPA rabbit hole with modern Rails

#129

Post by andrei_says_ »

_Tev wrote: post #120
andrei_says_ wrote: post #100

Earlier quoted context omitted.

I’ve used both Vue and Rails. Rails partials does meet my needs for compartmentalizing code. Don’t really see what benefit would I get for adding the complexity of separating the front end in its own layer. Turbolinks gives me the speed of an SPA and I get 5x the dev productivity by not adding one. And I absolutely love Vue. What am I missing?

I think both sides are doing something different. If you want to prototype / start new project with complex UI (think filterable lists / tables, communication apps, dashboards, ...), you are building the app around the client and SPA is natural choice If your app is more like (simple) CRUD app, then you probably don't need SPA features, and they might even slow you down. There is no clear line between those two, so l…

This makes sense, for the few views which contain the complex UI. What I’m having a hard time with is the suggestion to replace all views. I don’t see the benefit in that.

Re: Escaping the SPA rabbit hole with modern Rails

#130

Post by andrei_says_ »

wjossey wrote: post #113
brandonmenc wrote: post #104

Earlier quoted context omitted.

> That might not be enough for you when you're working with mostly vanilla CRUD pages > I'd say even for trivial pages it's a net positive Curious, what do you consider more complicated than CRUD, yet simultaneously "trivial"?

Poor choice of words on my part. For me, using Vue is worth for CRUD pages, trivial pages (pure HTML), etc. There's enough it gives me that even though I don't need it, I enjoy utilizing it in my workflow. What I was attempting to express is that I understand that for many, it doesn't give them anything in a basic CRUD page, and in fact can add a lot of complexity when you move away from built-ins with the backend fr…

Reading this, I am windering if the way I am approaching Vue is more complex than the way others do.

Could you outline your approach to including Vue, to carrying state and changes from the rails api to the Vue-powered views, incl. initial state?

Do you think you could share a code sample?

Post reply on HN