Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Modern Front-end in Rails

evilmartians.com

Post reply on HN
Print view View original

131–140 of 150 posts

Re: Modern Front-end in Rails

#131

Post by debaserab2 »

Can_Not wrote: post #123
debaserab2 wrote: post #108

Earlier quoted context omitted.

More testable? Because they are discrete codebases, possibly. It sure sounds like getting a dev environment setup that mirrors the production env just got a lot harder. Given there is an entire new codebase there is now an overall larger coverage area to test. Faster? I don't see how putting an entire app server layer in between your HTTP requests is going to make anything faster. More maintainable? You now have an e…

> You now have an entire codebase duplicating the request your client is making This is factually wrong. You have a small component that mounts your front-end like a pure function. No loss in maintainability, no "duplicate" anything.

Not at all. There are two HTTP requests: one from your client to your rendering server and one from your rendering server to your app.

That's two different places that logic must be deployed to and tested against. It's irrelevant that it's the same render code.

Re: Modern Front-end in Rails

#132

Post by hyeomans »

polysaturate wrote: post #69
trcollinson wrote: post #40

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…

Turbolinks is plenty fast enough and simple enough for most Rails projects. Maybe sure you're relying on the correct Turbolink events and there's pretty much not anything else you need to change to have Rails automatically load server rendered markup through PJAX.

Any good tutorials/books/resources on Turbolinks?

Re: Modern Front-end in Rails

#133

Post by quantumofmalice »

trcollinson wrote: post #40

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.

Re: Modern Front-end in Rails

#134

Post by brandonmenc »

quantumofmalice wrote: post #133
trcollinson wrote: post #40

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 also endorse Intercooler.

It's perfect for small to medium sized apps that need just a little bit of front-end sprinkling.

Re: Modern Front-end in Rails

#135

Post by 20years »

quantumofmalice wrote: post #133
trcollinson wrote: post #40

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 have used intercooler too for a couple of apps. It is a joy to work with in comparison to some of the Angular apps I have worked with.

Re: Modern Front-end in Rails

#136

Post by moron4hire »

sillysaurus3 wrote: post #88
trcollinson wrote: post #40

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…

By abandoning React, Vue, and Angular, you're excluding yourself from hiring all the webdevs that need a front-end technology on their resumes in order to get hired elsewhere. That's a pretty large swath. But yes, it's nice that the world is finally realizing Arc was way ahead of its time. HN is snappy because the HTML is small, with few network requests. https://rauchg.com/2014/7-principles-of-rich-web-application..…

Used to be a day you could get hired on a C# job with just Java experience, say nothing about the particular libraries you used within those languages.

Re: Modern Front-end in Rails

#137

Post by Can_Not »

debaserab2 wrote: post #131
Can_Not wrote: post #123

Earlier quoted context omitted.

> You now have an entire codebase duplicating the request your client is making This is factually wrong. You have a small component that mounts your front-end like a pure function. No loss in maintainability, no "duplicate" anything.

Not at all. There are two HTTP requests: one from your client to your rendering server and one from your rendering server to your app. That's two different places that logic must be deployed to and tested against. It's irrelevant that it's the same render code.

Except all 4+ SSR and framework teams have been working on this technology for years and put a lot of thought and design into it, so it's not so randomly sloppy that the one client SPA will need duplicate testing suites just to prerender HTML serverside.

Re: Modern Front-end in Rails

#138

Post by minor3rd »

the_gastropod wrote: post #85
muthdra wrote: post #56

Earlier quoted context omitted.

NPM is a well-maintained tool. Version 5 got major updates in speed and usability. They where aware of the Node release cycle and implemented the new version in advance so it would be rolled out alongside Node. NPM now does way faster caching than before, can lock dependencies in specific versions more easily (inspired by Yarn) and may have a flat dependency tree if your project demands it (like when using Polymer an…

Yarn exists because npm has historically been a problem-riddled package manager.

They still have some awfully awkward stuff in npm5. In some cases they will overwrite your package.json with logging data (WTF?)

Re: Modern Front-end in Rails

#139

Post by minor3rd »

captain_crabs wrote: post #37
nicolasMLV wrote: post #34

Turbolinks is the official Front-end part of Rails and it works very well, but there is no mention of it in the article neither in the hackernews comments, so i think it is under-used. There's also turbolinks-ios and turbolinks-android, I built my mobile apps with minimal knowledge of Swift and Kotlin.

I've transitioned from rails-everything to working exclusively with front-end frameworks and libraries (react, angular, polymer), and I'll tell you this still: if I'm working in rails, I use turbolinks. It's a wonderful approach, way under-appreciated. When two or more things on the page need to know about each other/you require a high-fidelity interaction that you can't easily handle with just it, then yeah - reach…

Have to disagree on this one for anything but the most basic apps (think blogs and lots of static content). I'd have rewritten my entire app over by now with the "targeted air strikes" approach.

Re: Modern Front-end in Rails

#140

Post by inopinatus »

coisnepe wrote: post #80
inopinatus wrote: post #27

Earlier quoted context omitted.

The webpack integration coming in Rails 5.2 starts to do exactly what you suggest. We’ve had the beta in general use for weeks and I’d say the framework is going in the direction you want. This article seems a bit of overengineering by comparison and isn’t representative of what’s new out-of-the-box.

Does 5.2 add anything on top of 5.1? The core team added the webpacker gem back in February this year but I haven't checked out yet what they're planning with 5.2.

ActiveStorage for managing file uploads is the other big new feature.

There’s also a new secrets mechanism of dubious necessity. Seems DHH just can’t stop reinventing those.

Post reply on HN