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

81–90 of 137 posts

Re: Escaping the SPA rabbit hole with modern Rails

#81

Post by mooreds »

sho wrote: post #21
lucidone wrote: post #15

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

> decoupling your data from it's presentation will be a fruitful investment Very good point. You'll be building an API anyway if you want a mobile app. However, you can probably get away with a much smaller one, for only the most interactive parts of the app - I've gotten a lot of mileage out of simply embedding web pages for fiddly things like settings pages and other complex forms in mobile apps, saving the native…

> There's a certain type of person who's always going to be grumpy about learning something new.

I resemble that remark :). But I hear you, sometimes you have to invest to figure out if something is any good, and one way to do so is to build something real with it.

However there's danger on the other side too--a company with 5 different apps in 5 different frameworks or languages that all have to be supported by a small team of developers. That can't leverage deployment or performance tuning knowledge across apps. Where work is siloed because "Dev X doesn't know golang and Dev Y doesn't know rails". And where you can't rewrite the app because the business leaders wonder what they'd get.

Re: Escaping the SPA rabbit hole with modern Rails

#82

Post by vmware513 »

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…

Why you had to rewrite Ember.js to React? Ember.js is fast, modern and easy to work with. The Ember ecosystem is matured and reliable. It doesn't really make sense.

Re: Escaping the SPA rabbit hole with modern Rails

#84

Post by fny »

temporaryacc62 wrote: post #76
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…

Would you say Youtube works better now as it is fully SPA?

There's an army working on YouTube, and it has the traffic levels to justify the investment. They can actually put in the required effort to ensure the application functions seamlessly and meets accessability standards.

Re: Escaping the SPA rabbit hole with modern Rails

#85

Post by lauritzsh »

vmware513 wrote: post #82
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…

Why you had to rewrite Ember.js to React? Ember.js is fast, modern and easy to work with. The Ember ecosystem is matured and reliable. It doesn't really make sense.

OP said the primary reason was hiring -- "The primary reason stated was hiring and the secondary was build times."

Re: Escaping the SPA rabbit hole with modern Rails

#86

Post by GordonS »

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-side technologies to be 'old skool', and prefer to use whichever SPA library is the new hotness - but IMO, most web apps just don't have UIs that are complex enough to warrant using a SPA.

Re: Escaping the SPA rabbit hole with modern Rails

#87

Post by GordonS »

emodendroket wrote: post #69
zitterbewegung wrote: post #47

Earlier quoted context omitted.

Can you expand on significant amount of front-end functionality ?

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?

Re: Escaping the SPA rabbit hole with modern Rails

#88

Post by GordonS »

rlafranchi wrote: post #35
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…

I’ve had a wonderful experience using Vue in Rails applications and there are ways to do this without building a full blown SPA. The philosophy towards JS frameworks has usually been full throttle or not at all. I think there is a happy medium where you can use Vue when it makes sense to. This is a great application especially for existing projects that need to be more interactive.

I've used the same approach on some web apps, but combining ASP.NET MVC Core with Vue. I think it's quite common for web apps to have only parts that have a complex UI (even if it's the main part), so this pattern makes a lot of sense for some teams.

Re: Escaping the SPA rabbit hole with modern Rails

#89

Post by hashkb »

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.

Or that you need to be introduced to Reagent. Simple doesn't even begin to describe it.

Re: Escaping the SPA rabbit hole with modern Rails

#90

Post by GordonS »

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…

> 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

What needs to die is this grounded-in-fantasy contempt for mature, very much alive, performant technologies with huge ecosystems.

Post reply on HN