10 ms·

Love the idea of it, even if it's not for me. Ruby needs new blood infused into it. I realized recently that Rails started losing its popularity because it jus

Love the idea of it, even if it's not for me. Ruby needs new blood infused into it. I realized recently that Rails started losing its popularity because it just didn't quite keep up as the web evolved. Where the framework and its community resources (guides/tutorials) should have started promoting REST APIs and out-of-the-box no-friction compatibility with modern tooling like npm/webpack/react/whatever, instead it stuck with "the Asset Pipeline," purely MVC-style full-page-reload apps, and things like Coffeescript/jQuery by default. It's really unfortunate because Rails is such a brilliant framework, and Ruby such a lovely language, and they're falling out of the mainstream and losing popularity because of this. I wish the community would re-align. Michael Hartl's book, the go-to "learn Rails" resource, is a classic example. I think it's costing the community more than helping it nowadays. Although it's a great guide, it just feels weirdly out of date to be building a purely MVC full-page-reload app. And I think for every person it helps, five people look at it and think "seem like this isn't what I need for my project."

cageface 6y ago
I think it's more that the massive engineering effort that's gone into improving JS has leapfrogged it over languages like Python, Ruby & PHP in terms of performance and tooling. And since you're stuck with JS on the frontend there are some significant advantages to using it on the backend as well. I don't think any of the current JS frameworks are as comprehensive as Rails but it's clear where the momentum is.
- pmontra 6y ago
  Actually I'm not seeing many projects with a JavaScript backend. In my experience the number is one, and it was 2015. I mean, backends of projects I worked on or somebody offered to hire me to work on. It could be selection bias and yet they're asking me about Java, which I basically abandoned about 15 years ago, PHP, which I know since the beginning of it but only kind of toyed with, even C# which I can read as a foreign language close to one I know but never used. I wonder if anybody asked me about Rust or Go, probably not. What they ask me about and I accept to work on are Ruby, Elixir and Python, in order of my preference. Python is a distant third (as preference.) About frontend: JavaScript all the times if there is a frontend separate from the backend. React with some rare Angular project. I'd like to make a poll and see how many of the people here are working on a JavaScript backend vs any other language.
  - aerovistae 6y ago
    Same. I never understand these things I read about JavaScript momentum on the back end. I have yet to encounter a company using Express on the back end.
    - eagsalazar2 6y ago
      I've been curious about this lately: https://reimagined.github.io/resolve/ https://reimagined.github.io/resolve/. Anyone use it? Thoughts?
  - eguanlao 6y ago
    Survey results of back-end JS: https://2019.stateofjs.com/back-end/ https://2019.stateofjs.com/back-end/ Only those who know about the annual State of JS survey.
  - arcturus17 6y ago
    I read an article from Thoughtworks where they said they use NestJS in some production apps that benefitted from Node's performance characteristics. In the same article however they were critical of the trend of shoe-horning server-side JS into projects where more classical languages/frameworks would be a better fit.
  - cutler 6y ago
    That hardly sounds representative of the Node.js adoption curve. Could you elaborate on your typical client profile? Are you a solo freelancer, maybe attracting clients with legacy codebases? Location?
    - pmontra 6y ago
      Freelancer, Milano, Italy. They reach to me either for taking over existing projects or to start new ones. Of course it can be selection bias but it extends to the other developers I'm in contact with.
      - cutler 6y ago
- muglug 6y ago
  > I think it's more that the massive engineering effort that's gone into improving JS has leapfrogged it over languages like Python, Ruby & PHP in terms of performance and tooling This is not true – PHP is still much faster when running on the server than NodeJS. JS has got much faster in the last 20 years, but in-browser execution has seen most of the speedup (as it's where most of the optimisation is focussed on).
  - arcturus17 6y ago
    What benchmarks are you basing this on? From what I can find, in most benchmarks, Node.js is much faster than PHP - orders of magnitude in many cases [1]... This is what I've always heard anyway, that the amount of R&D that has gone into engines like V8, the C++ under the hood and the I/O model make it so. [1] https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/php.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
    - muglug 6y ago
      PHP isn't faster for arbitrary mathematical workloads (though the JIT in PHP 8 will help with those). Instead PHP is faster for the things websites normally do, like string manipulation.
      - arcturus17 6y ago
        I see this is the hill you want to die on... "Instead PHP is faster for the things websites normally do, like string manipulation." No, this is not right for a couple of reasons. NodeJS is potentially slower in certain CPU-bound tasks due to the single-threaded nature of JavaScript. On the other hand, thanks to its event loop and concurrency model, NodeJS is much faster than many languages/runtimes in I/O (reading/writing to stores, fetching data from other servers, etc.) - which is what many web servers do most. Your original comment also mentioned: "in-browser execution has seen most of the speedup (as it's where most of the optimisation is focussed on)." Which is also not true. The V8 engine is hyperoptimized and runs not only Chrome but Node too. It is precisely one of the reasons why server-side JS has gained in popularity over the last decade. The fact that it was initially devised for a browser environment does not mean that optimisation is focused there. If you're an engineer or web developer I really suggest that you brush up on these things, because with comments like the ones you've been dropping you'd definitely raise eyebrows - and not for the good...
- troughway 6y ago
  This is a little bit premature of me to posit however I have a good feeling about tech like Blazor. In particular Blazor offers two interesting approaches (“hosting models”): 1) a websocket-based HTML sync layer, basically shipping over the smallest amounts of render state from the back-end. This is as close as you get to having, essentially, a server-side rendered page that is then updated in real time. 2) a wasm based approach where the whole application is delivered to the browser and you make the API calls. Both have you writing majority of the code in C# and Razor templating syntax. Yes, you make an argument that well it’s technically still JS running it. But this becomes an implementation detail that will be ironed out, because technically the browser is written in C++, but we look beyond all that. And so on and so forth. Now, I’m not saying I expect the world to move to .NET. Far from it. I have been preaching for a language agnostic browser execution engine so that I can write not only my logic, but my layout and styling in whatever language I want to, whether it’s Ruby or F# or Lisp, and have the browser execute it via its own internal “assembly code”. Except I’ve been parroting this idea since mid-2000s and we have at last finally started down that road. I think this is where we are headed, and I don’t think it’s far fetched.
  - cutler 6y ago
    Blazor currently has to haul its runtime over the wire before it can do anything so a non-starter for anything performance-sensitive.
    - learc83 6y ago
      Did you miss this part: >1) a websocket-based HTML sync layer, basically shipping over the smallest amounts of render state from the back-end. This is as close as you get to having, essentially, a server-side rendered page that is then updated in real time. Also it's not like you have to load the runtime more than once. So it's not that it's a non-starter for anything performance sensitive--it's a non-starter for anything that can't download a 2MB file up front (I believe their goal is to get it down to half that size) if you want to use the WASM version of Blazor instead of the websocket-based HTML sync layer version.
      - 6y ago
- jamil7 6y ago
  In my experience I’ve seen JS on the backend really only used for lambda functions, to run socketio for some chat-like feature or for pre-rendering React components.
  - dynamicdox 6y ago
    I work for a Fortune 50 and my team’s product is JS frontend and backend. JS all the way down :)
    - jamil7 6y ago
      Might just be my area then (Berlin) I hardly see job ads for JS on the backend.
      - cutler 6y ago
        Node is massive in London so, yes, your experience has an element of local bias.
      - ritchiea 6y ago
        Wow we must be in separate Berlins because I see tons of JS backends. My impression is Javascript & Python are competing for most popular backend.
        jamil7 6y ago
        Quite possible that I live in my bubble! I see a lot of React & React Native but hadn't seen so much on the backend.
        pdoub 6y ago
        Seconded that in another comment in this thread. Lots of "fullstack JS saves you money since you can hire the same devs for web, backend & mobile" in Berlin, with varying success
- arcturus17 6y ago
  > I don't think any of the current JS frameworks are as comprehensive as Rails To someone who is switching from the Node ecosystem to Django REST, this seems like an understatement. I'd be happy to use server-side JS for certain microservices that needed its performance characteristics, or for prototyping in something like Firebase functions. But the mere thought of building a standard fully-featured web app in Node depresses me.
  - rektide 6y ago
    the whole trend though is that the server side is mostly a very tiny crud layer & a little bit of business operations. yeah tools like django are amazing packages. node is shockingly hardly any more tamed than it was 5 years ago, still rag tag Express for the most part. with who knows what for the data layer. but it just doesn't matter. alas! the actual application has been heavily front end biased, & all the real investment g architecture needs to revolve around that front end. it'd be great to have better out of box omakase js experiences. projects like hapi & fastify tried. but there's just not enough effort spent on the back end for that many devs to really care. and plenty of folks are using api based systems or hosted backends, appsync or some hosted graphql, where they can care even less about the backends. why be comprehensive when you hardly matter?
    - joelbluminator 6y ago
      > mostly a very tiny crud layer & a little bit of business operations. Even if you have a SPA, which isn't a given (yes, trends. I know. They come and go), the API, data migrations and background workers can easily be 50% of your code and effort.
      - arcturus17 6y ago
        Yea, I have switched to Django with the intent of continuing to develop primarily SPAs. Like I said in other comments I'd only build an API in Express if I needed its particular performance characteristics. I've checked other tools in the JS ecosystem that serve as "low-code" API layers, but upon close inspection they always seem to have some limitations on the business logic you can write, and some of them lock you in to products. No thanks. I'm finding Django REST gives me a sweet middle ground between dev speed backed by great abstraction "magic" and freedom to customize as the app grows.
- rektide 6y ago
  > i think it's more that the massive engineering effort that's gone into improving JS has leapfrogged it over languages like Python, Ruby & PHP in terms of performance and tooling. huge js lover here but I don't think this is true. I think the basic obvious progression is that the client side has shouldered more & more responsibility, that architectures have shifted away from being server side, & few folk have figured out how to make the server relevant. it does a tiny bit of business logic & mostly just crud operations on data. trying to do like we did, keep rendering & a lot of the client state on the server- it wasn't helpful, was a bad way of doing things. these choices of languages became irrelevant as the client side rose in prevalence, capabilities, & yes too, somewhat, performance, but mainly I chalk it up to a long long struggle to find suitable architectures. I don't think this is fair accompli, that it's all decided, but server side needs to radically change it's game if it wants to become relevant again.
- cknoxrun 6y ago
  The concept of performance is interesting, to me it should be more applied to the user's experience of performance. And personally, when I come across a slow, janky SPA where a server-rendered site would have made a lot more sense, I feel immediately annoyed by the lower performance.
universa1 6y ago
Hmmm, At least in rails 6 it moved away from the asset pipeline to a webpacker thing. It always was opinionated, and imho for many applications the classic full-page-reload cycle is still good enough, or a js client-side app doesn't bring any benefits besides being the cool thing to do. The docs were a problem from the beginning, but that improved a little with the official guides. As someone who used it on and off since version 1.x, it is obviously familiar and I am biased. Though it still feels like not really getting in my way when doing things and I can just write a feature and be done with it, when following the rails way. In the past I spent a lot of time in the freenode #rubyonrails channel, and a lot of beginners would have benefited greatly from understanding how a MVC app works, and along with it stuff like request-/response cycle. Especially since this also translates well into API/client-side apps. Sorry if this is a little incoherent, I am a little sleep deprived and back to the baby now :-)
- aerovistae 6y ago
  I certainly agree the classic full page reload approach is still completely relevant. It's more that most websites nowadays will employ a hybrid approach. They need a bit of both. Anything that isn't a static website is going to be using react or some other front end frameworks, and a lot of react involves asynchronous requests with REST APIs. But most rails resources focus exclusively on the one approach, with very little of the other.
  - universa1 6y ago
    I don't know the resources anymore, but Rails really embraced the REST (in it's opinionated way) approach with rails 3+. So any more or less up-to-date doc should indoctrinate the REST-style, especially for CRUD. You might need to make the transfer from the data is not coming from a form anymore, but some JS that sends JSON, but that is something a developer should be able to do... And yeah, I also think a mix is what makes sense for most things, and there it can be anything from plain js/jquery through stimulusjs to react/vue. Even though it sounds to me like I am trying to defend rails, this is not really what I am trying to do, just trying to show a little bit different perspective :-)
dperfect 6y ago
I used Rails for a lot of projects starting ~10 years ago, but slowly gravitated towards a stack based on Sinatra (for a lean REST API), Middleman (static site generator), and webpack/react/etc - for mostly the reasons you describe. In hindsight, I can't blame Rails for the direction it took; JavaScript's path (the language itself, as well as the tools) has been extremely volatile in that time. Rails is opinionated, which is part of what makes it great, but to be more opinionated on JS in the past probably would have been detrimental to the Rails community. I've felt the pain in my own work: every 2 weeks, it feels like my webpack/react/babel/etc toolchain and codebase need to be refactored because what was recently best-practice is now considered "legacy" and unsupported. When you embrace a specific set of technologies, you take on a certain amount of risk that those technologies will be deprecated, unsupported, or unpopular tomorrow. I believe (hope is probably the better word) the JS landscape is getting more mature and stable, and it makes sense that the recent versions of Rails have incorporated more of what has become "standard" JS tooling. I'll always love Ruby, and even if I don't use Rails at the moment, I appreciate what Rails is doing and I directly benefit from the contributions of the Rails community. More recently, I've been trying to learn some Elixir (those Phoenix LiveView demos look amazing), but not sure I'm ready to jump in 100%. Looks like matestack is essentially doing something similar with Ruby, so I'll be interested to see where it goes.
- dnautics 6y ago
  If you want a sinatra equivalent for elixir, you can use plug.
- d3nj4l 6y ago
  You can try out Turbolinks, the Rails equivalent for LiveView.
  - latortuga 6y ago
    This is not exactly a great characterization of turbolinks. TL definitely is great and useful for blurring the lines between server rendered and SPA, but it isn't anything like liveview. For that you're looking for something more like Motion (https://github.com/Unabridged/motion https://github.com/Unabridged/motion). Disclaimer, maintainer, but the comparison is much closer.
gls2ro 6y ago
> Ruby needs new blood infused into it. yes, I strongly agree with this, specially when talking about Web tech. I am programming in Ruby (and Rails) for over 12 years and I think I had the same feeling up until a couple of years ago that it become a stable system where I could move quickly and create new products but did not have so much newness. But now I see at least two things which makes me love even more this ecosystem: 1. Stimulus JS along with StimulusRelfex https://docs.stimulusreflex.com/reflexes https://docs.stimulusreflex.com/reflexes 2. ViewComponent https://viewcomponent.org https://viewcomponent.org And now I discovered this Matestack. I am excited because Ruby on Rails is a technology I know very well and I was (and still am) a little against moving to full SPA and adopting a JS framework for frontend. Somehow the SPA felt to me a little unstable in general, when compared with SSR. This unstable I think was mostly due to being very hard to debug real production issues. It might be from the way debugging worked in the beginning not showing proper line of code where the JS error was, or it might be because of my own resistance to change. But now with these new tools added to the Ruby eco-system I can make the web interface more responsive and in the same time feel that I only add stable components into an app.
- arcturus17 6y ago
  Can't tell what your SPA experience has been, but in my experience React with a standard webpack configuration such as what you get with create-react-app provides an extremely detailed trace. Never felt like I've lost more time than I should there.
  - gls2ro 6y ago
    Probably nowadays React with webpack provides a stable experience. It might be that my impression of SPA is also based on my resistance to dedicate time to learn the new tools. Usually I want to start doing stuff and then go back and read more. This is why I say it felt that way and I did not say that the SPA is unstable. Here is how my experience with SPA looked like: - I started with jQuery, 10 years ago or so (actually with Scriptaculous :) ), replacing parts of the interface with Ajax calls. Worked a little for a while then got into very ugly code both on JS and on Ruby. This was not a full SPA, but it was moving into that direction. - Then I moved to Backbone around 2013 I think. In the beginning it sounded very nice in the end again the code and mix with jQuery quickly become hard to organise. Also as it started to be slower to build MVPs in terms of moving fast and adding application features. - So I tried Angular and my main problem there was debugging production issues. The errors I saw on browser console were mostly not giving any clue about what went wrong. Probably it was because of the whole compile JS pipeline to support various browsers ... - Then I inherited a Webapp written in React (around 2014 or 2015) with backend in Rails which was a second-screen for a radio show. It provided various live interaction with listeners. There I saw the need for SPA but also is where SPA lost me as I spent a lot of time debugging simple things from someone could not be able to login to how long it took to add a new page to display some poll results. For sure a big part (or the most part) is on me and with my expectation about how things were working in Rails where if I wanted a page to display some poll results it meant to simply build a .html.erb and it was done. Of course later on came Action Cable and I started using it for any live thing. Again I am not saying SPA is in general heavy or hard to use. I am saying that for the products I build SSR sprinkled with some small reactive things is enough and for me (when I am mostly the solo developer) it is fast to produce (from idea to deploy) and debug a feature for a web app. That being told I am trying to learn Vue - and force myself to use so that I want to have experience with this kind of frameworks.
rektide 6y ago
alas for rails, a very very large percent of it's simplicity & adoptability were derived from it being so so so so server side based. useful for making an easy to use opinionated framework. but ultimately, expectations moved on. rails has continued finding it's way, trying to find a rails way to do things, but without that original simplicity, it's not nearly as compelling a sell. no one's done a particularly good job keeping a more server-side biased model. thicker clients keep winning & winning. I don't think it has to be this way, but it's going to take some soul searching & big up front bold vision & architecture to muster to the challenge & create a more balanced client - server relationship. not a ton of obvious winners hereabouts! but I believe!
Lio 6y ago
I’m actually quite bullish about Rails for the fitst time in a while due to StimulusRelex[1]. It’s a similar approach to Elixir’s Liveview and provides reactive, diff’d partial updates streamed over a websocket. This seems a very “now” approach to building webapps. 1. https://docs.stimulusreflex.com/ https://docs.stimulusreflex.com/
- te_chris 6y ago
  Cool that people are doing a live view type thing in Rails, but it introduces a lot more complexity without the BEAM
- joelbluminator 6y ago
  > streamed over a websocket That's my problem with this approach, I wonder what the penalty is (performance and complexity wise) for going that route. What is it using for websockets btw, Action Cable?
  - ksec 6y ago
    >What is it using for websockets btw, Action Cable? And that is a problem because by default Action Cable isn't scalable. You cant get it work by 100 - 200 connection and response time are very slow at 50ms+ and a lot higher at 95th percentile. AnyCable helps a lot but this is another pieces of complexity added to the system. Not a problem for Elixir and BEAM when they are sort of built for these type of workload. Although I am waiting for all the Fibre, Async and Ractor addition to Ruby 3 and see how they add fit in.
    - joelbluminator 6y ago
      > AnyCable helps a lot but this is another pieces of complexity added to the system. What is the added complexity? I honestly never used all this stuff.
- maxthegeek1 6y ago
  Neither Elixir Liveview nor StimulusReflex are really viable longterm, especially for mobile web. The idea of chattily streaming UI changes over the network doesn't work out for mobile web, where networks are frequently unreliable if not totally inaccessible.
rolae 6y ago
Rails has very much embraced webpack and different ways to build SPA on it, with providing an API only mode and easy install webpacker install commands. Maybe for an oppinionated framework it now offers too many ways to do the frontend. But more importantly, Rails is still insanely productive to work with. And with gems like stimulus_reflex and matestack you can get reactivity easily without having the complexity of full blown SPAs.
monkin 6y ago
I still prefer the good old “build stuff in rails” (which change a lot, something you don’t really know) over build everything in JS. Which is mostly popularized by new kind of programmers breed who learned everything purely from YouTube. They don’t know their tooling, systems, how web apps works, make huge mistakes on each level. Just putting the one solutions they know in everything. Do they think about what they doing and if this approach is feasible? No, not at all. It’s like with Wordpress, everyone is using it because of popularity, but WP is a nightmare to work with, and most of the time a huge overkill for what’s intended. I will not even mention Gatsby and super simple websites made in React because of it... > It's really unfortunate because Rails is such a brilliant framework, and Ruby such a lovely language, and they're falling out of the mainstream and losing popularity because of this. I wish the community would re-align. And this, this is just outrageous. Do you have anything to back this claim up? I’m not rails/ruby developer, but it always irked me when someone’s saying such thing about any language. Don’t get me wrong, JS is awesome, React/VUE on top of it too, but the point is, to know when and how to use them.
- matthewmacleod 6y ago
  Which is mostly popularized by new kind of programmers breed who learned everything purely from YouTube. They don’t know their tooling, systems, how web apps works, make huge mistakes on each level. Just putting the one solutions they know in everything. Or—bear with me here—it’s possible that everyone other than you actually isn’t an idiot and there are issues that you are neatly stepping over with this patronising nonsense.
  - monkin 6y ago
    Oh, wow a personal attack! I didn’t want to offend anyone, but you somehow feel attacked. Either way, have a good day. :)
masa331 6y ago
I think it's quite the contrary. Rails integrated Webpack a long time ago in it's basic installation so if you do `rails new my_cool_app` you have Webpack ready(and preconfigured with React/Vue/Elm etc.) right out of the box. Also it moved away from Coffeescript and jQuery. And for the full page reloads, which you think is weird, there are Turbolinks(again preconfigured in the basic install) since like 2012. I'm not sure React or other reactivity foos already existed at this time. And now we have things like Stimulus and Stimulus Reflex and others so the development ain't stoping now either. So the feeling that Rails are stuck or out of date is really only a feeling.
tarsinge 6y ago
MVC full page reload are fine with turbolinks and can deliver a better user experience (at least that’s what I get from my clients). The issue for me is more philosophical: JS is still not acknowledged as part of the view, the mindset is still stuck at the separation of concerns = separation of technology era. I’m not doing SPAs, but I’m not doing Web 1.0 pages either. I have views where tightly coupling JS is the sound choice, because well, the JS is really a part of that view (e.g. a data visualization). But for that Rails makes me juggle between two different apps for the same view (even worse with webpacker).
vinceguidry 6y ago
Christ. It did keep up. Every new rails release just makes it better and better. Rails isn’t popular anymore because people followed the swan song of language isomorphism overlooking JavaScript’s deficiencies. NodeJS improved by... adding Rails features. It’s amazing that people think there’s more to this story. It was Node that couldn’t keep up with Rails. No one cares cuz they didn’t want to learn ruby.
- aerovistae 6y ago
  I don't really see too many companies or projects using node on the back end. It's pretty hard to buy that node replaced rails. I see a lot more Java than anything else.
  - jozzy-james 6y ago
    i think it really depends on the industry - mine for example, most of the bigger players are running express apps on the FE (not 100% sure on backend, seems a mix of go/node and other things) - but why bother to run express/node on the frontend if you're not also going to leverage it on the backend.
  - cutler 6y ago
    That's because Java is one of the top 3 adopted languages and is general purpose. A more relevant comparison would be between Node.js and Django, Rails or Laravel and as far as job stats go, eg. https://indeed.com https://indeed.com, Node.js is everywhere.
  - pdoub 6y ago
    A lot of companies I'm speaking to (mostly Berlin/Germany based startups) have drank the "we have to use JS on the frontend anyways, and by going fullstack JS we can reduce our payroll since we can focus on only hiring JS devs and they magically work on ReactNative, the React web app and the Node.JS backend at the sime time" koolaid. Works super well for some, less so for others... Edit: Explicitly added Node.JS since that's what they rave about for making it possible.
- Existenceblinks 6y ago
Fire-Dragon-DoL 6y ago
Well, realistically, rails is a bad choice for a json rest api. As for everything else you said, it is doing that as far as i'm aware. Webpacker it's a thing.
- grumple 6y ago
  Is it? It has an api mode and I’ve used it extensively for that at multiple workplaces and projects.
  - Fire-Dragon-DoL 6y ago
    Yes but at that point you are getting all the disadvantages of Rails, without the strong points (fast prototyping and everything related to rendering HTML pages, file uploading etc.). Presuming you wanted to stay in Ruby for the API and wanted to stay in a project similar to Rails (so, preserving ActiveRecord), Roda + ActiveRecord gets you there with already much higher performance. If you think about it, a JSON API needs very little. Rails has a lot of added complexity for just rendering JSON. Even the sheer amount of files a Rails project has by default is enormous for something that simple.
    - grumple 6y ago
      > Yes but at that point you are getting all the disadvantages of Rails, without the strong points (fast prototyping and everything related to rendering HTML pages, file uploading etc.). Your perception of the strong points of rails are very different from mine. The strong points include rapid data and logic modeling, json serialization (jbuilder), robust libraries for user management (devise) and many other things, built-in security, routing logic, easy testing, and meta programming. You still get rapid prototyping in api mode, with a rails generate scaffold quickly capable of creating tables and a json rest api for that resource in a single line with no additional work necessary (assuming you had no business logic, which is generally easier to write in ruby as well).
      - Fire-Dragon-DoL 6y ago
treis 6y ago
The problem I have with Rails is that it's not a complete solution. You can use the generators to scaffold a bunch of stuff but those pages have no CSS and lack basic javascript like dynamically adding a row to a form. I don't think they need to go all the way to something like react. But a souped up Turbolinks where you can also easily do partial rerendering of pages would be enormously helpful. The barrier for entry into doing anything is still Rails + Bootstrap/Tailwind + webpack/yarn/npm. Which is a lot more than just whipping some stuff up in rails.
tomc1985 6y ago
We come from dramatically different perspectives because building page-reloading MVC still feels fine, as fine as it ever did. And Turbolinks is Rails' answer to the madness that is JS frameworks. You get a lot of the functionality of a single page app while still keeping the much-easier-to-code-for serverside rendering I am very happy I don't have to touch JS frameworks if I don't want to. Because I hate all of them (except Vue and jquery, they're cool) Rails isn't for trendy hipster JS kids, and I hope it never will be. I don't want those people in this space, they fuck everything up

cageface 6y ago

I think it's more that the massive engineering effort that's gone into improving JS has leapfrogged it over languages like Python, Ruby & PHP in terms of performance and tooling. And since you're stuck with JS on the frontend there are some significant advantages to using it on the backend as well. I don't think any of the current JS frameworks are as comprehensive as Rails but it's clear where the momentum is.

pmontra 6y ago
Actually I'm not seeing many projects with a JavaScript backend. In my experience the number is one, and it was 2015. I mean, backends of projects I worked on or somebody offered to hire me to work on. It could be selection bias and yet they're asking me about Java, which I basically abandoned about 15 years ago, PHP, which I know since the beginning of it but only kind of toyed with, even C# which I can read as a foreign language close to one I know but never used. I wonder if anybody asked me about Rust or Go, probably not. What they ask me about and I accept to work on are Ruby, Elixir and Python, in order of my preference. Python is a distant third (as preference.) About frontend: JavaScript all the times if there is a frontend separate from the backend. React with some rare Angular project. I'd like to make a poll and see how many of the people here are working on a JavaScript backend vs any other language.
- aerovistae 6y ago
  Same. I never understand these things I read about JavaScript momentum on the back end. I have yet to encounter a company using Express on the back end.
  - eagsalazar2 6y ago
    I've been curious about this lately: https://reimagined.github.io/resolve/ https://reimagined.github.io/resolve/. Anyone use it? Thoughts?
- eguanlao 6y ago
  Survey results of back-end JS: https://2019.stateofjs.com/back-end/ https://2019.stateofjs.com/back-end/ Only those who know about the annual State of JS survey.
- arcturus17 6y ago
  I read an article from Thoughtworks where they said they use NestJS in some production apps that benefitted from Node's performance characteristics. In the same article however they were critical of the trend of shoe-horning server-side JS into projects where more classical languages/frameworks would be a better fit.
- cutler 6y ago
  That hardly sounds representative of the Node.js adoption curve. Could you elaborate on your typical client profile? Are you a solo freelancer, maybe attracting clients with legacy codebases? Location?
  - pmontra 6y ago
    Freelancer, Milano, Italy. They reach to me either for taking over existing projects or to start new ones. Of course it can be selection bias but it extends to the other developers I'm in contact with.
    - cutler 6y ago
muglug 6y ago
> I think it's more that the massive engineering effort that's gone into improving JS has leapfrogged it over languages like Python, Ruby & PHP in terms of performance and tooling This is not true – PHP is still much faster when running on the server than NodeJS. JS has got much faster in the last 20 years, but in-browser execution has seen most of the speedup (as it's where most of the optimisation is focussed on).
- arcturus17 6y ago
  What benchmarks are you basing this on? From what I can find, in most benchmarks, Node.js is much faster than PHP - orders of magnitude in many cases [1]... This is what I've always heard anyway, that the amount of R&D that has gone into engines like V8, the C++ under the hood and the I/O model make it so. [1] https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/php.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
  - muglug 6y ago
    PHP isn't faster for arbitrary mathematical workloads (though the JIT in PHP 8 will help with those). Instead PHP is faster for the things websites normally do, like string manipulation.
    - arcturus17 6y ago
      I see this is the hill you want to die on... "Instead PHP is faster for the things websites normally do, like string manipulation." No, this is not right for a couple of reasons. NodeJS is potentially slower in certain CPU-bound tasks due to the single-threaded nature of JavaScript. On the other hand, thanks to its event loop and concurrency model, NodeJS is much faster than many languages/runtimes in I/O (reading/writing to stores, fetching data from other servers, etc.) - which is what many web servers do most. Your original comment also mentioned: "in-browser execution has seen most of the speedup (as it's where most of the optimisation is focussed on)." Which is also not true. The V8 engine is hyperoptimized and runs not only Chrome but Node too. It is precisely one of the reasons why server-side JS has gained in popularity over the last decade. The fact that it was initially devised for a browser environment does not mean that optimisation is focused there. If you're an engineer or web developer I really suggest that you brush up on these things, because with comments like the ones you've been dropping you'd definitely raise eyebrows - and not for the good...
troughway 6y ago
This is a little bit premature of me to posit however I have a good feeling about tech like Blazor. In particular Blazor offers two interesting approaches (“hosting models”): 1) a websocket-based HTML sync layer, basically shipping over the smallest amounts of render state from the back-end. This is as close as you get to having, essentially, a server-side rendered page that is then updated in real time. 2) a wasm based approach where the whole application is delivered to the browser and you make the API calls. Both have you writing majority of the code in C# and Razor templating syntax. Yes, you make an argument that well it’s technically still JS running it. But this becomes an implementation detail that will be ironed out, because technically the browser is written in C++, but we look beyond all that. And so on and so forth. Now, I’m not saying I expect the world to move to .NET. Far from it. I have been preaching for a language agnostic browser execution engine so that I can write not only my logic, but my layout and styling in whatever language I want to, whether it’s Ruby or F# or Lisp, and have the browser execute it via its own internal “assembly code”. Except I’ve been parroting this idea since mid-2000s and we have at last finally started down that road. I think this is where we are headed, and I don’t think it’s far fetched.
- cutler 6y ago
  Blazor currently has to haul its runtime over the wire before it can do anything so a non-starter for anything performance-sensitive.
  - learc83 6y ago
    Did you miss this part: >1) a websocket-based HTML sync layer, basically shipping over the smallest amounts of render state from the back-end. This is as close as you get to having, essentially, a server-side rendered page that is then updated in real time. Also it's not like you have to load the runtime more than once. So it's not that it's a non-starter for anything performance sensitive--it's a non-starter for anything that can't download a 2MB file up front (I believe their goal is to get it down to half that size) if you want to use the WASM version of Blazor instead of the websocket-based HTML sync layer version.
    - 6y ago
jamil7 6y ago
In my experience I’ve seen JS on the backend really only used for lambda functions, to run socketio for some chat-like feature or for pre-rendering React components.
- dynamicdox 6y ago
  I work for a Fortune 50 and my team’s product is JS frontend and backend. JS all the way down :)
  - jamil7 6y ago
    Might just be my area then (Berlin) I hardly see job ads for JS on the backend.
    - cutler 6y ago
      Node is massive in London so, yes, your experience has an element of local bias.
    - ritchiea 6y ago
      Wow we must be in separate Berlins because I see tons of JS backends. My impression is Javascript & Python are competing for most popular backend.
      - jamil7 6y ago
        Quite possible that I live in my bubble! I see a lot of React & React Native but hadn't seen so much on the backend.
      - pdoub 6y ago
        Seconded that in another comment in this thread. Lots of "fullstack JS saves you money since you can hire the same devs for web, backend & mobile" in Berlin, with varying success
arcturus17 6y ago
> I don't think any of the current JS frameworks are as comprehensive as Rails To someone who is switching from the Node ecosystem to Django REST, this seems like an understatement. I'd be happy to use server-side JS for certain microservices that needed its performance characteristics, or for prototyping in something like Firebase functions. But the mere thought of building a standard fully-featured web app in Node depresses me.
- rektide 6y ago
  the whole trend though is that the server side is mostly a very tiny crud layer & a little bit of business operations. yeah tools like django are amazing packages. node is shockingly hardly any more tamed than it was 5 years ago, still rag tag Express for the most part. with who knows what for the data layer. but it just doesn't matter. alas! the actual application has been heavily front end biased, & all the real investment g architecture needs to revolve around that front end. it'd be great to have better out of box omakase js experiences. projects like hapi & fastify tried. but there's just not enough effort spent on the back end for that many devs to really care. and plenty of folks are using api based systems or hosted backends, appsync or some hosted graphql, where they can care even less about the backends. why be comprehensive when you hardly matter?
  - joelbluminator 6y ago
    > mostly a very tiny crud layer & a little bit of business operations. Even if you have a SPA, which isn't a given (yes, trends. I know. They come and go), the API, data migrations and background workers can easily be 50% of your code and effort.
    - arcturus17 6y ago
      Yea, I have switched to Django with the intent of continuing to develop primarily SPAs. Like I said in other comments I'd only build an API in Express if I needed its particular performance characteristics. I've checked other tools in the JS ecosystem that serve as "low-code" API layers, but upon close inspection they always seem to have some limitations on the business logic you can write, and some of them lock you in to products. No thanks. I'm finding Django REST gives me a sweet middle ground between dev speed backed by great abstraction "magic" and freedom to customize as the app grows.
rektide 6y ago
> i think it's more that the massive engineering effort that's gone into improving JS has leapfrogged it over languages like Python, Ruby & PHP in terms of performance and tooling. huge js lover here but I don't think this is true. I think the basic obvious progression is that the client side has shouldered more & more responsibility, that architectures have shifted away from being server side, & few folk have figured out how to make the server relevant. it does a tiny bit of business logic & mostly just crud operations on data. trying to do like we did, keep rendering & a lot of the client state on the server- it wasn't helpful, was a bad way of doing things. these choices of languages became irrelevant as the client side rose in prevalence, capabilities, & yes too, somewhat, performance, but mainly I chalk it up to a long long struggle to find suitable architectures. I don't think this is fair accompli, that it's all decided, but server side needs to radically change it's game if it wants to become relevant again.
cknoxrun 6y ago
The concept of performance is interesting, to me it should be more applied to the user's experience of performance. And personally, when I come across a slow, janky SPA where a server-rendered site would have made a lot more sense, I feel immediately annoyed by the lower performance.

universa1 6y ago

Hmmm, At least in rails 6 it moved away from the asset pipeline to a webpacker thing. It always was opinionated, and imho for many applications the classic full-page-reload cycle is still good enough, or a js client-side app doesn't bring any benefits besides being the cool thing to do. The docs were a problem from the beginning, but that improved a little with the official guides. As someone who used it on and off since version 1.x, it is obviously familiar and I am biased. Though it still feels like not really getting in my way when doing things and I can just write a feature and be done with it, when following the rails way. In the past I spent a lot of time in the freenode #rubyonrails channel, and a lot of beginners would have benefited greatly from understanding how a MVC app works, and along with it stuff like request-/response cycle. Especially since this also translates well into API/client-side apps. Sorry if this is a little incoherent, I am a little sleep deprived and back to the baby now :-)

aerovistae 6y ago
I certainly agree the classic full page reload approach is still completely relevant. It's more that most websites nowadays will employ a hybrid approach. They need a bit of both. Anything that isn't a static website is going to be using react or some other front end frameworks, and a lot of react involves asynchronous requests with REST APIs. But most rails resources focus exclusively on the one approach, with very little of the other.
- universa1 6y ago
  I don't know the resources anymore, but Rails really embraced the REST (in it's opinionated way) approach with rails 3+. So any more or less up-to-date doc should indoctrinate the REST-style, especially for CRUD. You might need to make the transfer from the data is not coming from a form anymore, but some JS that sends JSON, but that is something a developer should be able to do... And yeah, I also think a mix is what makes sense for most things, and there it can be anything from plain js/jquery through stimulusjs to react/vue. Even though it sounds to me like I am trying to defend rails, this is not really what I am trying to do, just trying to show a little bit different perspective :-)

dperfect 6y ago

I used Rails for a lot of projects starting ~10 years ago, but slowly gravitated towards a stack based on Sinatra (for a lean REST API), Middleman (static site generator), and webpack/react/etc - for mostly the reasons you describe. In hindsight, I can't blame Rails for the direction it took; JavaScript's path (the language itself, as well as the tools) has been extremely volatile in that time. Rails is opinionated, which is part of what makes it great, but to be more opinionated on JS in the past probably would have been detrimental to the Rails community. I've felt the pain in my own work: every 2 weeks, it feels like my webpack/react/babel/etc toolchain and codebase need to be refactored because what was recently best-practice is now considered "legacy" and unsupported. When you embrace a specific set of technologies, you take on a certain amount of risk that those technologies will be deprecated, unsupported, or unpopular tomorrow. I believe (hope is probably the better word) the JS landscape is getting more mature and stable, and it makes sense that the recent versions of Rails have incorporated more of what has become "standard" JS tooling. I'll always love Ruby, and even if I don't use Rails at the moment, I appreciate what Rails is doing and I directly benefit from the contributions of the Rails community. More recently, I've been trying to learn some Elixir (those Phoenix LiveView demos look amazing), but not sure I'm ready to jump in 100%. Looks like matestack is essentially doing something similar with Ruby, so I'll be interested to see where it goes.

dnautics 6y ago
If you want a sinatra equivalent for elixir, you can use plug.
d3nj4l 6y ago
You can try out Turbolinks, the Rails equivalent for LiveView.
- latortuga 6y ago
  This is not exactly a great characterization of turbolinks. TL definitely is great and useful for blurring the lines between server rendered and SPA, but it isn't anything like liveview. For that you're looking for something more like Motion (https://github.com/Unabridged/motion https://github.com/Unabridged/motion). Disclaimer, maintainer, but the comparison is much closer.

gls2ro 6y ago

> Ruby needs new blood infused into it. yes, I strongly agree with this, specially when talking about Web tech. I am programming in Ruby (and Rails) for over 12 years and I think I had the same feeling up until a couple of years ago that it become a stable system where I could move quickly and create new products but did not have so much newness. But now I see at least two things which makes me love even more this ecosystem: 1. Stimulus JS along with StimulusRelfex https://docs.stimulusreflex.com/reflexes https://docs.stimulusreflex.com/reflexes 2. ViewComponent https://viewcomponent.org https://viewcomponent.org And now I discovered this Matestack. I am excited because Ruby on Rails is a technology I know very well and I was (and still am) a little against moving to full SPA and adopting a JS framework for frontend. Somehow the SPA felt to me a little unstable in general, when compared with SSR. This unstable I think was mostly due to being very hard to debug real production issues. It might be from the way debugging worked in the beginning not showing proper line of code where the JS error was, or it might be because of my own resistance to change. But now with these new tools added to the Ruby eco-system I can make the web interface more responsive and in the same time feel that I only add stable components into an app.

arcturus17 6y ago
Can't tell what your SPA experience has been, but in my experience React with a standard webpack configuration such as what you get with create-react-app provides an extremely detailed trace. Never felt like I've lost more time than I should there.
- gls2ro 6y ago
  Probably nowadays React with webpack provides a stable experience. It might be that my impression of SPA is also based on my resistance to dedicate time to learn the new tools. Usually I want to start doing stuff and then go back and read more. This is why I say it felt that way and I did not say that the SPA is unstable. Here is how my experience with SPA looked like: - I started with jQuery, 10 years ago or so (actually with Scriptaculous :) ), replacing parts of the interface with Ajax calls. Worked a little for a while then got into very ugly code both on JS and on Ruby. This was not a full SPA, but it was moving into that direction. - Then I moved to Backbone around 2013 I think. In the beginning it sounded very nice in the end again the code and mix with jQuery quickly become hard to organise. Also as it started to be slower to build MVPs in terms of moving fast and adding application features. - So I tried Angular and my main problem there was debugging production issues. The errors I saw on browser console were mostly not giving any clue about what went wrong. Probably it was because of the whole compile JS pipeline to support various browsers ... - Then I inherited a Webapp written in React (around 2014 or 2015) with backend in Rails which was a second-screen for a radio show. It provided various live interaction with listeners. There I saw the need for SPA but also is where SPA lost me as I spent a lot of time debugging simple things from someone could not be able to login to how long it took to add a new page to display some poll results. For sure a big part (or the most part) is on me and with my expectation about how things were working in Rails where if I wanted a page to display some poll results it meant to simply build a .html.erb and it was done. Of course later on came Action Cable and I started using it for any live thing. Again I am not saying SPA is in general heavy or hard to use. I am saying that for the products I build SSR sprinkled with some small reactive things is enough and for me (when I am mostly the solo developer) it is fast to produce (from idea to deploy) and debug a feature for a web app. That being told I am trying to learn Vue - and force myself to use so that I want to have experience with this kind of frameworks.

rektide 6y ago

alas for rails, a very very large percent of it's simplicity & adoptability were derived from it being so so so so server side based. useful for making an easy to use opinionated framework. but ultimately, expectations moved on. rails has continued finding it's way, trying to find a rails way to do things, but without that original simplicity, it's not nearly as compelling a sell. no one's done a particularly good job keeping a more server-side biased model. thicker clients keep winning & winning. I don't think it has to be this way, but it's going to take some soul searching & big up front bold vision & architecture to muster to the challenge & create a more balanced client - server relationship. not a ton of obvious winners hereabouts! but I believe!

Lio 6y ago

I’m actually quite bullish about Rails for the fitst time in a while due to StimulusRelex[1]. It’s a similar approach to Elixir’s Liveview and provides reactive, diff’d partial updates streamed over a websocket. This seems a very “now” approach to building webapps. 1. https://docs.stimulusreflex.com/ https://docs.stimulusreflex.com/

te_chris 6y ago
Cool that people are doing a live view type thing in Rails, but it introduces a lot more complexity without the BEAM
joelbluminator 6y ago
> streamed over a websocket That's my problem with this approach, I wonder what the penalty is (performance and complexity wise) for going that route. What is it using for websockets btw, Action Cable?
- ksec 6y ago
  >What is it using for websockets btw, Action Cable? And that is a problem because by default Action Cable isn't scalable. You cant get it work by 100 - 200 connection and response time are very slow at 50ms+ and a lot higher at 95th percentile. AnyCable helps a lot but this is another pieces of complexity added to the system. Not a problem for Elixir and BEAM when they are sort of built for these type of workload. Although I am waiting for all the Fibre, Async and Ractor addition to Ruby 3 and see how they add fit in.
  - joelbluminator 6y ago
    > AnyCable helps a lot but this is another pieces of complexity added to the system. What is the added complexity? I honestly never used all this stuff.
maxthegeek1 6y ago
Neither Elixir Liveview nor StimulusReflex are really viable longterm, especially for mobile web. The idea of chattily streaming UI changes over the network doesn't work out for mobile web, where networks are frequently unreliable if not totally inaccessible.

rolae 6y ago

Rails has very much embraced webpack and different ways to build SPA on it, with providing an API only mode and easy install webpacker install commands. Maybe for an oppinionated framework it now offers too many ways to do the frontend. But more importantly, Rails is still insanely productive to work with. And with gems like stimulus_reflex and matestack you can get reactivity easily without having the complexity of full blown SPAs.

monkin 6y ago

I still prefer the good old “build stuff in rails” (which change a lot, something you don’t really know) over build everything in JS. Which is mostly popularized by new kind of programmers breed who learned everything purely from YouTube. They don’t know their tooling, systems, how web apps works, make huge mistakes on each level. Just putting the one solutions they know in everything. Do they think about what they doing and if this approach is feasible? No, not at all. It’s like with Wordpress, everyone is using it because of popularity, but WP is a nightmare to work with, and most of the time a huge overkill for what’s intended. I will not even mention Gatsby and super simple websites made in React because of it... > It's really unfortunate because Rails is such a brilliant framework, and Ruby such a lovely language, and they're falling out of the mainstream and losing popularity because of this. I wish the community would re-align. And this, this is just outrageous. Do you have anything to back this claim up? I’m not rails/ruby developer, but it always irked me when someone’s saying such thing about any language. Don’t get me wrong, JS is awesome, React/VUE on top of it too, but the point is, to know when and how to use them.

matthewmacleod 6y ago
Which is mostly popularized by new kind of programmers breed who learned everything purely from YouTube. They don’t know their tooling, systems, how web apps works, make huge mistakes on each level. Just putting the one solutions they know in everything. Or—bear with me here—it’s possible that everyone other than you actually isn’t an idiot and there are issues that you are neatly stepping over with this patronising nonsense.
- monkin 6y ago
  Oh, wow a personal attack! I didn’t want to offend anyone, but you somehow feel attacked. Either way, have a good day. :)

masa331 6y ago

I think it's quite the contrary. Rails integrated Webpack a long time ago in it's basic installation so if you do `rails new my_cool_app` you have Webpack ready(and preconfigured with React/Vue/Elm etc.) right out of the box. Also it moved away from Coffeescript and jQuery. And for the full page reloads, which you think is weird, there are Turbolinks(again preconfigured in the basic install) since like 2012. I'm not sure React or other reactivity foos already existed at this time. And now we have things like Stimulus and Stimulus Reflex and others so the development ain't stoping now either. So the feeling that Rails are stuck or out of date is really only a feeling.

tarsinge 6y ago

MVC full page reload are fine with turbolinks and can deliver a better user experience (at least that’s what I get from my clients). The issue for me is more philosophical: JS is still not acknowledged as part of the view, the mindset is still stuck at the separation of concerns = separation of technology era. I’m not doing SPAs, but I’m not doing Web 1.0 pages either. I have views where tightly coupling JS is the sound choice, because well, the JS is really a part of that view (e.g. a data visualization). But for that Rails makes me juggle between two different apps for the same view (even worse with webpacker).

vinceguidry 6y ago

Christ. It did keep up. Every new rails release just makes it better and better. Rails isn’t popular anymore because people followed the swan song of language isomorphism overlooking JavaScript’s deficiencies. NodeJS improved by... adding Rails features. It’s amazing that people think there’s more to this story. It was Node that couldn’t keep up with Rails. No one cares cuz they didn’t want to learn ruby.

aerovistae 6y ago
I don't really see too many companies or projects using node on the back end. It's pretty hard to buy that node replaced rails. I see a lot more Java than anything else.
- jozzy-james 6y ago
  i think it really depends on the industry - mine for example, most of the bigger players are running express apps on the FE (not 100% sure on backend, seems a mix of go/node and other things) - but why bother to run express/node on the frontend if you're not also going to leverage it on the backend.
- cutler 6y ago
  That's because Java is one of the top 3 adopted languages and is general purpose. A more relevant comparison would be between Node.js and Django, Rails or Laravel and as far as job stats go, eg. https://indeed.com https://indeed.com, Node.js is everywhere.
- pdoub 6y ago
  A lot of companies I'm speaking to (mostly Berlin/Germany based startups) have drank the "we have to use JS on the frontend anyways, and by going fullstack JS we can reduce our payroll since we can focus on only hiring JS devs and they magically work on ReactNative, the React web app and the Node.JS backend at the sime time" koolaid. Works super well for some, less so for others... Edit: Explicitly added Node.JS since that's what they rave about for making it possible.
Existenceblinks 6y ago

Fire-Dragon-DoL 6y ago

Well, realistically, rails is a bad choice for a json rest api. As for everything else you said, it is doing that as far as i'm aware. Webpacker it's a thing.

grumple 6y ago
Is it? It has an api mode and I’ve used it extensively for that at multiple workplaces and projects.
- Fire-Dragon-DoL 6y ago
  Yes but at that point you are getting all the disadvantages of Rails, without the strong points (fast prototyping and everything related to rendering HTML pages, file uploading etc.). Presuming you wanted to stay in Ruby for the API and wanted to stay in a project similar to Rails (so, preserving ActiveRecord), Roda + ActiveRecord gets you there with already much higher performance. If you think about it, a JSON API needs very little. Rails has a lot of added complexity for just rendering JSON. Even the sheer amount of files a Rails project has by default is enormous for something that simple.
  - grumple 6y ago
    > Yes but at that point you are getting all the disadvantages of Rails, without the strong points (fast prototyping and everything related to rendering HTML pages, file uploading etc.). Your perception of the strong points of rails are very different from mine. The strong points include rapid data and logic modeling, json serialization (jbuilder), robust libraries for user management (devise) and many other things, built-in security, routing logic, easy testing, and meta programming. You still get rapid prototyping in api mode, with a rails generate scaffold quickly capable of creating tables and a json rest api for that resource in a single line with no additional work necessary (assuming you had no business logic, which is generally easier to write in ruby as well).
    - Fire-Dragon-DoL 6y ago

treis 6y ago

The problem I have with Rails is that it's not a complete solution. You can use the generators to scaffold a bunch of stuff but those pages have no CSS and lack basic javascript like dynamically adding a row to a form. I don't think they need to go all the way to something like react. But a souped up Turbolinks where you can also easily do partial rerendering of pages would be enormously helpful. The barrier for entry into doing anything is still Rails + Bootstrap/Tailwind + webpack/yarn/npm. Which is a lot more than just whipping some stuff up in rails.

tomc1985 6y ago

We come from dramatically different perspectives because building page-reloading MVC still feels fine, as fine as it ever did. And Turbolinks is Rails' answer to the madness that is JS frameworks. You get a lot of the functionality of a single page app while still keeping the much-easier-to-code-for serverside rendering I am very happy I don't have to touch JS frameworks if I don't want to. Because I hate all of them (except Vue and jquery, they're cool) Rails isn't for trendy hipster JS kids, and I hope it never will be. I don't want those people in this space, they fuck everything up