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 decision was made without careful thought nor without weighing many options. But when it comes down to it, many line of business applications (which is what I see a lot of in the market) don't need the level of sophistication the instructions in this article gives. Most applications need to be reasonably fast, reasonably responsive, and extremely easy to maintain and extend. Does working with all of these modern front end tools that change so quickly and given at least one order of magnitude increase in complexity also give the application a equal increase in speed, responsiveness, maintainability, and extensibility? I don't think so.
> 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 need a very high degree of desktop-like interactivity which again is something most i.e. 80/90% of applications I see in the wild do not require.
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.
> Do you think RoR is a good choice when all you really want is a service with a REST API?
I'm going to be honest with you. I love building pure REST apis in rails. The experience is so clean and effortless.
That being said there is at least one caveat to using RoR for the first time, and thats that the learning curve is probably going to be a little steeper than a rest lib like flask where things are more explicit, since there is a lot of convention over configuration in RoR. Once you learn the conventions, the development speed is ridiculously fast, but until then things can be pretty opaque and take some time to get used to, especially for people who don't understand well how the ruby runtime works. I've witnessed this on multiple occasions with multiple projects, if there are more advanced/not-stack-overflowable things that need to be done, devs who are working in RoR and ruby for the first time, will run into a lot of roadblocks. This has little if anything to do with their particular skills as a programmer and more to do with the dynamic nature of ruby and a lot of very tricky hacks rails does under the surface to make the end-user api clean and succinct.
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.
Agreed. My latest project has a Vue front-end (it's a small tool) and Rails does a wonderful job just dumping JSON for the front-end to render.
Even if it is a little excessive (which I don't think it is), I have features planned in the future where having an ORM like ActiveRecord+Ruby will make things very simple.
One note about RoR: it's very opinionated about using convention over configuration. It's very efficient if you generally work with it's convention. However, if you design and/or goals are regularly in conflict with those conventions, RoR might not be the best tool to use for that project.
I'm just learning Flask myself - are you using a database for storage? That's my next step. I've done full apps with RoR and this would not be a question at all with RoR, it's already built in, just toying with Python/Flask to learn stuff.
For the prototype, I just put my data into some json files. Connecting to some kind of database would be my next step if I continue on with it. Probably would use SQLAlchemy.
I'm a bit of a REST newbie and so some concepts (esp HATEOAS) are still a bit blurry. I would probably take a little time to dig into just what goes into a well-structured REST service.
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.
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 benefit from the single page app, front end framework, microservice backend that I didn’t have with a Rails monolith 10 years ago. The majority of what I see these days is unwarranted complexity.
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.
I've been noticing the problem of fancy js-driven front-ends on the open web more lately too. I feel like not a day goes by when I don't use some site that just breaks on a certain browser, or exhibits weird unintended ui behaviour with unresponsive buttons or blank page loads. Blogger is a classic example, but I see a lot of sites from travel to banking that used to be perfectly serviceable and boring become unreliable lately and months later the problems don't get fixed. Usually the source reveals angular.js or something like it.
This has got to be costing companies money, but it's hard to say when we'll see a return to simplicity as a virtue.
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 portion of our application. We also have a near native mobile application for Android and iOS. Other than the wrapper for the mobile applications, the application is monolithic.
Overall, we've seen a substantial increase in speed, responsiveness, and most importantly our ability to maintain and extend the application.
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.
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.
This completely reflects my experience too, as I recently got back to building line of business apps and clients were impressed by the snappiness of basic Rails apps with server rendered templates. Like you said the impact on complexity (and also important on productivity) of going the SPA route for this kind of apps is not justified for me.
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.
That presentation makes me want to learn Rails but fortunately there is a shortcut, you can use turbolinks on its own (written in coffescript thought).
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.
Developers need to be a part of successful projects. Specific tech is less important unless you want/need to go to work for/with people to whom "modern" means fashionable. Which, to be fair, is a larger portion of the industry than most of us care to admit, but then again, React and Vue basics can be learned on side projects.
(Angular, less so, though these days I do appreciate it when companies are so kind as to list Angular in their job postings; it's a good heuristic for weeding out based on the probability that there's no one with influence at the organization that thinks about the tools they're using carefully.)
In my area, it doesn’t much matter whether they actually have experience in Vue/React/Angular, all three and more are on their resume anyway and they can easily talk about the technologies.
There’s no doubt I have had applicants pass on us because we don’t use one of those frameworks. But there are plenty of other great web devs who do want to work in a reasonable environment and love it. So it’s balanced out.
I’d say my greatest selling point for the job is that we deploy all day long to production. Developers love getting features to users.
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.
Honestly, as a Rails dev, this just seems more complicated than creating a Rails app in API mode and using #{React||Vue||Ember}} for the front-end.
It's extremely easy to get started with a front-end app using vue-cli. This article spends a lot of time changing Rails' default functionality to achieve behavior similar to what vue-cli gives you by typing `vue init webpack` and answering a few questions.
I understand that getting up to speed with a front-end framework takes time, but in my case, it was time well-spent (I used Maximilian Schwarzmüller's Vue.js course on Udemy). There's no shame in just using Rails for the API.
The downside there is that you're then forced to build your application as a completely separate service and static site. With this approach, you can stick single page app where the UI needs to be more stateful and then use traditional server-templating for other things. I'm doing this w/ phoenix now and its nice because my typeahead search is done as a JS component, but the corresponding index and show pages are still mostly the same as what was scaffolded.
Not to mention, the combined approach is 100% necessary if you are going to require a server render for your react||vue|ember stuff.
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 in a JSON file if you really wanted to. But why would you when you can run an SQL server and use a real database?
Pick the best tool for each job. JS frameworks handle the view layer better than Rails does.
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 entire codebase duplicating the request your client is making. It actually breaks SRP more than it helps, because you'll need to constantly keep it in sync with your rendering/client codebase in order to perform server rendering. The individual codebases may be more maintainable but your application as a whole now has fragmented responsibilities.
I can't imagine when the trade-off of introducing an entire new layer of infrastructure into your app in addition to your normal app servers would be worth it just for the purpose of server side rendering outside of some specific niche scenario. That sounds like overengineering to the extreme.
> 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.
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.
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.
The Nuxtjs (and the others) SSR peices are not "an entire extra app you write and maintain", it's a small component, mostly already written by the nuxt team, that does one thing. It allows you to write a leaner, better focused backend.
It's probably a matter of tastes, either one project or two projects.
I've been working with Rails since 2006 and I'll create two separate projects. A Rails API project and a front end one. Two projects, two repositories, maybe two teams (specialized teams are more common than full stack.) The front end is served by the reverse proxy in front of Rails.
If I want to serve some semi-static HTML page from Rails, all I have to do is sharing the CSS file and create a controller for that (PagesController is a classic.) I don't think there are many chances of sharing HTML in a meaningful way among ERB and JSX, that must be duplicated.
Then Rails people will work with Rails tools and JavaScript people will work with the favorite tools of the month. The advantage is that if you want to onboard some pure front end developers they won't have to learn about Rails.
Of course! If you have human resource to separate and maintain backend and frontend - it's an excellent solution.
But it's article not for teams like this. The described solution for full-stack developers and small projects, which needs to be maintainable too. And component manner is a proper way to organize frontend code.
My project started more than four years ago. It was a mainly content project around content creating and sharing, and of course SEO.
Facebook released React two month early than we started. Webpack has not yet created. Gulp is a bleeding edge. And we used sprockets, CoffeeScript and SASS.
It's is a massive project now. And it changed development vector for last year. We make a lot of changes, and we haven't resourced for rewriting them on separated front-end and back-end for now.
But described methodology allows us to keep this project maintainable. We migrated this approach from Sprockets to Gulp, and from Gulp to Webpack.
And we thought. What if we tell about how we maintain the project to beginners? They are writing jQuery-spaghetti code, and they may don't know frontend frameworks and Webpack.
Let's tell them how to write maintainable code with webpacker, components, BEM and our code organization. It's maybe a good starting point for them.
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.
We did not set a goal to teach well-experienced front-end developers how to organize their code. The well-experienced developer knows about many ways of code organization and can choose one for a project depending on the situation.
Agree in principle, but any technique is frigthening at first.
Clearly for the authors this is a usual workflow - they're productive with it, and they only had to pay the complexity cost once (when figuring out things).
Once you get an integrated frontend-backend system and codebase, you start to get unique benefits:
- Server-rendered data, for avoiding superfluous ajax requests
I'm in the middle of converting a small production Rails API + Ember app to Rails Views + Vue.js using webpacker and a lot of the techniques discussed. It's certainly been a learning curve, but I'm definitely happier with the new setup for all of the reasons you mentioned.
It's not a one-size-fits-all solution, but for a single dev / small team working on a web-only application it can make a lot of sense.
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
Yeah, really good point; this article is kinda halfway between "modern client-side app" and "traditional server-controlled app", and it kinda feels like the worst of both worlds (added complexity without many of the benefits)
For what it's worth, there are a lot of good reasons to have access to both (though not saying the article is doing it the best way). There are all sorts of pages that aren't worth the boilerplate and extra time to develop (data-heavy admin pages, trivial about pages, etc). I love SPAs for the heavy-hitting User-facing pages, but for a lot of things they're total overkill and not worth the extra maintenance and development effort
Rails 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 rails needs to really dedicate some effort to better generators that ask which of these modern front end approaches do you want to use and then setup the project to just work and let me get to my coding.
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.
Totally agree. You can go the .js.erb views and `$('#div_id').replaceWith('<%= escape_javascript(render partial :partial_name) %>')` route, or you can use render_to_string and put your partial HTML in JSON and replace it with frontend JS, and so on and so on. And there's also turbolinks to consider and the idempotent stuff.
It's all great, I got my way around it, but I never know if what I'm doing is considered best practice or not.
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.
> 1. isolated, reusable, testable code that is easy to reason
> about;
> 2. short “code change → visible result” cycle;
> 3. straightforward dependency management; and
> well-maintained tools.
> Sure, “classic” Rails gives our code some structure: there
> are separate folders for view templates, javascripts,
> stylesheets and images. But as the front-end complexity
> grows, navigating them quickly becomes a cognitive drain.
WAT?
1. I don't see how the directory renaming / npm config changes this at all.
2. I guess this is an argument for speed of asset pipeline? As mentioned in the article itself, Rails 5.1 webpack with hot reloading built in. How much faster can you get?
3. I don't think I've ever heard of npm referred to as a well-maintained tool.
Beyond that, the idea that Javascript-heavy web apps are "Modern" is kind of silly. They're certainly trendy. In the vast majority of the cases I've seen, there's no coherent reason for the added complexity.
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 and it's components. like Bower works).
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 for vue, react, or what have you. But no need to start there! Use those as targeted air strikes
I think the issue is that with out of the box rails apps, there's not a lot of opportunity to perform one of these 'targeted air strikes'. Emergent requirements incentivize quick solutions and you can end up with a bunch of ad-hoc foundation components and really bad jquery-ui slapped around in erb files.
At least, that's been my (very limited) experience with it.
I've found it easier to just drop in `react-rails` and build out react components for certain situations than to try and string a bunch of jquery together.
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.
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.
This is over-engineering at its finest, and doesn't answer some questions: When do you want to use a front-end framework, and why?
For at _least_ 90% of the things out there, you don't need a front-end framework like React/Vue/Ember/Angular. And while these front-end frameworks increase the complexity of the app, its trade-off often doesn't nearly provide enough value in terms of speed/extensibility/maintainability to warrant it.
Rendering server-side views is fine: plug-in Turbolinks and have a blast. It's not cool, it won't get you stylepoints with your colleagues, but you should be trying to impress your client/boss with speed/extensibility/maintainability, and not impress with complexity of your stack.
Hm. While I think it's awesome that the Rails community is moving towards adopting modern JS practices, from this post, it's not making a very good case for _why_ you'd want to do this.
Modern JS is lovely to write compared to ES5, but this tutorial doesn't write any yet! Perhaps this'll be addressed in the next part of the tutorial (although doing it in a framework-agnostic way seems tough).
Also, if I'm reading this correctly, they're still attaching an `erb` for each component, and using Rails to determine how they relate to each other? This feels a bit wrong to me, at least for dynamic web applications; when you have a framework like React controlling all of your front-end rendering, it's easy to integrate client-side routing and make it a single-page app, which means lightning-quick page transitions.
So yeah, delighted to see Rails move towards this direction, and this post is super helpful in explaining the "how" for a basic setup, but not the "why"; it also falls a bit short IMO in going "all the way", to have the front-end truly control its destiny and reap the benefits associated with that.
We have a large monolith rails app and are gradually moving the front end to Vue. And as we start to seeing those “lightening-quick page transitions” it makes me want to devote more resources over to the change.
The method in the article seems like a very non-conventional way to go about it with no added benefit.
I may be mistaken, but I think the meat of this will be in post 2?
It sounds like your taking React's render() and replacing it with ERB. But, how are you giving the ERB file access to state and props?
I suppose if it's done well, this would make it easier for Rails devs to adopt single page apps. It sounds like you're abstracting away a lot of React and creating a Rails-ier API to it.
I think the intention is to go the opposite way: instantiating React components in the ERB template and passing in state/props from the controller instance variables.
Off-topic: That website sets font size in `vw` (viewport width percentage). This is horrible: Text is way too large on maximized desktop browsers, and zooming the page doesn't change that, but only causes a weird jump in position.
Worse than that: if I make the window narrow it displays some 40 lines, if I maximize it displays 20. The expected behavior is that the font size is independent from the width of the window, exactly as on HN and any other site.
What's the purpose of making text small, punishing readers for not maximizing the site? :-)
Seriously, it could be a way to make text flow into a smaller column, but there is no need to make text smaller. HN reflows and keeps the same font size.
Not trying to start a flame war here, buy what is the argument for using Rails over Express or Django/Flask for a new project ? Genuinely curious to know the benefits / downsides of each option
You can't compare Rails to Express. It's a much, much more full-featured web framework. JS doesn't really have an equivalent to Rails (that I know of).
Django is comparable in scope but Rails is many times more popular and a lot more work has gone into it. IMO you would need a very good, specific reason to choose Django over the far more popular Rails.
Genuinely to answer, Rails offer much richer environment, Express is pretty much bare bones server, Flask is comparable to Sinatra, the only comparable thing is Django and, especially in new version it got much better, I still think Rails is much more flexible solution, which offers you a lot already premade stuff, with your ability to control how things will be used, still quite significant.
Most of all, I believe a set of good practices enforced or encouraged with Rails is what distinguish it over all other frameworks.
Most difficutlty with Rails is after few years when you need to upgrade, I feel a lot of busy work has to happen then.
There really aren't any major benefits/downsides anymore regardless of what you'll read. To clear one thing up, you should compare Rails/Django/Sails (each language's "full" web framework), and Sinatra/Flask/Express (minimalist web frameworks). Each of the full frameworks offer a flavor or configuration of the framework that is focused to building RESTful APIs, and you can build the front end in whatever you want. The only major difference between frameworks in each class will be the language and ecosystem it uses. Of course there will be people that have heavy feelings towards whichever ecosystem they like the most that will tell you it's WAAAYYYY better than the other frameworks, but in reality it's nonsense.
When starting a new project, my major decision is if I want to use the REST API flavor of one of these frameworks + react on the front end (substitute with your front end framework of choice), or build the project fully in the framework itself. I've been writing a lot of python lately, so I go with flask for small or quick/dirty stuff, Django or Django Rest Framework for bigger stuff. React on the front end if it needs to be a SPA.
> There really aren't any major benefits/downsides anymore regardless of what you'll read
Who made you the grand arbiter? There are huge differences. Rails is miles ahead in the options you present. Probably 90% of startups that don't have a specific reason not to, use Rails - and rightly so.
Rails has over 65k commits. Django has 25k. Sails? Less than 7k. Don't tell me these are equivalent.
Rails is a great entry point into web development, because it Just Works. If you need to do something not included, there's most likely a Ruby gem that integrates seamlessly with Rails. Need authentication? Authorization? Audit trails? Piping logs to different systems? There's several mature options for each in the Rails ecosystem.
Rails is a very mature set of DSL tools. There is nothing even close to the level of integration, richness, community, and documentation that Rails offers.
Ruby by itself is a powerful reason to develop with Rails.
Much of the reconifgufation work here seems to relate to just moving the default webpack Javascript directory from /app/javascript to /frontend (or something on root).
The Rails team historically is known for making informed decisions about file structure conventions, since Rails already picked app/javascript as the place for webpacked JavaScript, why the need to move it?
I really wish Rails came with an easy out of the box to run as a REST api mode that let you load your initial front end from a single endpoint, or for server rendered react/vue/angular that can then hit the REST api, in a way that let you abstract the front end cleanly so that front end developers never need to touch anything rails related.
Rails with webpacker built in and rails api mode are both awesome, but they don't feel well integrated together.
Sure, you can get this working in a rails engine, but it feels like a hack and you miss out on a lot of built-in template goodies. There is also shakacode's React on Rails, which is awesome, but still pretty tightly integrated with the default rails views.
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.
Funny you mention that. I have a 4k monitor and bad eyesight and normally have to zoom in on webpages. When I clicked this one I was pleased that it was already zoomed in for me.
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.
I see a lot of people respond negative to this post, I got a lot from it.
First it shows you how to override rails defaults to create very similar environment that you would get if you would go api/react or vue. Advantage with this setup is that you still Rails foundation and this comes with a lot of goodies.
I love that it explain rather simple way to have hot reloading, I feel this makes me significantly more productive.
Overall really enjoyed article and will adopt many of ideas in it. It is good way to modernize your Rails projects.
Thanks for this, I've been fooling around with trying to get a Rails + Vue app started and sampling a bunch of tutorials.
One thing that would help me understand this better is a short overview of your strategy and why you chose it as opposed to some other options mentioned like rails api + JS-framework frontend.
It goes from history to nitty gritty, so I'd have to follow through step by step to get an idea how it all fits together.
I found it to be much easier to build an API (in rails or whatever, I use phoenix/elixir now) and consume it with either a frontend framework like ember (I use elm now) or a static site generator (I use hugo).
This way I can produce either an app frontend (something that requires JS) or a site frontend (something that doesn't require JS).
This website is total crab on my Laptop. The font is huge and zooming with ctrl +/- doesn't work (firefox 57).
Edit: Sorry for my harsh words. I just get kinda angry when I come across websites that don't allow me to zoom in or out, especially when the default font size is way off the standard.
Curious : is there an up to date analysis on the reasons you would still want to render to html on the server today ? Which search engines work fine with client js rendering the page ? Are there other issue you may still experience ( facebook links, mobile browsers bugs, etc) ?
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!
I've also been around for getting on 10 years (ok, 8.8, close enough) and this is literally the first time I have heard anyone compliment the typography of a Rails post, let alone noticed it occurring enough to become an identifiable trend.
I know this is off topic, but I noticed the typography too and was just seeing if I could tell what it was before looking. But oddly enough, I can't seem to find out what typeface is used using the developer tools for the life of me. Does anyone know how that could be hidden from the styles pane?
The rendered typeface is Stem Text. If you click on an element with the typeface and go to the computed tab that will show you what font-family style is applied.
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?
Yes you can. Not like jQuery where you use it to manipulate the DOM (as rendered from HTML generated on the server).
With React you basically let it manage one or more subtrees of the DOM; you let React do the rendering for that subtree at all times (possibly using React on the server to do pre-rendering).
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.
Yes. Thousands and thousands of engineers still use Rails to be produce valuable web applications and APIs. For a large number of use cases, there is little benefit to moving to a different stack.
This is precisely what was always wrong with the “Rails philosophy”. Front end should be completely independent to any kind of backend. The level of integration proposed here is an absolute nightmare to maintain and extend.
It’s not just a backend, Rails is a full stack framework - from database administration to data modeling, business logic to frontend. It literally has built in frontend templating in the form of erb.
That said, I think that frontend development has evolved into a place where frontend development is better done separately. As part of its evolution, Rails integrated Rails API and can be configured minimally to be a backend API only.
I wouldn't say this decision was made without careful thought nor without weighing many options. But when it comes down to it, many line of business applications (which is what I see a lot of in the market) don't need the level of sophistication the instructions in this article gives. Most applications need to be reasonably fast, reasonably responsive, and extremely easy to maintain and extend. Does working with all of these modern front end tools that change so quickly and given at least one order of magnitude increase in complexity also give the application a equal increase in speed, responsiveness, maintainability, and extensibility? I don't think so.
I'm not the first person to say this. Take a look at this presentation by Sam Stephenson, it will be worth your while: https://www.youtube.com/watch?v=SWEts0rlezA