1. 17
  1.  

  2. 6

    I don’t think this is curmudgeonly at all – I think this is a good attempt at rising above and offering a sane viewpoint. We need more of this. I would go even further and say that developing an SPA is largely a waste of effort. The whole SPA pattern was created by Apple (via SproutCore) so that they could recreate a desktop-like experience on the web, and once Ember came out, the idea seemed to spread like wildfire. I understand why you might want this if your target is mobile, but the web works just fine! It’s way more versatile than native apps and we should be embracing this instead of trying to emulate whatever eye candy Apple or Google cooks up. I mean, I guess it’s nice that people are taking the frontend more seriously these days, but why would I want to throw away everything I know every two years when someone decides that the current way of doing things is shitty and comes up with a shiny new way of doing things? I feel like everyone’s following the bandwagon, trying to one-up each other along the way, but they’re all too drunk on new technology to realize that no one is driving the damn thing and before we know it we’re all going to end up in a ditch somewhere.

    At the end of the day, our job is to write code as fast as possible, that works as well as possible for whatever platform we’re targeting, that doesn’t make us want to kill ourselves. To me, whatever stack gives me the best tools for doing that wins.

    1. 6

      The author glances off some good ideas here (if you can get past the presentation) but I feel they come to the wrong conclusion. The conclusion seems to be “use rails like we did in 2006” with some other backing service(s). I really wouldn’t fault anyone for choosing this path especially if they don’t have a lot of modern UI experience but personally I’ll be sticking with my Universal React application (and mobile, etc UIs) which fetch from a GraphQL endpoint.

      1. 11

        The way I’m suggesting to use Rails is completely different to what it was in 2006. Back then, they were the full stack, the database, logic, templates, etc., all went into the same package. What I’m proposing now is to just use Rails as the replacement for a SPA, while still keeping the back-end and front-end separation in place. The reason for this is that full-stack frameworks can offer a more pleasant developer experience (if you get rid of the cruft) compared to Gulp/Webpack, which is hell.

        The point is, there’s an alternative to the current JS-React-Universal-SPA horror show, just because they aren’t making headlines, they aren’t stuck in the stone age. I’ve been developing quite nicely using a Scala backend and Rails frontend that uses Her to call the REST API and react-rails to render the UI using React and TypeScript. Granted, there are some non-AJAX calls here and there, and it won’t ever be as quick as a full-fledged SPA, but I have functional SEO, routing, asset pipelining, functioning dependency management, deployment, access to the Ruby ecosystem (not that JS is doing badly in that area).

        1. 6

          The point is, there’s an alternative to the current JS-React-Universal-SPA horror show, just because they aren’t making headlines, they aren’t stuck in the stone age.

          I respect your opinion of gulp/etc, but it’s disingenuous to call it a horror show. You really aren’t making any points against Universal JS apps and while I respect that your experience with Universal JS was poor that is not everyone’s experience.

          What I’m proposing now is to just use Rails as the replacement for a SPA, while still keeping the back-end and front-end separation in place.

          I agree that having a dedicated UI server is a good idea in many cases (in fact, it’s the same architecture I take in my Universal JS apps).

          …I’ve been developing quite nicely using a Scala backend and Rails frontend… Granted, there are some non-AJAX calls here and there, and it won’t ever be as quick as a full-fledged SPA, but I have functional SEO, routing, asset pipelining, functioning dependency management, deployment, access to the Ruby ecosystem (not that JS is doing badly in that area).

          I would have liked to read more about your modern Rails/Scala setup in this post. Honestly you could probably have cut out the entire history lesson part and just focused on why Scala/Rails is an awesome combination for modern web dev. I also encourage you to look into GraphQL as a replacement for REST for communication between your UI and backend. There’s a quite nice Scala implementation: https://github.com/sangria-graphql/sangria

          1. 1

            I would have liked to read more about your modern Rails/Scala setup in this post.

            Yeah, I’m working on an example that does what I mentioned.

            Honestly you could probably have cut out the entire history lesson part and just focused on why Scala/Rails is an awesome combination for modern web dev.

            Yeah, uh, about that. I needed something to put the solution into context, perhaps the execution wasn’t the best possible.

            I take it you are using Sangria? What are your experiences?

      2. 3

        I did this style for years. Separate frontend and backend with an API between them, but the frontend in a conventional server-side web framework with stateful user sessions (Wicket).

        It works, but the performance is never going to be quite as good as having the state and UI logic on the client side.

        1. 2

          A lot of this depends on what your site/app is actually doing. Do you need SEO value? If so, you probably want to render something server-side. Don’t need it? Great. Every page has one html template and you never mess with it.

          We have a very small dev team where I work (3 devs, if you include the CIO as a dev). I am the majority dev for our user-facing applications (dashboard/onboarding). The other 2 worry about different things. Our workflow might seem complex at first (especially if you were setting it up), but for new devs, all they really have to do is install node/npm, then run npm install in their cloned repo. After that, it’s a matter of running grunt and everything is taken care of for them. Save a file, it automatically does what it needs to do so you can refresh the page and see changes.

          As far as code complexity, our backend is extremely light. It has routes that point to controller functions that mess with and return data. Sometimes they return basic bootstrapping json in a template. Sometimes they return just json. There isn’t anything crazy going on with templates, though. We have 1 template that the apps use, regardless of which page you hit within that app.

          The frontend is where all the templating nonsense happens. I use Mithril because I can read through the entire source in a couple hours. It’s about 1k lines. It provides routing and virtual dom, event handling, everything I need. Simple and easy to use. Anyone with experience in an MVC framework would be able to immediately identify what is going on with the components on the frontend.

          I don’t think it’s as bad as it’s made out to be. If you chase every new tech, you’re going to have a hard time and constantly be confused. If you want to get stuff done, pick something that works for you and start busting out some code!

          As I said above, I’m still using Grunt. Yeah, everyone says it’s the worst thing ever now, a total dinosaur. But you know what? It works, it’s quick, and I’ve had zero issues with it. Should I move on because there is peer pressure to do so? When it starts failing me, I’ll move on. I don’t care what hipster devs think about the workflow. Same for Mithril. I’ve had people ask why I don’t use Angular/Ember or go into some sort of React rabbit hole. But Mithril works and it works well. It’s fast. It’s easy to use. It’s easy to comprehend. Why change it?

          There are always reasons to look at new things, you’re always going to find some hot newness, regardless of language. Web development gets hit with tons of changes (especially on the frontend) because of the vast amount of people targeting it. There is no one right way to do it, and there never will be.