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

101–110 of 137 posts

Re: Escaping the SPA rabbit hole with modern Rails

#101

Post by wjossey »

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?

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 take a big reason to add it. For me, it at minimum is not net negative, and I'd say even for trivial pages it's a net positive.

Re: Escaping the SPA rabbit hole with modern Rails

#102

Post by jgalentine007 »

manquer wrote: post #56
wjossey wrote: post #6

To the author of the article- Kudos! Well written, well reasoned, with minimal hyperbole or unnecessary “X is dead” style declarations. Hope we see more writing like this bubble up to the top on HN. I’m not swayed by the argument, but that’s personal bias. I’m the technical cofounder / solo coder of a venture backed startup, and I built our platform on rails 5. I migrated our front end to Vue over the winter and coul…

My experiences are pretty much the same, the important distinction was when we added support for mobile apps, the API design problems had to be solved anyway, and significant differences between the interfaces for both mobile and web made it a pain to work with, we shifted to full API driven back-end and ember front-end and I cannot be happier. I think the author is missing the fact that it it hard to justify Rails o…

This is what is pushing me to write spa first now - it covers all the consumption bases. You get desktop, mobile web/progressive/hybrid and half of native.

Re: Escaping the SPA rabbit hole with modern Rails

#103

Post by kkrs »

virtualwhys wrote: post #28
kkrs wrote: post #23

Earlier quoted context omitted.

Elm + Scala works for me. I'm using the same elm source with minor variations for both web & mobile (wrapped with cordova). So far, it's been working wonderfully.

That's an odd choice given Scala.js, any reason you're not all-in on Scala?

The elm architecture removes the need to make decisions when it comes to structuring the app. The tooling is first class. While I'm not sure, I think elm has a larger community.

Re: Escaping the SPA rabbit hole with modern Rails

#104

Post by brandonmenc »

wjossey wrote: post #101
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?

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

Re: Escaping the SPA rabbit hole with modern Rails

#105

Post by tshaddox »

acdha wrote: post #77
thesephist wrote: post #70

Earlier quoted context omitted.

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

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.

Re: Escaping the SPA rabbit hole with modern Rails

#106

Post by pier25 »

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…

Thanks for sharing the video. It's really good.

Re: Escaping the SPA rabbit hole with modern Rails

#107

Post by Dirak »

dragonwriter wrote: post #91
Dirak wrote: post #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 drive…

Isn't the problem in your rant of SPA architectures vs MVC the fact that plenty of SPA architectures are client-side MVC architectures, and most of the rest are slight variations in the MV* family (MVP, MVVM, etc.)

No. That's exactly wrong. We need to stop even thinking in terms of MVC. React, Vue, Angular all used component based architectures and if you think component based architectures can be labeled as MV* then you're not understanding why this pattern is lightyears better than MVC.

MVC was a hack of a pattern that developers adopted to get server side rendering architectures to even work. Good developers recognized its many flaws and when front-end development became decoupled from the server, tried and true practices and patterns such as modularity, reusability, and separation of concerns were adopted to the front end and the results of those efforts are the front end frameworks and libraries we have today. They are not variations of MVC. If you work with them as such, your SPA architecture will look just as brittle and shitty as a server-side architecture.

Re: Escaping the SPA rabbit hole with modern Rails

#108

Post by dragonwriter »

Dirak wrote: post #107
dragonwriter wrote: post #91

Earlier quoted context omitted.

Isn't the problem in your rant of SPA architectures vs MVC the fact that plenty of SPA architectures are client-side MVC architectures, and most of the rest are slight variations in the MV* family (MVP, MVVM, etc.)

No. That's exactly wrong. We need to stop even thinking in terms of MVC. React, Vue, Angular all used component based architectures and if you think component based architectures can be labeled as MV* then you're not understanding why this pattern is lightyears better than MVC. MVC was a hack of a pattern that developers adopted to get server side rendering architectures to even work. Good developers recognized its m…

> MVC was a hack of a pattern that developers adopted to get server side rendering architectures to even work.

MVC wasn't even developed for networked applications, but for desktop GUI applications; it was later adapted for web applications,

And server-side rendering existed and the worked before MVC was a popular pattern to use for it; MVC was a step forward in making applications doing it maintainable, but want chosen to get it to work at all.

> Good developers recognized its many flaws and when front-end development became decoupled from the server, tried and true practices and patterns such as modularity, reusability, and separation of concerns were adopted to the front end

MVC came from application of exactly those principles to desktop development, and was adopted precisely to bring those to web development. Sure, it wasn't the end of the road in that, but it wasn't done kind of reversion from it, either.

Re: Escaping the SPA rabbit hole with modern Rails

#109

Post by eropple »

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?

You're missing that writing TypeScript, for a lot of people (myself included these days, if we're being honest), is a lot faster than writing Ruby. My productivity has spiked a ton by moving almost exclusively over to Swagger APIs in TypeScript and continuing that by writing a (relatively easy, relatively quick, not-magic-Rails-junk) React frontend is just the path of least resistance.

And I like Ruby.

Re: Escaping the SPA rabbit hole with modern Rails

#110

Post by noxecanexx »

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…

+1 for the last paragraph. I used that technique to quell my desire to use event sourcing everywhere
Post reply on HN