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

111–120 of 137 posts

Re: Escaping the SPA rabbit hole with modern Rails

#111

Post by noxecanexx »

zmmmmm wrote: post #30

I have to admit, I do not know Turbolinks well, but I feel like the author misses something fundamental about the benefits of modern frameworks. It's not just about building a giant SPA - component-based design is a huge value proposition. The problem I see at the moment is that client side "apps" - however they are rendered - hit a wall in complexity that is really hard to overcome without a a sane and sensible way…

You can do the same with server rendered apps. I don't think reacted and co invented components

Re: Escaping the SPA rabbit hole with modern Rails

#112

Post by noxecanexx »

fred123 wrote: post #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 fo…

I think it should still be possible to seperate view from the service at the backend, even if that means defining more routes. I am talking from the hiccup(clj) point of view though

Re: Escaping the SPA rabbit hole with modern Rails

#113

Post by wjossey »

brandonmenc wrote: post #104
wjossey wrote: post #101

Earlier quoted context omitted.

You're probably just not writing that much javascript, or needing javascript, so it sounds like you're not missing anything! I don't find using Vue adds complexity for me anymore, and I enjoy a lot of the benefits of it (component libraries, scoped styles). That might not be enough for you when you're working with mostly vanilla CRUD pages, so I totally get it. If your productivity goes down with Vue, then it should…

> 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 framework (like what rails gives you). So, I can get why someone might say "it's not enough".

Re: Escaping the SPA rabbit hole with modern Rails

#114

Post by zmmmmm »

sho wrote: post #51
zmmmmm wrote: post #27

Earlier quoted context omitted.

> It also lead to a culture of staunch refusal to learn or do anything new in that job I find one of the most difficult aspects of software is the very powerful "local minima" of effective (but not optimal) techniques combined with entrenched knowledge. People are so incredibly biased towards what they know well, and that bias is backed by objective evidence: when they do it X-way they are objectively faster AND bett…

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…

Heh, it is interesting how people can have inverted mental models of the same thing.

Actually, my preference for minima vs maxima is because minima translate readily to the natural world where you can imagine balls rolling down surfaces or water running down hills and getting stuck in local "minima" even though there is a lower energy state available to them. It makes a much easier mental model for me than thinking about maxima.

Re: Escaping the SPA rabbit hole with modern Rails

#115

Post by randop »

I feel like seeing more and more post about criticisms for workflow or framework that it is becoming unhealthy with the developer community.

There is always short comings on every tool and library, and part of responsibility of a good developer is discerning trade-offs.

Re: Escaping the SPA rabbit hole with modern Rails

#116

Post by acdha »

tshaddox wrote: post #105
acdha wrote: post #77

Earlier quoted context omitted.

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.

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.

Re: Escaping the SPA rabbit hole with modern Rails

#117

Post by sho »

cmjqol wrote: post #60
sho wrote: post #18

Earlier quoted context omitted.

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

Serveverless is not lambda. If you think so , you are mistaken , it's like saying Cloud == EC2 .

Well what is it then?

Re: Escaping the SPA rabbit hole with modern Rails

#118

Post by peteforde »

y4mi wrote: post #74
divs1210 wrote: post #61

Earlier quoted context omitted.

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

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

I'll give it a shot if there's a stable build of the ReagentBrainFuck transpiler working.

Re: Escaping the SPA rabbit hole with modern Rails

#119

Post by peteforde »

divs1210 wrote: post #61
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…

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.

Re: Escaping the SPA rabbit hole with modern Rails

#120

Post by _Tev »

andrei_says_ wrote: post #100
wjossey wrote: post #93

Earlier quoted context omitted.

This is now my feeling as well, after coding in Vue for only 9 months. If I started a project tomorrow, I'd use Vue on day 0 100% of the time. Even if I'm just rendering HTML, the process of using it helps me to separate out my components and break them down into small and understandable pieces. I'm sure I'd get the same benefit from Ember, Angular, React, etc., if I knew those frameworks as well. My feeling is that…

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 lot of the time you can do both approaches, but in the end your desired UI complexity drives the tradeoffs.

Post reply on HN