Live data from Hacker News

Modern Front-end in Rails

evilmartians.com

141–150 of 150 posts

Re: Modern Front-end in Rails

#141

I built a rather extensive application for a client over the last 18 months using Rails API and Angular, using a number of these sorts of principles. While it is entirely possible to use what the article suggested, I argue it's a premature optimization and may be a detriment to the entire project. We're now actively removing the Angular portion of the project and going back to the good old way. I wouldn't say this de…

Totally agree with the sentiment. I see engineers put to much time and energy focusing on frameworks and architecture and not enough time on building business value. The joy of Rails is that for the most part you can just focus on getting shit done, focus on building value instead of figure out the right directory structure or which latest framework to use (learn) on your project. I have yet to see a demonstrable ben…

making a game in a browser is a nice use case for react.js, I agree that business apps could do with simpler controls. That said, some responsiveness is unavoidable in business apps, because entering data to lists and grids takes time and if the browser crashes or is inadvertently closed, all that work will be gone.

Re: Modern Front-end in Rails

#143
post #126
post #91

Earlier quoted context omitted.

Thus creating cleaner, more focused, more testable, likely faster, and more maintainable code bases. Which also adhere to the Single-Responsibility Principle. We as developers already offload certain tasks to separate servers. Do you use your app server to terminate TLS connections? You could; but why would you when Nginx can do a much better job of it? You could store you application data like usernames and password…

The specific contention is that the JS frameworks aren’t any/much better for user and they are unquestionably harder to develop. The only time I can justify SPA is if you’re primarily differentiating via the UX.

That's a bit misleading. There's several tools you have available and you should pick the best tool for the job. Also, SPAs are only harder if you haven't already learned them. For anything too complex to not simply use WordPress, it's often preferable to use an SPA for the superior UI/UX experience (both for the developers and the user). Plenty of exceptions are welcome though, for example if the site's functionality is based around a key jQuery plugin.

Re: Modern Front-end in Rails

#144

I built a rather extensive application for a client over the last 18 months using Rails API and Angular, using a number of these sorts of principles. While it is entirely possible to use what the article suggested, I argue it's a premature optimization and may be a detriment to the entire project. We're now actively removing the Angular portion of the project and going back to the good old way. I wouldn't say this de…

I feel exactly the same, I use a hybrid approach, Vue/TS on the client (refactoring a legacy mess) and Symfony components (not the entire framework, legacy project) on the back end but not a full SPA, reusable composable components with a single core VM that orchestrates the page.

I get a lot of the benefit of a SPA (client side reactivity/UX/UI) with the benefit of a traditional architecture.

The "do it all on the server" vs "do it all on the client" approaches never made sense to me, do the bits that each is best at in the correct place.

Re: Modern Front-end in Rails

#145

Earlier quoted context omitted.

I would split in two even if I'm working on it alone.

Ok. Let's see from another side on this point. If you are beginner Rails developer who doesn't know how to configure Webpack properly and doesn't know how to works with React/Vue/Ember? And if your project must be a SEO-friendly? You don't know React, Webpack and doesn't know how to works with React/Vue SSR. Maybe learning its tools will be an excellent investment if you want to be a front-end developer. But what if…

Did you try create_react_app? I find it way easier to setup my frontend using it than to use webpacker, even being used to both rails and react. You type "yarn build", and you have properly fingerprinted js and css files ready to use, with an `index.html` file that includes them. It's great to only focus on backend in rails, and it brings all the cool thing from js dev for free: babel, webpack, yarn, live reload, import of css files, etc.

SSR is indeed still a problem (I've build a cache system that will render pages with chrome headless, for that), but gladly, it's about to be solved (at least for the SEO part): https://webmasters.googleblog.com/2017/12/rendering-ajax-cra...

The biggest problem yet to be solved: properly handling 404 status.

Re: Modern Front-end in Rails

#146
This article and a lot of opinions I hear like this are incredibly ignorant. There's nothing wrong with using Rails in a "classic" way as everyone seems to call it.

I do think calling Rails' method classic and these new frameworks "modern" a bit ignorant. If anything Rails is "modern" and these new frameworks are just that, new. Being new does not mean you're modern. It means you're new. A trend. You'll likely be gone tomorrow.

Re: Modern Front-end in Rails

#147

I think Vanilla Rails sprinkled with a bit of React can go a long way. Not every part of an app needs the duplicity of state, or need to look dynamic.

> sprinkled with react I can sprinkle in javascript for a normal rails app to add behavior - but i thought react required moving all rendering into it? are you able to "sprinkle" with react within otherwise normal html/css/js?

It's even easier to sprinkle with Vue.js

Re: Modern Front-end in Rails

#149

I built a rather extensive application for a client over the last 18 months using Rails API and Angular, using a number of these sorts of principles. While it is entirely possible to use what the article suggested, I argue it's a premature optimization and may be a detriment to the entire project. We're now actively removing the Angular portion of the project and going back to the good old way. I wouldn't say this de…

I've built a fairly large, modern web app using rails and intercooler ( https://github.com/LeadDyno/intercooler-js ) and I've been very happy with the results: simple, feels modern and easy to extend. The two technologies play very well together and I've been able to add AJAX at the high value points in the app, rather than biting off a huge bit of infrastructure that needs to be maintained everywhere.

I really like intercooler. I’d rather sprinkle UI goodness instead of jumping neck deep into jS frontend quicksand.

Re: Modern Front-end in Rails

#150
post #2

Wow, I like how readable the text is. The typography in the post is beautiful.

Whenever I see a front-page link about Rails, I always think, " I bet the top comment threads will be about the font or layout rather than the content ". Click, and... yep! It's been about ten years, and you don't see as many Rails posts as you used to, but it still holds true!

probably due to the fact that rails tends to be more accessible for junior frontend devs or designers guys that want to try some backend stuff
Post reply on HN