7 ms·

I went from MVC style all-in-one frameworks (Rails, Laravel) to application APIs fronted by single page applications and hope the developer mindshare tilts back

I went from MVC style all-in-one frameworks (Rails, Laravel) to application APIs fronted by single page applications and hope the developer mindshare tilts back to MVC frameworks. Something that'd take me an hour or two in Rails can take a week using these new tools, even after being reasonably experienced with them. Don't even get me started on Apollo (not my thing at all, and from my experience most don't know how to use it well, including myself). Most apps are fine serving html, using plain old boring forms, and having the odd React or Vue component where necessary to do some heavy lifting for user interactions. Moreover, it's a lot quicker as a small team to iterate.

korm 8y ago
I hope we don't go back to MVC for everything. I think we just have to use the right tool for the job. If an app is highly interactive or will have frequent data updates, or if it's supposed to be used almost like a native app, a SPA is the perfect way to achieve this. If it's going to be like most sites, traditional MVC will probably be better. Not that react isn't great for traditional websites, I've just seen too many fullstack or backend devs struggle with it, so if they're going to be involved in the frontend it may be worth considering the alternatives.
- arcticwombat 8y ago
  SPA isn't automatically the best solution for a page or site with frequent updates. The updates are handled by JavaScript and http calls. You can write a lot of that stuff in a dozen lines of JQuery with nicely refreshing content and ajax instead of throwing in large amounts of framework bloat.
  - onion2k 8y ago
    jQuery 2.1.3 is 27.8Kb. React + React DOM is 35.6Kb. 7.9Kb extra isn't nothing, but it's not something many sites really need to stress over. It's definitely not enough to state using React is adding "large amounts of framework bloat".
    - arcticwombat 8y ago
      I'm not talking about the bloat of the framework itself but the code you write to use the framework. When you have 2mb worth of "React code" and the framework itself only takes up 35.6kb, that's a lot of bloat.
      - masklinn 8y ago
        If you have 2mb of "react bloat" you wouldn't have "a dozen lines of jquery".
        deleted 8y ago
        [deleted]
      - Klathmon 8y ago
        2mb is a LOT of code, like an absurd amount for most projects. That almost always points to larger issues, like a complete disregard for bundle size in the first place. And if the project isn't worrying about bundle size at all, then even their vanilla/jquery page is going to end up bloating a ton as well. More often than not the culprit in 2mb bundle sizes is a a few packages that include "data" in the bundle (For example, i've seen timezone and locale information bloat bundles by megabytes, and in one case a 5mb bundle ended up being 4.6mb of zip codes...)
        braindouche 8y ago
        Yeah, that was me, sorry. I wasn't given a choice.
        Klathmon 8y ago
        lol I did it too once! We were making a PoC one time for a small app, and ended up needing a way to quickly determine some location information related to the zip. I remembered that I saw the ~5mb bundle once that had all the zipcodes in it, and found a library that would let me do that, and bundled it right in. The PoC ended up working out, and we built the infra to correctly handle the lookups without needing to bundle the entire country from there, but man did that raise some eyebrows from a few other devs that noticed it!
  - masklinn 8y ago
    > You can write a lot of that stuff in a dozen lines of JQuery with nicely refreshing content and ajax instead of throwing in large amounts of framework bloat. OTOH jquery is much bigger than you'd expect, there isn't much of a difference between a minimized jquery and vue, or even react once you factored in gzip. And while I've no experience doing so using vue, writing small dynamic react components embedded in larger static HTML pages is quite enjoyable.
    - seba_dos1 8y ago
      It's 2019, most of the stuff that jQuery used to handle is now included in the browser API. For instance, to have "AJAX", simply try window.fetch instead of $.get.
      - vertex-four 8y ago
        Then add a polyfill per api call to support anything but the most recent browsers, if you happen to want your site useable by people with old systems or who are at work.
        seba_dos1 8y ago
        ...which you can selectively serve only to the old browsers :)
        piker 8y ago
        That sounds trivial.
    - deleted 8y ago
      [deleted]
tobr 8y ago
For a component here and there React is a pretty bad choice because of its size. Svelte could be a more suitable option, but I’m not so sure it passes the magpie test.
- deleted 8y ago
  [deleted]
- pault 8y ago
  In my experience this is the use case where vue shines. It's far easier to drop it into an existing html template than to create a react application for a single component.
- dwaltrip 8y ago
  Magpie test? I couldn't find an answer on google.
  - tobr 8y ago
    The article has a reference and link to [1], where the behavior of constantly looking for new and shiny tech is likened to that of a magpie. As Svelte is still fairly new and not widely used, I think maybe it is in that class of technology. 1: https://blog.codinghorror.com/the-magpie-developer/ https://blog.codinghorror.com/the-magpie-developer/
    - dwaltrip 8y ago
      Makes sense, thanks!
quest88 8y ago
I recently started a hobby project and initially went with a JS solution. But when I had to start deciding on auth, maybe an orm, routing, db layer, and templating, I said fuck it and installed Rails. Previously I had never built a real product in Rails, only the book store tutorial. I'm really happy with Rails so far. I don't have to worry about a lot of shit I had to worry about in JS land and now I can focus on the app itself.
- lucidone 8y ago
  This is my experience as well. Sometimes the conventions are frustrating, and particular to Rails I still don't know how to handle the front end well aside from jQuery (how are you doing it? Stimulus + Turbolinks, or...?), but is it ever refreshing to just focus on your product instead of all the tooling surrounding developing your product.
  - freehunter 8y ago
    If you need a lot of JS, Vue is a nice choice. You can drop it in for just a single page of your site if you need heavy JS on one part but still want Rails on the rest. Or you can go full-on Vue front end with Rails in API mode, or anywhere between.
- wlll 8y ago
  As you're doing Rails I recommend you check out Stimulus JS (https://stimulusjs.org/ https://stimulusjs.org/). I've installed it in a recently project (Rails 6, rake webpacker:install:stimulus) and it's like a breath of fresh air. Totally gets out of your way, but lets you add behaviour to your app as you need it.
  - mike1o1 8y ago
    Agreed. Stimulus has been great and very refreshing. I love writing my html using erb templates, and being able to do that and easily add client side interactivity has been great!
- Jedi72 8y ago

korm 8y ago

I hope we don't go back to MVC for everything. I think we just have to use the right tool for the job. If an app is highly interactive or will have frequent data updates, or if it's supposed to be used almost like a native app, a SPA is the perfect way to achieve this. If it's going to be like most sites, traditional MVC will probably be better. Not that react isn't great for traditional websites, I've just seen too many fullstack or backend devs struggle with it, so if they're going to be involved in the frontend it may be worth considering the alternatives.

arcticwombat 8y ago
SPA isn't automatically the best solution for a page or site with frequent updates. The updates are handled by JavaScript and http calls. You can write a lot of that stuff in a dozen lines of JQuery with nicely refreshing content and ajax instead of throwing in large amounts of framework bloat.
- onion2k 8y ago
  jQuery 2.1.3 is 27.8Kb. React + React DOM is 35.6Kb. 7.9Kb extra isn't nothing, but it's not something many sites really need to stress over. It's definitely not enough to state using React is adding "large amounts of framework bloat".
  - arcticwombat 8y ago
    I'm not talking about the bloat of the framework itself but the code you write to use the framework. When you have 2mb worth of "React code" and the framework itself only takes up 35.6kb, that's a lot of bloat.
    - masklinn 8y ago
      If you have 2mb of "react bloat" you wouldn't have "a dozen lines of jquery".
      - deleted 8y ago
        [deleted]
    - Klathmon 8y ago
      2mb is a LOT of code, like an absurd amount for most projects. That almost always points to larger issues, like a complete disregard for bundle size in the first place. And if the project isn't worrying about bundle size at all, then even their vanilla/jquery page is going to end up bloating a ton as well. More often than not the culprit in 2mb bundle sizes is a a few packages that include "data" in the bundle (For example, i've seen timezone and locale information bloat bundles by megabytes, and in one case a 5mb bundle ended up being 4.6mb of zip codes...)
      - braindouche 8y ago
        Yeah, that was me, sorry. I wasn't given a choice.
        Klathmon 8y ago
        lol I did it too once! We were making a PoC one time for a small app, and ended up needing a way to quickly determine some location information related to the zip. I remembered that I saw the ~5mb bundle once that had all the zipcodes in it, and found a library that would let me do that, and bundled it right in. The PoC ended up working out, and we built the infra to correctly handle the lookups without needing to bundle the entire country from there, but man did that raise some eyebrows from a few other devs that noticed it!
- masklinn 8y ago
  > You can write a lot of that stuff in a dozen lines of JQuery with nicely refreshing content and ajax instead of throwing in large amounts of framework bloat. OTOH jquery is much bigger than you'd expect, there isn't much of a difference between a minimized jquery and vue, or even react once you factored in gzip. And while I've no experience doing so using vue, writing small dynamic react components embedded in larger static HTML pages is quite enjoyable.
  - seba_dos1 8y ago
    It's 2019, most of the stuff that jQuery used to handle is now included in the browser API. For instance, to have "AJAX", simply try window.fetch instead of $.get.
    - vertex-four 8y ago
      Then add a polyfill per api call to support anything but the most recent browsers, if you happen to want your site useable by people with old systems or who are at work.
      - seba_dos1 8y ago
        ...which you can selectively serve only to the old browsers :)
        piker 8y ago
        That sounds trivial.
  - deleted 8y ago
    [deleted]

tobr 8y ago

For a component here and there React is a pretty bad choice because of its size. Svelte could be a more suitable option, but I’m not so sure it passes the magpie test.

deleted 8y ago
[deleted]
pault 8y ago
In my experience this is the use case where vue shines. It's far easier to drop it into an existing html template than to create a react application for a single component.
dwaltrip 8y ago
Magpie test? I couldn't find an answer on google.
- tobr 8y ago
  The article has a reference and link to [1], where the behavior of constantly looking for new and shiny tech is likened to that of a magpie. As Svelte is still fairly new and not widely used, I think maybe it is in that class of technology. 1: https://blog.codinghorror.com/the-magpie-developer/ https://blog.codinghorror.com/the-magpie-developer/
  - dwaltrip 8y ago
    Makes sense, thanks!

quest88 8y ago

I recently started a hobby project and initially went with a JS solution. But when I had to start deciding on auth, maybe an orm, routing, db layer, and templating, I said fuck it and installed Rails. Previously I had never built a real product in Rails, only the book store tutorial. I'm really happy with Rails so far. I don't have to worry about a lot of shit I had to worry about in JS land and now I can focus on the app itself.

lucidone 8y ago
This is my experience as well. Sometimes the conventions are frustrating, and particular to Rails I still don't know how to handle the front end well aside from jQuery (how are you doing it? Stimulus + Turbolinks, or...?), but is it ever refreshing to just focus on your product instead of all the tooling surrounding developing your product.
- freehunter 8y ago
  If you need a lot of JS, Vue is a nice choice. You can drop it in for just a single page of your site if you need heavy JS on one part but still want Rails on the rest. Or you can go full-on Vue front end with Rails in API mode, or anywhere between.
wlll 8y ago
As you're doing Rails I recommend you check out Stimulus JS (https://stimulusjs.org/ https://stimulusjs.org/). I've installed it in a recently project (Rails 6, rake webpacker:install:stimulus) and it's like a breath of fresh air. Totally gets out of your way, but lets you add behaviour to your app as you need it.
- mike1o1 8y ago
  Agreed. Stimulus has been great and very refreshing. I love writing my html using erb templates, and being able to do that and easily add client side interactivity has been great!
Jedi72 8y ago