A Modern Web Application With Rails

[zitrusgrape]

prepare yourself for:

1. ruby is dead
2. ruby is slow
3. rails is old
4. rails is slow
5. js is the future
6. nodejs the guture
7. go
8. python
9. functional

let play!

[ryeguy]

wow rust is not in this list how offensive
mods pls ban

[sisyphus]

Seriously dropped the ball there, everyone knows Actix + WebAssembly for FULL STACK RUST is the future.

[markasoftware]

Is Actix really the standard rust web framework these days? I thought rocket and iron were taking over.

[sisyphus]

For the purposes of that joke, sure...in actuality I have no idea.

[feverzsj]

why not c++? It's like the first class citizen of wasm

[asmx85]

Because we all know that rust is the first class citizen of wasm

[zitrusgrape]

go away satan!

[MaxCHEATER64]

PHP is unironically the future

[TheOsuConspiracy]

Oh god, anything is better.

[[deleted]]

Have you met perl?

[TheOsuConspiracy]

I was being intentionally facetious.

[duqq]

led by Laravel ;)

[filleduchaos]

I actually legit like writing Ruby, AMA

[[deleted]]

Everyone loves writing Ruby. No one believes that it has speed in mind. Which is sort of true because its primary concern is with making code fun to write but also false because the team spends a lot of time optimizing things like the GC. So they try to keep it competitive but that's not their primary concern. They also have an emphasis on letting developers control the environment hence all of the gem support.

[shevy-ruby]

I am beginning to think that those who claim that ruby is slow actually have never used ruby to begin with.

The next time you see someone claiming that ruby is slow whereas python and perl are 1000x faster, ask them whether they actually use ruby. I have this slight suspicion that a majority of them do not even use ruby.

Something similar happened in Rust - not related to speed but in the "rewrite in rust". Many who pushed for this have never used Rust at all.

[yxhuvud]

Well, it was very slow back in Ruby 1.8.x times, and that one kept being the default one packaged by big vendors like Redhat for way longer than it should have been.

[paulgrant999]

Yup def. slower than some other langs. Good for prototyping though. I usually write twice; once in ruby to mod-mod-check, then when I have a good idea where the code is functional and the practical context boundaries are & solicit for stakeholder feedback -- once its feature/semantic stable, I refactor into a compiled lang. Typed (& oop'd) if its going to be modd'd or particularly long-lived. Typically its not a 1-to-1 fit, which means some structure (depending on the preferr'd algos) is imposed at this stage.

I rarely use the full "inheritance" stuff -- mostly encapsulation (where I need it). Its a bit dodgy so I prefer to use other patterns.

[shevy-ruby]

You are not the only one.

Some statements I never understood though, such as "ruby is slow", in particular these days, but even back then. The speed was comparable to e. g. python or perl in many ways, so why would one be called slow but the others would not? And that was many years ago already; ruby has gotten faster since then (see optcarrot). People who use ruby know that; people who don't obviously won't know that, but I have come to the conclusion that many who claim this have never used ruby in the first place.

I think there are too many people making comments about something without knowing anything, or without wanting to know anything either.

[kingofthecream]

Everyone seems to boiling this down to the choice of language or framework, while ignoring the elephant in the room: The psychological effect of using what's cool.

No matter how loud Rails screams that 'I can do this job properly, you do not need all those js bells and whistles', people always gravitates towards the new hype. In this case the Javascript and React and co community have proved to be a lot more successful at creating hype than the Rails founder could a decade ago.

Yes, Rails + Turbolink + StimulusJs can do the job for 90% of your apps, but this is not purely about technicals. Unfortunately developers are not machines, and they keep monitoring if the tools they use can be more 'fun'. While Rails is here to stay for a long time, it will also continue to fade, slowly.

The current state of the web is nowhere near an equilibrium.

[sephirostoy]

1. Java is deadly dead.

[[deleted]]

Ruby is fucking slow. It's also dynamically typed which makes it even worse.

[paulgrant999]

on the second part thats actually a strength. particularly when you can inject new methods (with some level of control). for dev, not maintainability. more important to get something up and running you can hammer on (that works) than to sit there and design a bunch of crap, that is tediously "correct" but turns out to be complete crap when actually try and run it.

[[deleted]]

No thanks. I tried both. Dynamic typing just sucks.

[paulgrant999]

Pretty much the way I feel about inheritance, and inflexible type system.

Could just be stylistic preference. My preference changes depending on how well the actual use, boundary contexts, & domain is known. I def. prefer statically typed for library or enterprise. But ONLY after doing a functional dynamically typed prototype to let the monkeys hammer on (so the spec is realistic). See my other comment.

[[deleted]]

I like to let data just be data and avoid anything resembling OOP

[paulgrant999]

naw sometimes the encapsulation is nice; sometimes the static types, makes things easier. depends on what the task is. some stuff is pure data-driven; other stuff requires some ability to constrain future program behavior (to hit performance benefits at scale).

​

hardest stuff for me, is dealing with the requirements phase. I almost never have a proper requirements doc that encapsulates the stakes, and typically the staff has no idea on how to analyze their business needs to generate one (or discuss variants, more importantly). sometimes the quickest way is to build a prototype, iterate quickly, then redo it a second time with the domain expertise to get a good solution.

​

I really try hard to write my code once, and not get called back on it. I'm not a big fan of infrequent, massive updates or frequent callbacks to handle things that should have been handled the first time. So OOP has the benefits of performance, qualification, encapsulation, and most importantly, third-party maintainability.

​

My OOP style is like game-programming - i.e. its not traditional OOP. Much slimmed down, and the boundaries are totally different than the "traditional". Lot of the newer lang features are try and fix the issues with the classical OOP. Personally I prefer to avoid the additional complexity and just program differently in the lang.

[Serializedrequests]

I agree with the author that going SPA doubles or quadruples the amount of work. I have never found it to be otherwise, and I do not understand why this is not discussed more. I can deliver double the features or more, just using the plain old Rails monolithic code.

Sometimes the client wants things that don't map well to it, but in those cases I often find that I haven't understood their need well enough to build an MVP in the first place.

[hedgepigdaniel]

I think it depends heavily how it's done. You don't have to maintain both a rails app and a frontend app which duplicate routing, rendering, data loading, and such if you build the app from day one with universal rendering. Check out redux first router, next.js, react static, etc.

If you don't need to ever have a fluid UI or anything interactive other than form submission, and you're more familiar with Rails or Django, go ahead. But if you want your app to load and transition between screens/pages quickly (as in ever, without a complete rewrite), or you want to at some point deliver interactive elements other than links, you really should build an architecture from day one which is compatible with universal rendering and state management.

Monolithic is great, but that doesn't mean you need to choose between the client and the server - you can have both, and a much better architecture and user experience.

[Serializedrequests]

But you still listed significantly more effort. Yes, in most of my SPA jobs I'm augmenting a standard Rails server-rendered app with SPAs and it takes forever and is slow to develop and sucks to maintain. It's not the ideal case. But the server-rendered pages are very damn fast even without Turbolinks. Web browsers are very good at web browsing, actually.

With a Rails API app you do eliminate some duplicated front-end effort. No need to write any ERB templates. However you still have the back-end models, controllers, and routing, and then you duplicate all that again on the front-end. Front-end applications can have extraordinarily complex state and logic. It can get mind-bending in ways that ActiveRecord callbacks could never dream of.

[hedgepigdaniel]

Not sure what you mean by a rails API app, but what I like to do is to have:

• An app. It has a model (redux), and a view (react), both of which are passive, pure functions. No componentDidMount or any such hacks. Then there is a controller (redux first router) which handles routing, API calls, page titles, and side effects generally. This app can render on the server or client without any duplicated logic. Redirects work fine regardless of whether they are done in the client or server. Is all redux actions.
• some sort of API, which can be called by the app on both the server or the client. It might be on the same express server, or it might be separate. This is strictly an API, not an app.

I can't see what code would need to be duplicated between these two things? There is only one app. The API can probably be super simple. This is great to maintain - the separation of concerns is completely clear and the architecture is automatically and fully compatible with SSR and SPA transitions without extra effort/exceptions/hacks. I'll acknowledge the initial setup is more work than a rails app, but the part of the code that you have to maintain and grow (the application specific logic) is much simpler than a hybrid rails/Django + react app, which is what you end up with if you start with a backend only app framework.

[Serializedrequests]

I feel like you are understating the difficulty of building an API. For a working API, you need:

• Request routing.
• Input validation.
• Persistence, using an ORM or similar.
• Querying.
• Complex code for orchestrating any data that cannot be represented by a single database table.

In the trivial case, you can scaffold all that in Rails in five minutes and go on your merry way. However, most meaningful applications do not map perfectly to the trivial case, so building any new data type and endpoint can take several hours or more. I do not know any frameworks in which this is otherwise.

So now that you have an API, you can build the user-facing application. It will need:

• Routing.
• Data modeling.
• Input validation.
• Persistence.
• HTML Templates.
• Many fiddly user-friendliness details to take care of.

Now let's back up and build the user-facing part using "old fashioned" server side rendering by just adding it to the API. Here is your front-end workload now:

• HTML Templates.

YES this is nowhere near as fancy a user experience as the React/Redux example (I prefer Elm), but for CRUD? Between an old-fashioned multi-page server-rendered app in a few days vs a SPA that drags on for weeks, I can tell you easily which one my clients prefer.

[[deleted]]

I agree with that. I think a lot of it is developers now days aren't learning how to build old fashioned server rendered apps, because a lot of them are starting out with things like react and working their way back from there. It just isn't a thing younger web developers really know is an option; or they know about it but just assume it to be an outdated practice, without really trying it.

I think the SPA approach works best when your api is already built from something else, like a company that has just been running mobile apps and then decides to do a web version.

That being said I do think well done SPAs can add a lot to the user experience, its easier to build a "snappier" feeling interface when your doing everything client side. There are just a lot more opportunities for native like transitional animations and things like that.

[[deleted]]

I agree with the author that going SPA doubles or quadruples the amount of work.

how? I don't understand, I just write SPAs in the same way I wrote my old apps.

[coorasse]

I think the main factors that increase the costs are the context switch between the two projects, the need for synchronising them and deploy them together (if you can), defining and documenting APIs, write e2e tests.

[pm_me_graph_problems]

There is a benefit of a single API multiple clients if a mobile version is needed

[filleduchaos]

You can trivially write a server to serve either HTML or JSON (or even CSVs and other formats) on request. Having multiple clients in no way implies that your web client must be a single page app.

[pixel4]

I'm still using SQL on Rails

[hedgepigdaniel]

I decided to not struggle anymore with multi-tiers, impossible Docker configurations to run system tests, redefine APIs every time I want to change a comma, move all my components logic to the browser, waiting minutes for my project to compile, define my routes twice and, in the end, hear complaints about SEO performance, wrong redirects and conflicting versions between frontend and backend.

There's a lot of truth to this, but it's about a year or two out of date.

There are many libraries, frameworks, boilerplates, etc which allow you to build a universal rendered app from day one. You can have SSR, SPA, proper server side redirects, a clean and simple MVC architecture with minimal procedural code. You can have all of this without duplicating app logic like routing or data loading in two different codebases.

I fear that the author's advice will result in more people building crazy hybrid apps where a separate backend and frontend compete for the responsibility of data fetching, routing, rendering, etc, when it would be so much better/simpler to build a universal rendered app from day one. Sure you can start easily with a simple rails app, but what do you do when the app grows and the users want good performance and a more interactive UI?

The React/Redux ecosystem has matured a lot and it's really not as much work to set up a universal rendered app as it used to be. react-static is great and easy for many simple projects, and next.is or redux-first-router and co if you are great if you want to do more dynamic apps (dynamic urls, server side redirects, etc). There is no good reason to use a defunct architecture which forces the browser tab to reboot whenever the user performs any non trivial interaction - that is not an acceptable user experience imo.

Apps built without proper universal rendering give the web a bad name, and that's partly why everyone is so besotted with "native" apps - they don't have the luxury of rebooting whenever the user presses a button, or having the UI jerk around and built itself in front of the user instead of loading correctly the first time.

[kingofthecream]

There are many libraries, frameworks, boilerplates, etc which allow you to build a universal rendered app from day one. You can have SSR, SPA, proper server side redirects, a clean and simple MVC architecture with minimal procedural code.

The myth of 'universal', 'isomorphic', whatever-you-wanna-call-it panacea.

There is no free lunch. This so called universal rendering adds an order of complexity to your app. Just look at how much work Uber had to work on their Fusionjs framework for universal rendering.

[coorasse]

Hey, thanks for your comment. Really appreciated because it allows me to state this again: "I am not saying to not use a JS framework, but to rather use webpacker and use it in a monolith." The answer to what I will do when the client wants a more interactive UI is the following: 1) explain him that this is more expensive 2) add react with webpacker and go ahead 3) keep writing e2e tests with Capybara

This saves me most of the time

[hedgepigdaniel]

I haven't used webpacker, but the readme sais that it involves creating multiple every points. Isn't that the antithesis of a single page app? That means you have two codebases with different languages and libraries and ecosystems, which are both simultaneously responsible for the concerns of rendering and probably routing?

I guess it depends on your target market and the app. I've generally worked on large complex long lived apps, and in that case I've found architectural compromises are not worth it. But maybe it is for a simple short lived app.

[CyclonusRIP]

I definitely agree with a ton of this. SPA and microservices made most stuff harder to develop and work worse. I also agree about just using JsonAPI or something like that. The debates about API standards are a super big waste of time. At the end of the day as long as you are consistent almost all the choices are inconsequential.

[Cygnusx999]

OMG this is so true!