That font is ridiculously huge. It's painful to read. Looks like the browser's font resize functionality is blocked but you can change the size by resizing your browser width. I really don't like that UI pattern.
Modern Front-end in Rails
71–80 of 150 posts
Re: Modern Front-end in Rails
#72Earlier quoted context omitted.
If your react/vue codebase is isolated to client end, how is your server going to render react/vue code?
You have a simple nodejs server that renders using react nextjs, vue nuxtjs, angular universal, or ember fastboot while using rails for your APIs.
So now you've simplified your 1 app server into 2 app servers that aren't even the same language or environment.
Re: Modern Front-end in Rails
#73Earlier quoted context omitted.
When you say you're going back to 'the good old way', out of curiosity, what do you mean? 'Unobtrusive' JS and ajax here and there, but primarily server rendered templates? Or something else?
We are going back to server rendered templates yes. We are using erb's for templating, jquery, sass and bootstrap, and Turbo Links. It's old and boring and works like an absolute charm. It's not that we don't use JavaScript, we do quite a bit (we're not into CoffeeScript, it's a personal preference). We are using Action Cable for rendering data through web sockets which is one of many examples of a JavaScript heavy p…
It's old and boring and sensible. You need a SPA if you're building something like Google Maps, but most products just don't need it. It introduces so much overhead and so many new problems that just don't exist in a server rendered approach.
I applaud this approach and would love to have an opportunity to one day work at a company that values reliable and sensible approach to building software instead of just following the latest fashion.
As Mikey Dickerson said; what we need is basic, well-known technology, applied correctly.
Re: Modern Front-end in Rails
#74Turbolinks 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.
Turbolinks just "works" so easily out of the box - for most use cases of persisting header / footer / etc between pages your users will think it's a "true" SPA. Even comes with the customizable css loading indicator now to re-enforce that feeling of speed.
Re: Modern Front-end in Rails
#75Earlier quoted context omitted.
To your first point, you can still server side render if you use an API by serving your frontend through a server that fetches data from the API before rendering
And at that point is the added complexity worth not just rendering with rails?
>And at that point is the added complexity worth not just ~rendering with rails~ using Node.js for your server?
Re: Modern Front-end in Rails
#76I understand the craze. But c'mon...
http://www.castingcall.club serves over 1M pageviews a month. Total hobby project. It has a hybrid of what this article describes. I have my `/app/assets` folder for most of the pages on the site and I've got my webpack `/frontend` folder which handles the complex components.
I also run http://program.reforge.com. Same approach. Rails asset pipeline for the pages that are simple and React on the pages that need to be componentized.
Re: Modern Front-end in Rails
#77I 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…
> Most applications need to be reasonably fast, reasonably responsive, and extremely easy to maintain and extend. Exactly this. I do a lot of freelance rails work and have worked on all kinds of ruby/rails projects. I would say for honestly at least 80% probably around 90% of projects, the "old school boring" rails way is by far the way to go. The whole front end heavy craze is really not the right choice unless you…
Do you think RoR is a good choice when all you really want is a service with a REST API?
I prototyped something in a couple of days with Python and Flask and it made a good enough impression that we are thinking about fully developing the idea. I'm open to just about any tech and am thinking about continuing with Flask (and Flask-restful), using Go, or Ruby on Rails. I have almost no experience with any of these and that's part of the reason they appeal to me.
Re: Modern Front-end in Rails
#78Rails is still a truly incredible framework and it still moving very fast in terms of development. It’s front end stuff has always felt wrong to me and many others and we found weird ways to doing what we wanted. Rails 5 added support for a lot of them as the article points out but it still feels complicated. Rails is awesome bc it’s opinionated but the fact that it’s ruby still lets you do what you want. I think rai…
I don't understand from your comment whether you are aware that Rails 5.1 introduced generators to automatically add Vue, React and Angular (and Elm subsequently)? It sets everything up neatly and allows you to selectively incorporate reactive components where they're needed in your application, without having to go all the way to separating front and backend completely.
https://medium.com/statuscode/introducing-webpacker-7136d66c...
Re: Modern Front-end in Rails
#79Earlier quoted context omitted.
> Most applications need to be reasonably fast, reasonably responsive, and extremely easy to maintain and extend. Exactly this. I do a lot of freelance rails work and have worked on all kinds of ruby/rails projects. I would say for honestly at least 80% probably around 90% of projects, the "old school boring" rails way is by far the way to go. The whole front end heavy craze is really not the right choice unless you…
Do you think RoR is a good choice when all you really want is a service with a REST API? I prototyped something in a couple of days with Python and Flask and it made a good enough impression that we are thinking about fully developing the idea. I'm open to just about any tech and am thinking about continuing with Flask (and Flask-restful), using Go, or Ruby on Rails. I have almost no experience with any of these and…
I’ve built rails api only applications for a long time and I find it to be a great experience. Now, to be fair, I pick it because I know Rails very well. But it’s worth taking a look at for sure.
Re: Modern Front-end in Rails
#80Rails is still a truly incredible framework and it still moving very fast in terms of development. It’s front end stuff has always felt wrong to me and many others and we found weird ways to doing what we wanted. Rails 5 added support for a lot of them as the article points out but it still feels complicated. Rails is awesome bc it’s opinionated but the fact that it’s ruby still lets you do what you want. I think rai…
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.