> if the modern equivalent of Rails already exists, please let me know!
You're in luck. Rails 5.2.3 was released 20 hours ago.
More seriously, I feel rails is still excellent and I'm happy to work with it every day. I'd be interested to hear more about what makes rails not modern? I find it a very productive framework.
EDIT: If you're talking about missing a JS equivalent of rails, do you know about Loopback? https://loopback.io/
I know this is the opposite of what you asked but I find Rails to be keeping pace with modernity much better than its conemporaries! Django seem to have given up on integrating websockets (ActionCable has been in Rails for literally years now), nor is there trivial integration for JS assets/asset pipeline functionality. I don't write much of either anymore, but I'd still reach for Rails the instant I need to get something done quickly.
And with django-channels (https://channels.readthedocs.io/) Django goes way beyond just WebSockets. You can now do fully asynchronous data processing pipelines.
I'm still happy working with Django (which is not something I can say about the JS ecosystem). Especially when doing APIs with Django REST Framework.
Fully agree with you - been in the JS world a lot lately and it's not as polished as the more 'traditional' web frameworks.
Channels was supposed to make core but never did - what happened there? That's what I was driving at really - if I were stewarding a modern web framework, I would be integrating websocket support. It never sat right with me that something as common as APIs is farmed out to a library in Django (this comes out of the box in Rails with no configuration) either.
I don't dislike Django, but I certainly find that there's a lot more messing around to get done things that I would consider pretty standard. I used the new Rails beta last week and I noticed that Webpack integration is now there - how long until we see something like that with Django?
Andrew Godwin (creator of django-channels) has recently handed over the repo to other maintainers and moved on to some role on adding `async` support to Django Core. (Channels was officially adopted by the Django project, but isn't part of the Django-core — you still have to add the package separately.)
This async support is hopefully coming within 2019. I'm super-excited about using it in future django projects.
In short, the efforts are constantly undermanned, leading to developer burnout. Andrew had since came back to pushing things (ASGI 3.0 came out last week), but it seems like he intends to focus more on the big picture (standardise async web stuff in Python) than spending time on Django specifically.
Step up if you believe you have good visions on making Django a “modern web framework”.
Django channels sounds like a great idea and I really like the conceptual step it made with ASGI, but in practice I found it to be riddled with problems.
For instance, the posix IPC implementation of ASGI is very buggy and "not officially supported". The other implementation uses Redis (so, yet another component to take care of) and is quite brittle as well. We've noticed severe slowdowns of downloading images when using the Daphne web server in development mode, many issues running out of memory, clogged queues and so on. This is also very difficult to debug, due to the many moving parts, and of course it only happens on production, so good luck trying to reproduce it locally.
For this project (which is still in production), we ended up falling back to a standard Gunicorn web server setup using traditional WSGI to handle regular HTTP traffic, and relying on channels only for websockets. For new projects, we've moved to a tiny standalone gevent-based websockets server (https://pypi.org/project/high-templar/) which we deploy next to a standard gunicorn stack. It is much simpler and much more stable. Unfortunately, it's something we've developed in-house, so if there are issues we have to fix them ourselves. There've been some problems with gevent which apparently have been fixed in the latest git repo, but there hasn't been a release since last year. So many issues....
In Rail 6 webpack (with a framework integration via the webpacker gem) is the default system for handling JS, CSS still goes through the asset pipeline though. I wouldn't be surprised if Rails 7 drops sprockets entirely.
And I have been wondering why it doesn't push the CSS to Webpack as well. There is no way in the foreseeable future that Rails could do without JS and hence Webpack is mandatory. We might as well push it as default or easily enabled / disabled via options.
It's clunky to build CSS 'packs' and it's unclear how to wire in asset helpers e.g. checksum'd file names for images. It's not insurmountable, but there is no obvious best path forward.
I saw this! It makes sense with the proliferation of front end view layers so I'm pleased that there's less work for me to do to integrate things like Vue and React. I was very late to the party with Rails but I do think it gets a lot of things right.
There may be packages in the community but the entire point of the article was highlighting the advantages of having framework level choices that 1. Are maintained by the framework team, 2. Establish patterns where the community can build other packages based on those assumptions. For example, now that yarn and webpack are standard in rails, we can build gems that can import and configure JS packages in a consistent and modern way, knowing exactly how most rails projects will manage JS. I have been frustrated that rails doesn’t have default admin, authentication, and authorization for this exact reason.
I was just teasing, Laravel looks solid. It's also comforting to know that if you move from Laravel world to Rails, a lot is familiar out of the box. It's good for us developers and good for the industry. Which I can't say about js stack/elixir/Golang/Spring etc etc.
Interesting. I always found Django so much more productive than rails due to the auto admin panel being out of the box. If I’m starting something new than its nice to have a place for non devs to enter data immediately.
Both do quite a bit better for cleanliness and setup time than any of the other platforms I’ve used for web development.
I'm interested in hearing about applications successfully using ActionCable for what and how. It's unclear to me how much use it's getting, or how well it meets actual use cases.
ActionCable is super easy to use out of the box to get WebSockets running, but it's incredibly non-performant. Anything more than 100 concurrent users took the time taken to a send a message to the socket from milliseconds to seconds. Replacing it with the AnyCable gem in conjunction with AnyCable-Go got us to over 1000 concurrent users without a hitch.
I just deployed ActionCable into production yesterday. I’ll be using it to share some information between our users’ mobile app and our web client.
I’m concerned about performance. As much as I know that premature optimization is the Devil, it’s hard to stomach deploying something that is so notorious for becoming a bottleneck. Once I get past my MVP of this feature and have some maintenance hours budgeted, I plan on exploring AnyCable.
> nor is there trivial integration for JS assets/asset pipeline functionality
...WHY would anyone ever want that?! I thought that splitting an app into one frontend-app and one backend-app, each in its separate repository too and runable alone is the very minimum everyone does nowadays.
(Yeah, later you may go on and chop the backend into microservices, but for starters you at least keep these two sepratate - why would you want to impose knowledge of Python or Django as requirement for your frontend developers?! Even if you start with a couple full-stackers, you'll want to later be able to hire more narrow focused specialists.)
Serious question: Django doesn't even have lazy loading. Why do people use it? Am I missing something? No way I'd wait a few seconds to get something big from the db
I work on a hybrid React-on-Rails application and working on the React portions is so. fucking. painful. Seriously the shit people come up with with this "tool" makes corporate-hack Java programmers look good. I am always taking the backend Rails-y tickets if I have the chance
Blaming complexity on React is a bit like blaming complexity on ERB. The problem isn't React, the problem is the massive hole where React doesn't have an opinion. React improves the area around the hole so much that the technologies we use to fill the void look obviously deficient in comparison.
This is actually the bane of JS community's existence. JS developed so fast and so wildly that there was never a breather to form and write down best practices or opinions. This is jarring to someone coming from the Rails world where a lot of magic is happening, there are strict opinions (heck, it's in the subtitle of the copy) and strict conventions to adhere too. JS is wild west compared to that.
This is not to say that JS is shit but both JS and Rails have their place. If you want flexibility, you need JS. If you want iteration speed and dev productivity you need Rails.
I don't understand. One is server application development, one is client development. They are two vastly different things.
From this hot take on JS, I'd think people are suggesting that the development experience of all the other available clients are a lot better, but then I became an Android and iOS developer and that's not true either.
Swift isn't bad, but the language isn't the only thing that dictates how hard client development is. I'd rather use React than UIKit abstractions, that's for sure. And CoreData is probably the worst and most outdated abstraction I've used across all platforms. And even if I think iOS development is the ideal way to write software... it only runs on iPhones and iPads.
I mean, of course the Rails side of your application is probably nicer than the client side where you get to stay in your simple request -> response realm that runs on the same machine. If given the option, I bet almost every HNer would rather be the person paid the same to build the API endpoints vs the crapshoot that is client and UI development.
But I see this perpetually confused as Javascript vs <my favorite language I use on the server>. For example, Ruby fares pretty poorly against Node if you forget the client, like Sinatra vs Express/Koa.
I think we're diverging. The mental model of a Rails developers is well formed and if you're a beginner then you can rely on a very strong community for opinions, best practices and conventions to follow. This greatly decreases cognitive load and immensely improves productivity.
When you make a jump to a JS stack (whether client side or server side) you have a lot of options but no best practices or conventions to follow. You have to make a lot of choices which have already been made for you in RoR. Even though SPA frontend dev has settled between React and Vue, you still have to make a lot of decisions. React also bills itself as a view library. You have to make decisions about state management (if needed), routing etc etc. A vast chunk of these decisions are made for you in RoR so that you just work on the app. I think this is what the author was lamenting about.
People REALLY underestimate how much those opinions help when it comes to software development. If you start a project or new feature and your team is going to have lots of opinions on how something should get done. It’s typically easier for people to ingest the idea that something is “best practices” than have to follow whatever someone in the room is saying.
If the platform is too unopinionated you will generally wind up with:
1) A project with many competing ideas (most js projects I see end up like this)
Or
2) A team with some people feeling like they are not heard
Ah, I see your point. I definitely was that beginner that was originally compelled by the ease of Rails. I would watch RailsCasts for fun and be amazed at how much you could do with so little. I thought it was the ultimate developer experience back then.
These days I prefer building something up from microframeworks and I like to take the opposite side of the trade-offs you mention in your comment. There are a lot of aspects of Rails I ended up really disliking over time.
But at the same time, I still find myself thinking back to some of the pleasantries that Rails gives you and wishing I had them in my bespoke applications. Even just things like being able to enumerate your routes from the CLI or seeing your SQL queries and query response time in the terminal during development. If it's something you have to implement yourself, you just tend to not do it at all. And there's a lot a framework can do for you with some opinionatedness.
I think the classic example of this realization is when you deep dive on microframeworks, accumulate them in production, and encounter things like performance issues but realize you don't even have the tools to debug them because you didn't build them.
Rails was somewhat unique at its birth with its opinionated-ness. Outside of that world, in "respectable" programming environments with smart people who were good at algorithms and O(n) notation and all that (which was not me) it was rare that I encountered the kind of insanity that I seem to run into daily with PHP and later JS.
> “...JS developed so fast and so wildly that there was never a breather to form and write down best practices or opinions.”
js and ruby were released in 1995, with rails coming 10 years later. so js development wasn’t fast in the least. after the little ajax blip resulting from outlook web access’s release in 98, js stagnated until node came along and made it interesting again.
prototype/jquery a little before it and later front-end frameworks like backbone, ember and then angular helped cement js as a thing. it only seems fast and wild because the ecosystem really only woke up again in the 2010s.
(i tooled around with js on netscape right after it came out but then lost interest)
JS may be released in 1995 but it was not used much for anything except changing status bar messages, or image rollovers (remember those?) for at least ten years. Sure there also was Microsofts DHTML on IE, which failed to get much traction. Only starting with GMail and AJAX in 2004-2005 JS started to be treated seriously, it still took some years and SPA hype to become "a must". So about ten years max.
Also Rails was constantly evolving since inception, alas, a lot of JS is revolving, i.e. solving the same problems over and over again, just with different approaches.
The last point would be that people initially taking up Rails were not new to programming and usually switched from PHP or Java. Now Javascript is often the first (alas, often the only) language people learn.
So I'd say the culture is quite different.
Well of course js development is slow - you can upgrade Rails v1 to differently opinionated Rails v2 on a server overnight. Try upgrading 8 billion people to a browser that supports eg. ES6.
> This is not to say that JS is shit but both JS and Rails have their place. If you want flexibility, you need JS. If you want iteration speed and dev productivity you need Rails.
Not true at all. Rails can be extremely flexible; it's all modular and you can reduce it down to almost nothing if you want. Javascript's only place is to run in the browser; it lost its way once people decided to make a server platform out of it. JS is far too forgiving of mistakes to be running backend code, full stop. ES6 and up are vast improvements but the damage has already been done.
And in any case I have yet to work in an environment where I am not writing at least some ES5...
I'm not so sure about that... maybe I'm just old but React provides very little of anything compelling other than shadow DOM and databinding. It seems like every opinion it has outside of those two very narrow areas is INSANE
The funniest part about the enthusiasm for React masochism is that the best parts of the library are better accomplished with a combination of Turbolinks 5 and Stimulus. Not a coincidence that they're all Rails extractions.
For me, the more interesting question in all of this is where did this fervour for JS-and-the-way-down actually come from?
My hypothesis is that it's the natural result of a huge mess of new talent - fresh out of various overpriced Bootcamps and told that their 9-week educations give them a credible opinion in true post-modernist fashion - all being released on the world at the precise moment that a predictable police lineup of over-promised technologies were all at the top of their respective hype cycles.
Humans have a predictable tendency to assume that the thing they are thinking about at the moment is far more important than it actually is. If you have a very short institutional memory and everyone you know in your bubble has been programming for a relatively short period of time, pretty soon you can start to believe that if everyone is doing it, you couldn't all be wrong.
What purpose does it serve to take such an uncharitable view on other people?
This community is full of experienced professionals who use Javascript even in the face of alternative options, and we belabor this topic every day.
So what excuse do you have for assuming and hypothesizing that everyone must be an unenlightened boot camp amateur when you could've turned to anyone and simply asked?
For example, to me, modern JS is not substantially worse than other dynamically typed languages. Give me Python and Ruby code and the Javascript version probably looks the exact same. Meanwhile, those languages don't have a 1:1 version of `results = await Promise.map(urls, (url) => crawl(url), { concurrency: 8 })`. And that's not to start a language war but rather to demonstrate a concise example of a technical strength, aka a purely technical ground that a craftsperson could reach for that tool.
But now fold in its advantages like ubiquity, async-everything, runs natively in the browser, and has a static-typing system that's actually catching on, and it should be pretty obvious why someone could pick it when given an option beyond "they don't know any better."
Also, there's the obvious trade-off of treating your server as the API for all of your clients and treating the web as just another client that runs on the user's device instead of essentially coupling it with the server.
But surely these things are obvious or easy to find out, so it's hard to assume good faith in your post.
why is async everything a strength?
I find it an unnatural way to think about coding, just like threading. Sure if performance absolutely requires it I'll start using threading, but why do it by default?
A strength, in my eyes, is simplicity. What's simpler than a code that runs sequentially?
Node is single-threaded + async-everything which gives you simple concurrency with the async/await abstraction. It's these there things that come together to make building async apps simple. For example, I went out of my way to avoid Node before it had promises and async/await, and that seems to be the Javascript most HN users remember.
Concurrency in this situation almost becomes free at the expense of changing
user = db.findUser(42)
to
user = await db.findUser(42)
So when writing programs where you want more than one I/O thing to be happening at a time whether it's network requests or a bunch of concurrent workers, which is pretty much why you'd use Node, you get it trivially.
Even something like running parallel DB queries trivially inside an Express route:
That code in Go would take me 40 lines and involve wait groups.
Compare that to Netty or trying to write async code in Rust where it's really easy to block the event loop because all libraries and stdlib are sync by default. So you're passing around a CPU pool to run sync code inside your async context. It's hard to look at that sort of code and understand its runtime behavior. Oops, you accidentally blocked. Oops, the pool gets saturated immediately and starts blocking. It's hard to straddle both worlds, and the code is constantly trying to "return to its sync default" so you have to be eternally vigilant. Sync isn't necessarily the default you want, either.
Of course, this comes with other expenses like needing to run one process per core and you can't do CPU-bound work in-process. But you may be used to that limitation using Ruby or Python for example.
I'm not trying to start a language war or tell you that you should drop what you're doing to use Node because it's The Best.
What I'm responding to is this idea that you couldn't possibly have a technical reason to use Node given a choice unless you're fresh out of a boot camp and know no better.
Node + Express is just fine for the same sorts of things that Sinatra is fine for. If you are more comfortable in JS than Ruby, please know that you have my full encouragement and support.
However, you are (perhaps unintentionally) twisting my words. I brought up bootcamps because I can demonstrate a strong causal association on a timeline.
The beef, such as it is, is with the 750k npm packages, the brutal moving target that is the packaging/transpiling/dependency hell/OCD bikeshedding that comes with a commitment to the JS ecosystem. And given that you used to be a Rails user, you know full well what giving up sane defaults in favour of the pursuit of pure compositional bliss looks like, but you're choosing to forget the trauma.
Meanwhile, there's an entire generation of new devs that have been told that Rails (or your favourite server side alternative) have been eclipsed by better thinking. I don't think I'm just an angry old man screaming at cars from my porch when I call bullshit.
Javascript is good for async code, still not sure why this is a great thing by default. It's nice when you want to write async code, do you always want to write async code?
For most web apps I've seen you simply don't need to write them in such a way. Blocking IO will switch to a different thread in most ruby web servers anyway.
All that's nice at the language level in favor of JS, but it doesn't speak to the framework level of what all Rails offers compared to everything additional you need to add to React to be comparable. Same deal for some of the frameworks in PHP like Laravel or Drupal.
Comparing React vs Rails is like comparing an iOS app to Rails. I don't really see the point since they are fundamentally different, and whether your application should run on the client or not is a bedrock decision long before you get to "React vs Rails". Rails isn't even an option in one of the branches of that decision.
I assume you meant to instead draw a distinction between a large framework like Rails and a tiny one like Sinatra. And I'd say that ranges from a matter of taste to the composition of your team more than anything else. Obviously there are upsides and downsides to any point you can mark on the continuum.
I meant that if the Ruby community had an inherent preference for Sinatra-like frameworks such that Rails had the same status as Meteor or Sails does these days, then you would get articles by developers saying how they miss Django when having to reimplement a bunch of stuff in Sinatra that you automatically get with Django.
But you're right that I made an invalid comparison to React. It's more the starting with Node and having to add a bunch of functionality that you would get out of the box in Rails, because a front-end framework like React is the preference, and lots of developers would rather write isomorphic apps/sites.
It's difficult to convey context or background in these conversations, and they quickly become circular based on each participant's favourite default assumptions. For example, you're clearly excited about asynchronous, Promise-driven code patterns. I am preoccupied with developer happiness and ergonomics that come primarily as a result of opinionated defaults and a relatively stable ecosystem + build process. The simple truth is that if I needed results = async map -> crawl() in rb, I would call a service written in Go or Rust... but also, the number of times where I need to green-field a web crawler is dwarfed 250-1 by building the sexiest, snappiest CRUD UIs possible.
Meanwhile, there was once upon a time a perceived crisis of junior talent which led to the creation of the first code bootcamps, all of which were taught Rails, jQuery and Sass. I'm not trying to be shitty, classist or ageist in suggesting that the bootcamp phenomena suddenly started emitting a large number of blank-slate new devs that would understandably treat every exciting idea as the most incredible thing since <insert your fav noun>. After all, if you have few previous experiences, what can you compare against?
Previous generations of devs learned predominantly through either auto-didactic persistence or academic lectures; this new crop was suddenly predominantly learning from (and influencing) each other.
I recently read an excellent book called The Death of Truth, which technically has nothing to do with programming... except that in this conversation, it's totally about programming. If every coder's ideas are treated as equally valid truths even though there exists a massive gulf between their relative experiences, then we're confusing feelings with good engineering.
I think it's that, and the general accessibility of Javascript. Before this JS craze you saw the same shit with PHP and Visual Basic, though for the most part people weren't trying to build and rebuild the same platforms nearly as much as now
I know that it's 2008 calling, but seriously: when did Heroku, Github and the bundler/gem ecosystem stop qualifying as accessible? Deploying an MVP Rails app with sophisticated functionality is so effective that it still qualifies as erotic.
For me, the most compelling example of progress coming from the JS camp was my shallow investigation of the Expo platform for React Native. It has some genuinely sexy developer ergonomics features which I'd love to see make their way back into Rails.
I've been trying to learn some Rails and it's not that simple. People tend to say just read Hartl which is 804 pages according to Amazon. It may seem simple once you are familiar with a few dozen gems, action this, active that but there are a lot of bits to learn about.
I'd like to formally extend an open offer to help you or anyone else reading this to contact me for help if you're stuck learning Rails. Just reply with an email or some other mechanism and I'll follow up. If you have questions about best practices or you're just stuck on something, hit me up.
Hartl is great, has his/its place etc. Sometimes you just need a smart person with experience to add personal context. Happy to be of service.
Hi, if you are interested in helping people with their ruby/rails issues, there is also reddit / ruby discord / rails slack / and stack overflow. I'm trying to be active on Reddit and the Discord but not very active on slack/stack overflow. There are already quite a few people helping but more people would help :).
True, any 15 year old framework will have bloat.
But Rails is absolutely skinny compared to Spring, ASP and fellows.
Its probably easier than a MEAN stack also.
That book is long, not because rails is bloated, but because there are very in depth sections building things from scratch like authentication that in practice are solved by gems. They are important for beginners to learn but are rarely reimplement from scratch in rails projects.
Not quite true - React confuses inputs with outputs by taking in callbacks as props instead of just emitting events. This makes shouldComponentUpdate very error prone, and memoizing callbacks to work around it is a mess. This is a large contributor to complexity and bugs in React apps.
That's a great observation -- one that's true of, say, jQuery too, which handled the problems of cross browser compatibility, over-verbose interfaces, and DOM manipulation so well that... we got to really take a hard look at the problem of doing everything we wanted by direct DOM manipulation.
Honestly, I just wish Rails had some degree of static typing (a la TypeScript.) As a Rails code base grows and patterns are required beyond the basics, it becomes a nightmare to tell what comes from where. You'd probably gain some mileage from that in your React codebase.
I've been meaning to revisit Kotlin's web framework offerings. I've used it in small doses for Android and AWS Lambda functions and, IMO, it seems to potentially be the best of both worlds; strict where it needs to be and flexible where it doesn't. I'm currently supporting a few Python Lambda functions at work and they feel very slapdash in comparison.
The biggest problem with Kotlin is also it's biggest strength: excellent interop with Java. This means that you can use all of the Java libraries...but that also makes writing new libraries in idiomatic Kotlin unnecessary, so you're going to get less of them, and have to use a lot of crummy old Java APIs.
Try Kotlin with the Spring Boot framework. I view Spring Boot as the Rails of the Java world and the Spring team has done a lot of work lately on Kotlin compatibility and idiomatic APIs.
This week I’ve been porting one of my Spring Boot apps to Kotlin and that was a great experience.
The only thing I’m waiting for is good reactive drivers for Postgres and then you can go with their new reactor based apis instead of the older one-thread per request Spring MVC.
This is a good point. I haven't used Spring in forever, so I don't know if/how it takes advantage of any modern Java features, but I could see Java 8/9/10 and (a framework like) Spring being pleasant and productive.
The Spring and Spring Boot teams have done a lot of work on this. IIRC Spring Boot 2.1 is compatible up until Java 11, and Java 12 support should be in 2.2.
Some API's are adapted to take advantage of modern Java features like for example JPA repositories that can return Optional<T> for single row queries and Stream<T> for multi row queries. Some API's have been improved with functional equivalents.
If you combine this with Kotlin you get all the power of the Spring framework together with excellent nullability checks and modern language features that Kotlin brings to the table.
Kotlin + Dropwizard is a great choice (or Spring Boot). I've used it in production and it's got the best aspects of Rails (opinionated) with the best aspects of a modern, statically typed language running on the JVM (need I say more?).
I'm waiting for a chance to try out Crystal/Amber, which is type-checked (not sure how safe?) and can be pre-compiled like Go apps. It looks really close to Rails:
Crystal/Amber combination is such a joy to work with, it's too bad it's not more popular, I'm contributing a bit to the project sometimes and use it for personal stuff. I regret it's not that trendy because it's the best web experience I ever had.
Stripe has built a type checker for Ruby that they're using internally. I don't think it has been released yet, but you can get a preview of it at https://sorbet.run/.
So it's something along the lines of Erlang / Elixir dialyzer. I don't like it much (dialyzer) because of the verbosity and unDRYness. Every function definition becomes two lines and the name of the function is repeated in both. Type names are longer than they should and are separated from argument names.
It would ideally look pretty similar to typescript. There's actually a few projects adding typing to ruby, but they seem to be mostly trying to catch issues at runtime, which to me is pointless. Or the syntax is onerous, using decorators and/or separate type definitons.
I'd be really interested in a typescript like superset of ruby, and I've even thought about building a prototype of it, though it's quite outside my area of expertise.
I don't mean the syntax, I mean the abuse (ostensibly a language feature) of method_missing that's incumbent in the ecosystem. What would be the type signature of Active Record?
I'm referring to things like dynamic find_by_* messages since more people might be familiar with that.
But I don't know why you'd say that. ActiveRecord models are one of the main places you'll see a bunch of `use SomeGem::Thing` that introduce a bunch of magic methods on model instances.
And my point is that we aren't talking about method composition here that you can statically analyze with a bolted-on type system. Ruby's metaprogramming runs so deep that it's a substantially bigger challenge than other dynamically-typed languages.
One clue is that humans even have a hard time with it. The first shock that people have with Ruby is when you see a method or identifier and grep shows up with zero results.
Aside, I can kinda tell that Ruby is entering Perl territory when there are no beginners around to chime in with their gripes.
The magic stuff's awful. Any time you have to dig into a mothballed Rails codebase from a version either older or newer than what you're used to, or with a bunch of Railsy magic gems that aren't in your usual toolkit, it's hell. I'd rather let the computer tell me what stuff is and where it's defined than memorize a bunch of magic prefixes.
I only say that because it seems like low-hanging fruit. If I have a class with a random @ivar that's added inside a random method, there's nothing up-front to check against. An ActiveRecord subclass at least has a database schema to validate against.
I truly agree with you. I absolutely love Rails and what it has to offer, ever since working with it since Rails 2+. Truly one of the best bet I've ever made!
Try this out: https://github.com/jho406/Breezy, its a library i wrote that makes working with the React/Redux portion feel like a classic Rails app. Its inspired by turbolinks and doesn't require APIs to work.
> If you're talking about missing a JS equivalent of rails, do you know about Loopback?
I would not go down that route, because at least Loopback 3 looks promising at first, but after a while it does not scale dx-wise. The biggest trap my team fell into, was that you could „include“ related models in a request, that you did not have permissions to. Media management was also very poor and did not integrate well into the whole eco system.
We are now using TypeORM[1] and routing-controllers[2] which has been very nice so far. I have been building my own framework at work on top of these and it safed us a good chunk of time. If you want to have a look, go to my profile, I have put a link there.
LoopBack 3 was terrible - complicated, added no value, encouraged creating vulnerabilities, had lots of obvious vulnerabilities in official components. LoopBack 4 looks pretty different, but I wouldn’t trust it to be good unless the entire team and philosophy behind it has been replaced.
I've been using LoopBack 3 in production for 18 months.
> added no value
It gives you an API explorer, routing, ORM, validation, error normalization, authentication, authorization via ACL, and more out-of-the-box. I'd consider this value.
> had lots of obvious vulnerabilities
I'd like to know more about this. The only thing I can think of is bypassing ACLs via fetching records and including relationships. I don't know of any framework or combination of libraries that doesn't have this vulnerability.
> LoopBack 3 was terrible - complicated
This is probably true. LoopBack 3 essentially uses a single model to represent your API and data model. This is the single responsibility principle taken to the extreme opposite. It's a complete nightmare at times. If you have an exact one-to-one mapping of your API to database, this may not be a problem.
> unless the entire team and philosophy behind it has been replaced
Have you heard of FeathersJS? It is more akin to rails, supports many databases (neo4j, postgres, mssql, etc), runs on plain node.js, offers soa lifecycle hooks like rails, websocket/realtime support ootb and graphql via third party libs. https://feathersjs.com/
Let's say the last time I really worked on anything Rails related was 2011-ish, and while I got stuff done OK, I never really particularly fell in love with it (and in fact was often annoyed that most projects I worked on seemed to start with a week of hacking through environment and gem snarls).
Where would people recommend I read about (a) getting up and running with rails 5 and (b) appreciating what's new and improved in the last 8 years?
I use RVM and create .ruby-version files for every single project I touch. Occasionally I'll let more than one project share a Ruby version/Gemset combo, but often I'll make sure each is unique.
No need to "bundle exec" anymore, because simply cd'ing in and out of project folders resets your gems to a clean list only required by that app. It's great. The years come and go and I still hear people complaining about Ruby version and gem hell and I wonder why the heck they aren't using RVM!
Try looking into Nuxt which is built on Vue. Docs could be better but once you figure out a few things I found that you can be highly productive. But it's strictly a front end tool. Some guys use Laravel on the Backend but I'm partial to Taffy.
I worked extensively with sails.js about three years ago and it was an unmitigated disaster. The ORM has about 1/8th of Rails' functionality and queries that would be trivial with Active Record were a nightmare. On top of that the community was a mess and around the end of that time, a lot of the core maintainers dropped out because there was so much in fighting.
Unless there have been some major changes I highly advise staying away from sails.js.
It's been about four years since we touched it. When we used Waterline (the Sails ORM), we discovered two distinct SQL injection vulnerabilities in it, without intentionally looking. I would link the related issues, but they seem to have disabled Github issues in the waterline repository[1]. That--and lots more--scared us away. We switched happily to Hapi[2] with about a week of work and never looked back.
The major stable version came with a lot of improvements.
I'm not saying sails.js is the best option for a big project, but is pretty decent for prototypes and fast development.
That was the promise. The reality is sails never really took off, fighting within the core team derailed development and fractured the community, and its opinions are so poorly documented that you basically have to learn it from reading the source. The founder will occasionally chime in and say that it's still alive, and his company has great success using it, but unless you are one of the core maintainers I doubt you will have a similar experience. There are very few people that have used sails in production that would recommend it. The author is undoubtedly a brilliant developer and light years beyond my own skill, but that does not matter when the community is tiny and bugs never get fixed.
I haven’t used sails in production, but I have tried in on a side project and it definitely was a disaster. We just started using Nest at work, which is a TypeScript framework that feels sort of like spring. It’s been nothing short of great, and typeorm is BY FAR the best orm in the node ecosystem.
I used it in production for 2 years w/ MongoDB and it worked fine for fast development. At the time the main knowledge resource was the Manning book "Sails.js in Action".
Speaking of JS, do you guys have a suggestion for good SQL querybuilder and maybe a migration tool for Node? I prefer to do everything else by hand or use smaller libraries.
Not that i don't know how to write SQL queries by hand, it's just raw SQL queries with conditions is just ugly.
Knex is really nice. I use objection which extends it for orm stuff. The insert graph features are pretty neat. I definitely don’t use all it has to offer.
>More seriously, I feel rails is still excellent and I'm happy to work with it every day. I'd be interested to hear more about what makes rails not modern?
The whole thing he explains in the post: he wants an all-rounder like Rails but which covers the SPA/JS side.
I think many of us have realized that the SPA, which introduces an entire second application into your stack, isn't that cost effective. I'm more interested in turbolinks and if absolutely necessary, maybe something like http://instantclick.io to get an 80/20 payoff.
For folks here doing startups, imagine the speed boost of maintaining one less entire application than your competitors.
I love Rails. I also like React. What I really miss is an easy way to connect the two - a Gem or a generator that connects models on Rails, through REST API endpoints, to a front-end state management library (Redux or MobX).
But I suppose that DHH got burned with Prototype and then CoffeeScript and wouldn't endorse something like this.
I think what the OP meant by 'modern,' was an equivalent of Rails that uses the technologies demanded by the tech industry today. On the one hand, the industry went to Python because a ton of data science libraries were written in that. On the other hand, React ended up real dominant on the front-end because of all the sh*t code people put between HTML JavaScript tags. Another route, is any promising asynchronous and scalability like Node or Elixir. So these divergent vectors make something like a Rails that can serve the needs of big data, snappy UI and scaling while at the same time using the team we've got super difficult. The needs of the industry have created an oblivion of the solution that was always already there, Rails.
That attitude needs to get out of everyone's head. You are the tech industry. If you want to build something in Rails, a mature and capable framework that has tons of support and won't go away, just do it. Who's going to stop you? Applies to any other technology that's stable as well.
The trouble is "we," the developers aren't the tech industry making the decisions. The managers, who once were full time developers, are making the decisions. I can say hey let's use this stable, mature tool, but which catches enthusiasm more? That or the guy drooling over React and all the complex mystery JS libs saying it's the best thing ever?
Yup - unless The Tech Industry is going to come in and rewrite all our code into Flavor Of The Month (and do that every 3 months forever) I don’t really care what they “demand” - I’m too busy providing value for my customers to be shaving that yak
I actually have gone back to writing server-rendered apps like it's 2012 and it's been wonderful.
Server-rendered used to mean slow and clunky but I've found that using Go my page loads are super fast. The inter-page transitions can sting a little on really really slow connections, it's true. But users are much more willing to deal with them if they haven't first been subjected to a minutes-long spinner while the SPA loads up all its libraries and state.
A little game I sometimes play is asking fellow developers to try and guess the frontend framework used on one of my apps. They click around for a little while wondering "Angular or React" before I tell them it's actually just some Go templates rendered on the server. It often opens their eyes that the loads were so fast they couldn't actually tell they were happening.
SPAs have their place and I've written a lot of them. It's amazing how far you can take server rendering in 2019, though.
I don't get why everyone keeps saying this. Is it because of WordPress? In 2005 I used my own MVC framework with ORM and stuff. It was written in PHP. My pages had the usual generation time of 0.03 seconds. And that was with no specialized caching or any crazy optimizations. Even with no AJAX, page loading seemed instant, unless you connected to the server from across the world.
I completely agree. In 2008 at my first coding job we used plain php/MySQL with no caching and the sites were responsive. Plus they required like zero maintenance! In 2009 I went to work for a Django shop and was introduced to caching, reverse proxies/wsgi servers, templating, etc. It took a long time to buy in to this way of doing things, as it seemed intentionally complicated for no reason. Over time I've learned to appreciate that there are real benefits, but it wasn't immediately obvious to me. Regarding js templating, spa's, and all that stuff: I've tried to keep my previous experience in mind, and be open-minded about the potential benefits of these technologies. But I haven't seen any as yet.
Serious question. What's wrong with simply having a static directory from which you send html files to the client? I do that all the time with my servers and the load times and the complexity of the project never seems to get out of hand. When the app needs to be highly interactive, I perform simple fetch requests and DOM updates from JS. Am I missing something here?
the lighter text means the post has been down voted correct? Why was the parent post downvoted then? They make a perfect point, there's nothing inherently slow about traditional web apps. There's definitely things regarding the UX that traditional server side web applications can't do vs browser side but they can be incredibly fast.
one nit pick, what does "server-side rendering", and even "client-side rendering", even mean? The browser renders HTML, it's always client side and it's always outside of the scope of application code. Does "rendering" really mean template parsing?
Server side rendering means the server converts a template into a fully formed html page by pulling layouts and partials together, adding JS/css assets, interpolating dynamic sections with data from the database. The response to the browser is html ready to parse and display.
Client side means the layouts, templates, partials, components are on the client and are stitched together their. The server only send data and the client app handles interpolation and generating the html.
>one nit pick, what does "server-side rendering", and even "client-side rendering", even mean? The browser renders HTML, it's always client side and it's always outside of the scope of application code.
This is an excellent point. Both HTML and JSON are string representations of data structures. Both are eventually transformed and converted to DOM.
It's kind of a misnomer; it usually means generating a "renderable" thing (e.g. HTML) , not actually rendering it on the screen because yes the browser does that.
How many "quality of life" features does your website have that require some JavaScript that you end up writing as one off functions/endpoints/etc? (various kinds of autocompletion, live search, notifications, messaging, etc.)
I'm all for server side rendering - I maintained several vanilla PHP/HTML/CSS websites in the 2000s, and only used jQuery sparingly when things grew in complexity. I later used Django for many years similarly, and when react/ember/angular/etc. started blowing up is when I started feeling like performance was something we had to worry more about.
That being said, server side rendering shows its limits when you build an application with lots of actions your users can perform on the data shown in their window, and reloading the page every time would significantly slow them down. That's when you're tempted to start going the SPA route, but those frameworks tend to be pretty opinionated about how you should structure your code and data, a slippery slope that leads to the stereotypical bloated, unresponsive JavaScript mess some websites have become famous for.
There is certainly a balance to be found, but it's a tricky one.
It depends on the application of course, but some of them do end up sprouting a bunch of little "quality of life" JS functions. Writing these is happily a much simpler experience than it was in 2012! The most complex app I run also has the deepest browser support requirements, back to IE11. That said, I still have document.querySelector in all my target browsers so I find I don't even need jQuery.
For autocompletion, datepickers, etc I use drop-in components. These tend to be jQuery based but it's not the end of the world.
When I do have a particular view or flow that outgrows the "bits and pieces of JS" phase it's actually pretty straightforward to use a modern UI library like React or Elm on that view alone. Reducing the scope of the area you're using the framework in rather than writing the entire app in it simplifies things pretty dramatically. The JS doesn't need to worry about routing, pushState, etc etc etc. It just deals with its own little patch of DOM and state.
I haven't developed any website but my server-side preference would definitely lead me to something that is always server-side-rendered. It's no surprise we all like HN, the experience definitely feels more than good enough.
There was a standard (https://tools.ietf.org/html/rfc3229) to diff pages so that only the delta would be sent to the browser. After that the only missing piece would have been that the browser doesn't refresh the whole page but intelligently re-renders the difference in the DOM, and that would have been the perfect world.
I'm really only familiar with ASP.NET, but do other frameworks not include support for partial page rendering? The ASP.NET `UpdatePanel` is simple and even has gracious degradation. (If client doesn't support for whatever reason, it will just revert back to doing full page POST and refresh.)
Of course, this is just wholesale replacing a DOM subtree with another. But there's also probably some point where just parsing the new subtree is faster than attempting to create and apply a diff.
Just because you have some interactivity doesn't mean you have to jump to an SPA, vue/knockout work well in the hybrid scenario and then you only have the complexity where it makes sense as well.
I can recommend Mithril, which can support a full spa but is also very practical if you just want small parts of the page to be dynamic. It is a great little component based spa library that is small in size and has a simple api. It is very similar to react and doesn't require a compile step.
Libraries like IntercoolerJS really help with page transitions and other dynamic interactions, while still letting you do all the rendering on the server.
SSR + Pjax + React on the components that really need it seems like a much-simpler combination to me than what seems to be generally considered 'state of the art' these days.
I find that once a company uses the product, they never stop. The customer base is very sticky.
I have also found that I bounce a lot of companies that don't "get it". They don't understand that it's about making things better for candidates and so all they see is Hackerrank with less features.
My challenge for growth is finding better ways to explain the ethos and the benefits to those companies.
Why miss it, come on back, the water's still warm and the dev is still as fast as ever in Rails. Honestly, the JS stacks all seem vastly more annoying on so many levels.
It seems like the JS ecosystem changes so fast because it knows better is possible, so it just tries to reinvent itself over and over.
The JavaScript world starts with this weird prototype based language with a syntax that looks like it might be something more class based. From there it goes to dependency bundling hell, callback hell and Christmas tree code indenting, no standard implementation, and a library required for everything under the sun (Left-pad!) And somehow this is what the cool kids are into? I never liked Rails because it was "cool" I liked it because I love getting stuff done, fast.
JS is not my first choice for many things but I still have to work with it often enough to know that most of your complaints about the language haven’t been a problem for years. It’s improved a great deal and is much better to work with lately—more so if you don’t install a library for everything under the sun (because you really don’t have to in order to be productive).
There are valid complaints to levy against the ecosystem, but the ones you listed are non-issues if you take time to learn the language and VMs/environments themselves. To be fair, I mean.
I don't use scaffolding [if I can help it]—unless it's some I've set up and maintain myself (if I know I'm going to do a run of similar projects).
Normally I only do greenfield projects as their architecture and maintainability are highest priority due to the need for longevity. Plus I often find those systems rather heavy-and not just in JS.
Oddly I never considered starting a new project with it, but now I'm questioning why that is. I guess I just don't see many new projects started in Rails, and nowhere I've worked the past few years uses it. I stopped using it after Rails 3, but I'll give it a try again in the next side-project I work on and see how it goes.
We as a profession seem to be perennial victims of availability bias.
We're naturally going to think of the stuff we've been reading about lately on the Internet first. Which is just never going to be the established and stable stuff that'll let you get your job done without producing any blog-worthy experiences in the process. "Went home after 8 hours without producing any fodder for war stories" doesn't make for an interesting tweet, let alone post on Medium.
Server side rendered is still fantastic for the vast bulk of web apps. Turbolinks and a bit of care around performance and all you users know is you have a fast site. Not many apps really need the super rich SPA type experience.
This. And it takes a LOT of work to emulate everything browsers give you for free on server side pages (caching, back button, reload to continue on connection loss ...)
And you can take this approach to the next level with Phoenix LiveView that’s in its testing phase right now. Server rendering is so fast in Phoenix that it had a lot of people clamoring for a turbolinks-like solution to the problem.
It’s not perfect yet, but as a first version is remarkably capable already.
Honestly I have stopped trusting 'the herd' as a metric as it seems we programmers are more enticed by shiny things than practicality or excellence in engineering
Rails is used heavily even for new projects under the GOV.UK umbrella. The emphasis on accessibility and usability of government sites/applications weigh in favour of more-traditional stacks.
Does it tho? React, Webpack, Babel and TypeScript have been around for a while now, and I can't think about anything else more recent that had a similar impact on the JS ecosystem.
Awhile back I converted a React app to pure JS after noticing that most of the commits for the last year had been updating as the slew of libraries it used had incompatible releases. The code size went down, performance went up, and you no longer needed a 300+MB toolchain just to load it.
According to wikipedia, the final version of Angular 2 was released on September 14, 2016. It required a complete rewrite and was not backward compatible with Angular 1. The current release of Angular seems to be version 7.
Yeah, but I am quiet sure at least 12 new frontend frameworks were pushed to Github in the last 24 hours, plus 143+ NPM packages probably broke with the last Babel update
If JavaScript is weird I have no idea what Ruby is. Callback hell and Christmas tree indenting have not been a part of JavaScript for many years since the wide adoption of promises, and now async/await.
What makes it order of magnitudes more performant than Ruby is that it's non-blocking, and now comes with a very pleasant syntax to accommodate.
> What makes it order of magnitudes more performant than Ruby
Source for the "orders of magnitude" anywhere in the last year or so? Ruby with EventMachine outperformed Node significantly when I tested websocket chat servers.
Yes, of course. Everything is a trade-off. Why the condescension?
But there are almost zero async-everything options in the space. And being confined to a second-class async subworld inside a synchronous ecosystem is a classic error-prone challenge whether you're using Twisted, Event Machine, Tokio, or Netty.
It's a pretty big downside of using Event Machine which even created its own networking primitives instead of using those in the Ruby stdlib.
Sorry, I guess on a second reading you were specifically talking about situations in which you want to do things async. In that case, I can see that everything being async from the start is preferred.
I was talking about the general case of everything being async in JS. That's frequently touted as a benefit of JS, but it's utterly maddening to workaday web developers. You want your requests to be served async (which should just be handled by whatever framework you're using), but inside of a single request you mostly just want to write synchronous code, even when you're dealing with IO. It's a lot easier to reason about.
I'd assert that inside routes you actually don't want to be sync, yet async/await lets you write async code with the simplicity of writing sync code.
Consider the simple example of just running two unrelated database/network queries at the same time which is basically a ubiquitous desire when writing a web service:
And now consider a case where you want to issue four database queries, but you don't want the route to take four connections out of the pool at once, instead ensuring that it only uses two:
// This fn is built into Bluebird and trivial to find 8-line impl for.
// getA..getD are just functions that return promises so they can be
// created lazily.
const [a,b,c,d] = await Promise.map([getA, getB, getC, getD],
(fn) => fn(),
{ concurrency: 2 }
)
What I would simply assert is that these sorts of things are really nice to have in your toolbox when writing I/O code like a networked program, and I don't think there exists a simpler async abstraction for it than Node. And I certainly would not have said this until Node had promises and async/await.
99% of the endpoints I write are two steps: load some data from the database, then use that to render HTML, JSON, CSV, etc. I really do not want to encounter any of the myriad of bugs that asynchronous execution makes possible. And the best way for that to happen is if nothing is async.
We had huge performance issues with ActionCable that basically made it unusable for more than 100 concurrent users. We considered EventMachine however ended up going with AnyCable in conjunction with AnyCable-Go which got us up to 1000 concurrency users without any performance impact.
I just updated a rails app through about 3 years worth of versions and it was minimal effort. Not sure what you mean by this. Rails seems to be very stable at this point.
Would you mind expanding on this? I went from Django to Rails and loved it so I'm always genuinely curious about the experiences of people who didn't have the same fun as me.
It was 4 years ago. I could never work rbenv and bundler to play nicely when cloning the project on the second machine. But I am willing to give it another go.
I’ll say this: I came to Rails from Node (and before that .NET but with a way smaller scope of responsibility), and I am thoroughly convinced the author is correct. I couldn’t estimate for shit in my first few months at this job (once I had ramped) because Rails makes things that would’ve taken at least twice as long easy to do, even without gems. Plus, I have seen not even a third of the compatibility issues between our version of the framework (bit old) and up-to-date games as I saw when I was writing Node full time. Rails is the first non-“enterprise” framework I’ve felt let’s me focus on the correct level of concern for my current needs.
Airbnb, Kickstarter, Twitch, GoodReads, Bloomberg, there is quite a list of companies who still run a significant amount of their site through Rails. Over time I imagine that particular bottlenecks and performance critical pieces have been pulled out into other languages and services as necessary, but I certainly wouldn't feel bad about it if I was developing or maintaing a Rails site today. It's significantly better than PHP, and a hell of a lot of sites are still run on that. The reality is that if you really need to scale, your primary bottleneck will probably be the datastore, not the frontend.
I'd say it's more use Rails for all of your standard CRUD operations and then use Go as a module in Rails using Quartz/FFI if you have any algorithms that need to be high performance. Of course you could always go down the microservice route and spin up a Python/Go service for your more intensive data processing modules.
Twitter using Rails to grow to the point where Rails became the problem was actually Rails's selling point. If you ever grow to the point where Rails is your problem, then you have money to solve that problem. But if Twitter hasn't used Rails, they might not event get to the point where their product is out the door.
It's absolutely correct to say Twitter blamed their issues on Rails. It's less likely to be correct that they wouldn't need a similar major change if they had started with anything else and grew from an MVP to one of the busiest sites in the world. I personally find it doubtful that they couldn't have done it with Rails.
When I started, Java and Spring were (still are..) enterprise (Ruby and Rails existed but were not popular in my area and network) and the major criticism in my mind was the difficulty faced as a beginner.
Spring was humongous and had so many modules that I just couldn't grasp the purpose of each (I still don't) plus there was a lot of overlapping functionality. Senior devs would come to college and ramble out stuff which made less and less sense as time passed by.
Writing a simple app became tedious without a reference by side. So that was enterprise in my mind - tedious, complicated and completely incoherent at times - what and why were completely skipped, at times, in favour of how.
At that time I discovered JS and the simplicity of assembling a decent sized app won me over. The startup ecosystem was also picking up pace in my country and speed of iteration mattered more than anything else. Granted JS can become a nightmare (which I learned later) but that speedy feedback compared to Java was enough to make node my "homestack."
There were other things which worked strongly against Java in my education -
1. Being forced to use eclipse without training (what are these buttons, what does everything do, how do i do this, I was fighting more against the IDE than anything else)
2. Being forced to use the Oracle database which was (for some xyz reason) given to us in a virtual machine and took ages to run a simple join in a small table of 100-500 records.
3. Programmers with experience can be completely oblivious to the mental model of a beginner.
Long time rails developer turned "enterprise". Spring-cloud now requires much less boilerplate and is easy to develop with using kotlin's syntactic sugar shortening code and making it more concise.
Orm is kind of a failure and requires us to write some queries by hand into string literals, but at least it has it's own sql syntax to avoid engine dependence.
Much less? I haven't use spring cloud for quite a while but last time I did it there's quite some grunt work to make config server / eureka / ribbon / hystrix and friends to work. Let alone the the deployment process.
But I think the key difference is Rails is more opinionated so you don't have to worry about which circuit breaker to use. Or just don't use any.
You are typing about activating the service discovery modules of spring cloud (which rails doesn't have), I am typing about the autoconfiguration goodness. Sure, I could have said spring boot instead of cloud, but cloud is kind of a superset and comes with feign integration so I use that.
I used to think SpringBoot was amazing until I tried Rails. Then I really felt another level of holy shit.
I have lots of love for both. They're different tools. Ultimately I dropped Rails because being without static typing just isn't for me, but certain parts of the experience were positively magical.
I sort of feel the same way about Boot. That auto configuration mechanism is next level. The breadth and depth of what's available in the Spring ecosystem is great too.
They're really kind of optimized for different things though. Like Rails has some gems you just drop in and it blows you away what you get for stunningly little effort. But then it's not that customizable and you find yourself fighting with it. Spring has all kinds of battle tested enterprise grade bits and bobs that take a lot longer to operationalize but they'll last you forever.
I'm currently trying out aspnetboilerplate as a middle ground between the two. Specifically the aspnetzero version. It's like that "holy shit I get all this out of the box?" with Rails but the "I can understand this, work with it, customize it if I need to and it's going to last the distance". Im finding there is a slight learning curve to it and I wouldn't necessarily make all the same choices the framework does, but so far I can see this becoming a happy medium once I've found my groove with it.
And yet I regularly see "fluent programming" levels of verbosity in the Spring-everything Java services and batch process code at my company. variableNamesThatLookLikeThis and tests.givenSome(data).thatLook(likeThis) seems to be something I only ever see in Java code bases. There's a love of unnecessary verbosity in that ecosystem.
It means it's everything but the kitchen sink: heavyweight, difficult to learn and use, and full of features you don't need.
It has nothing to do with popularity being bad. In general that's good a thing, because support is better (and rails does have terrific support), but it does exert a feature-accretion force.
I didn’t mean it as a slur! When I wrote .NET, the applications I was working in were massively large and complex, and so mostly what I was working on was optimizing small bits and pieces, and they allowed me to focus ON optimizing those small bits and pieces, because they were what mattered in that context. Rails let’s me focus on the big picture, because that’s what matters in my current context. Express had me working on stuff that I didn’t REALLY care about/want to know about in the context I was in.
Have you ever used rails? It's not heavy or difficult to learn. Many commonly used things are actually separate gems, not included in the core framework.
Confirmed, Chicago has multiple billion and hundred-million-dollar businesses built on Ruby on Rails. A lot of it stems from Basecamp being based here, so Chicago had a lot of early adopters. But those early adopters have spawned new companies using the latest versions of Rails decades later.
I still write Rails applications regularly, some applications I've maintained since 3.0 to 5.x.
What's amazing, is I booted up a 4 year old project in minutes the other day at work. A co-worker was interested in using the project, it took 15 minutes to setup clean.
Overall, I find Rails is easily more maintainable and definitely enjoy it more than the Django and Flask apps I write regularly. Javascript (Node + React/Angular) breaks all the time when upgrading, so maintaining it is not super fun either...
Here's a project I wrote in Rails and deployed late last year:
I'll take a mildly unpopular opinion and say that I really despise code-gen-style web frameworks, like Rails or ASP.NET MVC or Django, and would rather reinvent the wheel than use them.
I definitely see the appeal of these frameworks, but I feel that a side effect of having them is that there's a metric ton of code generated and you really have no idea how it works. I remember spending almost 30 minutes digging through the C# object being used to parse JSON, generated by ASP.NET, to see why a field mapping was being done incorrectly, simply because I had traverse through four different files to see the logic.
Granted, part of the problem there is intrinsic to how C#/Java are structured, and the massive number of files needed by them, but I still feel that the code generation made it worse.
Even if the code weren't generated, the amount of ceremony to add an endpoint, add a new type to be parsed, and perform updates just does my head in. That aforementioned C# app was about ~1000 LOC, across a few dozen files. I rewrote the system, from scratch, using Clojure and http-kit in around 100 LOC, without losing any features.
I'm probably just old now, but I suppose I really dislike magic in my codebase, which is why I tend to prefer the lower-level things.
(Also, just a note, I'm a total hypocrite, since I actually wrote an MVC-ish framework in Node.js 5 years ago, then ported it over to Erlang).
I feel like as a collective set of industries across development and security we have been telling people for years not to reinvent the wheel because it's easier to stand on the shoulders of giants. Despite this, there seems to be an increasing push (from, for example, Go programmers) to go back to DIY. Is this not tearing away all the work we've done to stop people building their own auth, their own crypto, their own file read/write mechanisms and use ones that are battle-tested and safe?
I should backtrack a tiny bit before I'm downvoted to oblivion.
I'm not opposed to libraries to handle a lot of stuff (like auth, crypto, and file I/O). I think it's typically irresponsible to reinvent these things for any reason other than "it's a fun personal project".
What I dislike about a lot of the frameworks is how locked-in I feel. There's (often) only one way to do things, and I don't always feel it's the best way, like my aforementioned parsing logic.
Sure, the framework's way might not always be the best way of doing things but I prefer to just accept it and move on. It saves spending time debating, deciding, experimenting with different ways of structuring code, when it probably doesn't really make that big of a difference in the end anyway. Most web applications are really not that different from each other.
On top of that it prevents really bad coders from rolling their own in a really bad way. Remember when everybody was coding their own MVC framework in PHP?
As for C# not parsing JSON correctly, that seems more like a problem with a language or library not anything to do with frameworks?
I overly simplified, but basically the issue came with having to figure out how the route was binding, then finding the class that was handling that binding, then finding the class the handled the parsing, etc.
It's not intrinsic to all frameworks I'm sure, but imposed structure like that does inherently lead to bureaucracy, which can make figuring stuff out difficult.
Its only an issue when it doesn't work, and for rails it basically always works. In 4 years using rails the only time I have ever had to read the source was to find an undocumented feature in Active Storage which had only just came out.
You're completely right. Clojure enables an incredible amount of productivity. It lets an engineer compose just the things they need, quickly and powerfully, to ship something complete and functioning rapidly.
With that said, might it also be possible that there could be some drawbacks? Having worked in and with Clojure, I found the ecosystem incredibly immature. It's somewhere beyond arrogant - reckless comes to mind - for most engineers to do all their own plumbing for a web service. The odds that they'll manage to design someone easily long-term maintainable are slim. The chances of authorization, authentication, potential SQL injection, and a thousand other security things being handled well is effectively none - the Clojure ecosystem seems wildly ignorant of such things. The core philosophy of just composing the libraries you need into Ring means that anything you don't actively think of will be entirely neglected. This is a dangerous and unprofessional way to ship code that will be facing the real internet.
This stands in stark contrast to the level of consideration around maintenance and security that has gone into a modern, mature framework. Or a modern language where SAST is an option.
Again, you're completely correct. Doing low-level stuff feels absolutely amazing! The sense of control, of having your hands in the guts and the ability to do what you need without wasting time on bullshit magic, is heady and glorious. It's just perhaps worth considering that that magic can sometimes be incredibly valuable, well worth the tradeoff against the feeling of freedom.
I threw Clojure in as an example, but my point is that if I avoid the ceremony, and stick to a few slightly-lower-level libraries, I end up with a lot less code that I feel was overall, easier to write and maintain.
Again, you're completely right. You will get something easier to fit into your head.
Is it perhaps possible that there might be some room to question if the goal of something that fits neatly it one person's head is really the best one? For professional applications, some might opine that there could be other considerations. Certainly most of my comments about Clojure apply to any tools that work from the same mindset.
But perhaps I merely misunderstand an elegantly made point of yours - can you help me?
Sure, it's possible that my mentality is totally wrong, and that having a large amount of cruft is necessary for a lot of big projects. I even built my own framework to experiment with these ideas [1][2] (forewarned that I think I swore a lot in the codebase and READMEs if that's a problem).
I can see that there's probably a case to be made for "forced-best-practices", which a lot of frameworks kind of entail, and I think that if you don't trust yourself (or coworkers) to write quality code, then having the guardrails for that Rails and ASP.NET MVC give you probably feel nice.
However, I think a case can be made that these same guardrails can feel restrictive and noisy to more experienced developers (or people with large-enough egos like me). I have no desire to ever touch J2EE ever again in my life, no matter how much I could get paid doing it, because it felt like getting anything done was about as much fun as filing my taxes.
Rails is certainly not as terrible as J2EE, so I'm not trying to draw a direct equivalence, and maybe a balance can be struck...Personally, I find that the "give me a server and I'll set up some middleware on top" approach like Express (for Node), and the aforementioned Ring/HTTP-Kit for Clojure give me the best balance.
Clearly there's a middle-ground -- I certainly wouldn't suggest that most people go and reimplement TCP and HTTP from scratch for a project, unless they're severely masochistic, or they just want to learn more about TCP or HTTP.
I've personally watched experienced, mature, and very senior developers build sophisticated systems with Clojure, Ring, and http-kit. And blink at me owlishly when I ask them how they sanitize their inputs to guard against SQL injection. They'd been intensely focused on the core logic, architecture, system design, and business functions. Everything else received cursury consideration.
My takeaway from that is that it's unreasonable to expect even the best of developers to remember every detail every time. Even the best forget or make mistakes. If our tools don't take this into account and protect us from ourselves, we're going to get burned.
I don't disagree with what you're saying; as I've stated, I'm not opposed to having some good libraries to handle dangerous stuff. I personally try not to do SQL with direct string-concatenation, and instead opt for something to sanitize stuff before I actually run anything (at least anything that has the chance of ever touching outside my basement :) )
I just don't like having the libraries forced as part of the full structure, and instead would (typically) prefer them to be functions (or if you're in a Lisp, possibly macros).
I totally agree. I don't like the feeling that comes from being babysat by code that tells me how I need to do everything.
But I don't know a better way to guard against all the things I might not think of. I've seen entirely too many cases of people doing something wildly unsafe and reckless because it seemed the easiest to them at the time and their tools didn't handle things for them. Use serialized objects to communicate between systems? Why not? We have Avro schemas, those will keep us safe as we deserialize random data from the network, right?
As much as I don't like being treated like a child by a bucket of bits, I also recognize that Clojurian minimalism requires me to think of literally everything. I have to know everything that's dangerous, how it's dangerous, and how to guard against it. That feels like even more load on my brain than being babysat - and I'm a security specialist!
That's fair enough, I'm not really a specialist in anything since I'm (officially) unqualified for everything...I will concede that you might have a point security-wise....but I don't have to like it!
I was reading the parent comment and some of the other comments about the mental model of a beginner. I suppose if you're first exposed to Rails and start using 'scaffold' it can generate a ton of code you'll need to grok. But once you understand the nuances of writing Rails its much faster and cleaner to just create files and go about your business. There is only 1 thing I ask Rails to generate for me and its database migrations; it handles adding the timestamp and placing it as the end of the folder, thats not something I care to think about myself.
I very much appreciate the code generation. I hate having to make repetitive changes in 4 places to add a new file because nothing is wired up automatically.
I still develop using server-rendered like it's 2012. Since I'm pretty much an indie dev, I just don't think it's worth my time to initally start a project off REST API (i.e. using react) because it's literally 1 more layer to take care off. I.e. if a REST end-point name changes, then I'd have to modify both frontend and backend code. In addition to that, initially, getting a software specs is a much harder problem than to implement. Having to create REST endpoints for every single data that needs to be passed around is not nice when the structure and specs are still very likely to change.
Moreover, finding developer experienced in react is much harder and more expensive than those who do traditional HTML-CSS combo. Finding a freelancer to slice out PSD design into HTML-CSS is also much harder to go wrong. I wouldn't be comfortable outsourcing a react project to freelancer I barely know, but I'd do it for HTML-CSS.
I'm not against react or other SPA frameworks by any means. I think they're great technology that makes certain use cases convenient and can make a good user experience. That being said, there are also costs for those, and I just feel like there are so many websites out there that don't actually need to be implemented using SPA. Traditional server-side rendering would have saved them so much time, resources, and headache.
I personally would only rewrite a particular project into an SPA when there's a real need for it. For example, when the user base is large enough that a nice-to-have user experience becomes a big enough deal, if there are real needs for "reactiveness", or if mobile apps counterparts that would also require REST API is needed.
As a beginner, Rails seems much easier to get from zero to something. So much of the tutorials I’ve seen on react are about dependencies and environment setup. I know React has some big advantages but on smaller teams/projects it’s hard to see the benefit.
Elixir and Phoenix are excellent, and you'll recognize many of the same concepts in these. The communities are excellent as well, and welcoming to newcomers.
They're fantastic and I hope the future is bright for them but I've had to pick Rails for a few projects over the last few months because the library support is so much more established. The more I get to use Phoenix, the more I am convinced it is the most well designed web framework there is, so I hope to use it a lot going forward.
It took me a couple of hours to build my first demo with it, have a look: https://youtu.be/tTPH4DyUaUk
and I didn't have to write any JavaScript for it.
Elixir/Erlang's emphasis on uptime/fault-tolerance/scalability/concurrency (admittedly at the cost of performance and the abstraction of a VM) is perfectly suited to web/mobile use-cases.
On paper, Pheonix should be the default choice for large and small web/mobile MVC applications. I think the question of if that becomes the case is directly tied to adoption of Elixir.
The performance comparison matters if you start comparing nginx, and maybe even the Go/Rust frameworks, but it absolutely blows Rails out of the water for performance without sacrificing any of the high-level abstraction goodness that makes Rails appealing. No reason not to move to Elixir unless you cant hack functional programming IMO
I've found that Elixir & Phoenix are the right abstraction of Rails-like productivity but "enterprise" reliability and scalabiliy. You get real-time functionality out of the box (dosen't feel cobbled together like Rails channels and blows anything Node out of the water). And with LiveWiew coming soon, it's going to be even quicker to build modern interactive experiences.
"Move fast and break things" very accurately reflects the state of Javascript development in 2019. Libraries and frameworks, and node/npm themselves move so quickly that APIs, versions, ways of doing things -- all break so quickly as to be ludicrous.
This post rings true.
I gave nextjs a try recently to build a simple dashboard that could connect to our oauth provider. Forget external libraries, even simple ways to do state management, user login, screens, HOCs to guard routes - all of this is poorly documented, managed, and there are 100s of github gists that aren't versioned, demonstrate old APIs that have been deprecated and aren't really usable unless someone who knows that they're doing goes in, and cobbles together an example.
I'll bite. One, I'm not sure next.js is the right tool for a simple dashboard. Seems a bit overkill. I think some simple MVC pages with vue dropped in where necessary would be a better fit. Also, your last sentence sounds like you're saying that it's not usable unless you know how to use it.
For completeness - the goal was to create a dashboard that could actually utilize SSR as we scale it up to larger amounts of traffic.
The last sentence was written to mean that unless you go in and spend a LOT of time reverse engineering code from a myriad examples, it's almost impossible to get a working implementation.
I've been using Django since I started 10 years ago. I argue that it was a great choice back then and it's _still_ the right choice even with the advent of the modern everything. If you are writing a website for a business, I see nearly no actual business case for using Node+SPA for nearly any kind of website you'd want to build. Especially in a business context, unless you are building a super ultra real time thing (and then use Elixir not Node), Django will do just fine and be several times faster to develop and easier to pull off. And you can get pretty far into the dynamicness camp before it becomes untenable. s/Django/Rails.
Rails developer here. I did Django for 6 months and nothing bad happened, it's a sane, mature, solid framework.
Ruby/Rails feels nicer to me but Django is super solid.
Also, a senior Rails developer can become very productive in Django in a matter of months (and probably vice versa) so it's not as if it's two worlds apart.
I personally don't missed Rails mostly because boilerplate doesn't really bother me. I'm more afraid of using the wrong abstraction.
Rails (v4 was my last experience) was hard for me and I think my reasoning is as follow:
- I like to dig deep into the framework I work with but Rails have so much meta programming (a.k.a magic) that I struggle real hard figuring out stuff. You often have to go into runtime, hit method and see where it lead you to and after a while, I realise that I'm not going to see the bottom.
- If you are someone who like to dig deep, the documentation wasn't helpful for me at all.
- ActiveRecord for a while discourage using foreign key. When I move away from Rails, I tried SQLAlchemy and love that its unopinionated. Then I move to node and agree its ORM are less powerful but I learnt to love SQL. ActiveRecord for me shouldn't be any more than just convenience ORM and shouldn't replace SQL, that goes against Rails' ActiveRecord philosophy which claim these constraints should be at the model side rather than DB side. https://guides.rubyonrails.org/active_record_migrations.html...
- Lastly, I firmly believe MVC is a leaky abstraction. Any variations of MVC is just shifting the complexity around, not reducing it. I worked on Rails, worked on iOS (which uses M-V-VC). The pattern I see is that almost every year, someone will get bitten by vanilla MVC, tried some variants unsuccessfully and conjure a new variant; the cycle goes on. MVC is a 20 year old pattern, it have amazing insight into how we should build application, but its implementation always fall short after so many years.
Ultimately, I don't think Rails was optimised for someone like me. I think there's just fundamental differences in philosophy between me and Rails.
I agree with the magic complaint. As a newer dev, I don't like how difficult it is to reason about core rails features and added gems... inheritance from hidden classes, etc.
Agnostic of stack, SPAs provide a clear separation of concerns. The api layer is responsible for transforming data between the client and controlling access. The client is responsible for presenting the data structures provided by the api to the user, and turning user inputs into data structures that the api can consume.
I feel like this line of thinking is very analogous to the whole microservice craze -- you shouldn't need to introduce a network boundary to write well architected software. There's no reason you can't have a clear separation of concerns in a server side rendered application.
And "there's no reason you can't, if you wanted" is a far cry from "sure, the work is already done."
For example, something as simple as having a server-side rendered forum built with your favorite back-end language and now you want to build a client for it (web, iOS, Android).
That basically means massive duplication as you create a json interface boundary.
Yeah, you were already passing a { user, topic, posts } object to the template, so you can just serialize it your json api, right? But you can't because when you wrote that code, you knew the data never left the process. You didn't need to scrub the user.password_digest. Adding an api on top of an existing system is a lot of work no matter how much you hand wave about "well architected software."
But forget over the air network boundary. How about just wanting to implement the view layer of your Rails app with Go one day? How exactly would a "well architected" Rails app help you out?
The truth is that one reason that SSRs are simpler is because they are monoliths which spares you from certain classes of concerns. That's the trade-off you have to pay for if you want to cleave the monolith one day.
It sounds like you're assuming the SSR is not well architected and then using that assumption to prove your point. It's pretty easy to have an API layer interal to your application -- have your view templates consume that API. No reason you have to have your view templates across the network, written in another language.
No, what I would say instead is that 90%+ of SSR apps aren't architected like that, so I would accuse you of the same thing: that you're using "well architected" to describe what's actually an exotic configuration that nobody refers to when they talk about SSR, basically creating microservices on localhost that hit your own network stack which is a premature abstraction for most cases that I thought you just got done lambasting in your OP.
Who said anything about microservices on the local network stack? You don't need to do that to separate the layers; just have them be separate logical layers in your application. This is common enough that I almost think we're talking about different things: people have written APIs and SSR apps for much, much longer than SPAs have been around.
I agree 100%... The network boundry is in fact arbitrary. There are all sorts of similar hardware boundries in any computer system which we trust the OS, framework, language, etc to abstract away for us. For example how often do we think about where an Array is stored? It could anywhere from Highspeed cache to swapped out on disk. Likewise the client-server boundry for most of coding should be invisible.
Don’t forget interactivity and real-time feedback for user actions. SSR simply can’t provide that without lots of javascript thrown inside each template, and we all know what that leads to...
To put it generously, this is theory that rarely makes it to the real world. In reality, all SPAs I've seen had chunks of business logic re-implemented on the client side, and had web services that only made sense within the context of specific user interactions.
Moreover, no one stops you from separating concerns on the server side.
It’s really good at highly dynamic/interactive apps, such as browser versions of asana or slack, or other things where user actions are small but frequent. If you aren’t doing full page reloads and have a lot of changes, it’s much simpler than managing each individual state change in vanilla javascript.
I personally think React’s component model is much nicer than any templating system I’ve used as it supports composition as a first-class feature.
And if done well, yes you get better performance on the frontend. (If done poorly, you don’t.)
Unfortunately, React's been around long enough now that there is legacy code that was NOT done well at all. I unfortunately inherited a project recently that was so convoluted and over-engineered, it took me like 30 minutes just to figure out how to change the logo in the top navbar. I could have done that with a Rails layout or header partial in about 30 seconds!
For my work it's all React + React-Native shared codebase for web and mobile.
I've also heard that graph dbs are better for social data than relational dbs, though I don't know the details. So I guess another use case is you are Facebook.
From my perspective as a developer who's had to use React, it seems more like following trends than solving a real problem.
In my case, I've had to deal with a form-heavy application, where React adds more boilerplate to form handling than just using the DOM.
I've really never bought the performance thing about a javascript-heavy SPA. I'd much rather see progressively-loaded html content than watch a loading indicator. I'd really rather have slightly longer page loads on average than deal with the long wait, and then hurry up and wait of the typical Single-Page App.
For a straightforward well constrained app, the complaint against rails is usually performance. But it breaks down as soon as the well constrained app has to be maintained or grown for any amount of time past typical JS dependency hell.
Rails/ruby perf is getting better with some new work in ruby with JIT and memory. It's got its work cut out to match up with Go, Elixir, or Node, but compared to the rest of the options, it also has a huge head start on some other basic things like community and support.
Seriously, do people like writing boilerplate or something? Whenever I write a non Rails backend, I keep on thinking about how easy, how fast this would be done in Rails. Like I'm writing a backend right now in Rust, and while Rust is an excellent language with lots of ergonomic features, it's not a tenth as fast or fun as Rails. It's quite depressing to be writing a bunch of Rust code only to remember that this would be done in a few minutes with Rails (albeit with half the safety).
For instance, let's take writing a simple RESTful API. With Rust and Rocket, I need to build up the file structure, start writing controllers to fetch the different resources using diesel, figure out connection pools and how they link with Rocket fairings, then find I need rocket_contrib in order to automatically serialize to Json, then write out all the same routes (/ GET/POST, /:id GET/DELETE/UPDATE, etc.). Meanwhile in Rails I type `rails generate scaffold article title:string content:string`. Boom. Done.
Several times I've found myself thinking about ways of making my development experience better in Rust. Maybe I could write some macros that fix my problems. But then I'd just be reinventing Rails' metaprogramming. Ah well. I guess sometimes we need to reinvent the wheel.
What’s the harm in using rails purely as an API? You’ll still get a lot of functionality out of the box and maybe have to write just a little bit more glue code for the JS-backed front end than what rails provides out of the box.
That's what we do. Rails mostly just a json api, with a React front end. Devise handles auth. Useful gems in models and services, sidekiq doing its thing... Happy with the setup.
As far as I know, there's no official way of using Devise over a REST API. It is designed with a server-side Rails app in mind. There's devise_token_auth and related client libraries, but I wish there was an official way for handling authentication for single-page apps. Every time I look into this issue, it seems like there isn't much going on in this space. Then again, maybe the entire authentication protocols space is like that, and it's actually Devise which is in the unusual position of being a de-facto standardized way to do auth in the Rails world.
It's true that there isn't an official way to use Devise over REST, but then again Devise isn't even the official way to manage auth in Rails apps - it just happens to be the de facto one due to community support. That being said, by using something like devise_token_auth/simple_token_authentication and devise-two-factor you can have a token based auth system with MFA ready in a matter of minutes.
Personally, I don't think there are really any back-end frameworks that have an official way to handle auth as it's always based more on community consensus.
I'd just like to say Spring Security has come a LONG way. It use to be a maze of madness and frustration but now is fairly straightforward.
Also, Spring Boot saved that whole organization from irrelevance. It took a huge amount of effort to just get hello world on the screen prior to Spring Boot.
I have seen this many times. You start with ActiveRecord, and before you know it, you are with a working with a Frankenstein of gems that resembles Rails, except it isn't done well.
I've come to a different conclusion over the years.
For example, let's compare 5 legacy Rails apps (each at a different version since this is the real world) to 5 bespoke Express/Sinatra apps.
One upside of the Express apps is that all of their glue code is right there in plain sight. You can go into each code base with a blank slate and read the code to understand what it's doing with zero dependent knowledge.
Having worked on Rails apps as part of my 7 years as a contractor, you don't get that benefit in a super framework. You need so much knowledge about Rails to follow the trail through an application. And it gets hard to keep things straight once you're jumping around old versions. Even stuff like "wait, where did this variable/method come from again?" and being able to quickly ID it as something Rails itself provides vs something else (application code or gem).
Or how about figuring out how authentication works in each of your 5 Rails apps that use Devise? If you're a veteran, you know to look for some magic options in config.rb/devise.rb and you know what they translate into. Otherwise it feels like credentializing in a black box.
I think that things like React and Express are toppling the old guard idea of Ember and Rails that large applications somehow save you from work. When Rails was hitting the front page of HN every day 9 years ago, the meme of the day was how much you could do with so little code. DHH showed you how to make a blog with almost nothing but `$ rails generate`. Want a user-avatar system that uploads to S3? Just drop a few lines here and there: https://github.com/carrierwaveuploader/carrierwave#getting-s... -- this was the spice of Rails.
The benefits are almost undeniable upfront, and the down sides of the trade-offs they make usually take a long time to fruit, so they're hard to quantify. But they're there.
But I can't tell you how many times I've deep dived on a client's old Rails app with pencil and paper into the wee hours of the morning wishing it was indeed just a "microframework that half-implemented Rails" if that would mean I could follow actual code from A to B.
Don't get me wrong, there are always trade-offs and there is never a best. This isn't to lambast all Rails apps across the globe. But I see the "you're going to either use Rails or reinvent Rails" meme a lot to discourage smaller frameworks more often than I see someone point out the other side of that trade-off.
True. You’ll loose some productivity but not as much as jumping ship to a complete JS stack. And I’m saying that as a full time JS Dev. The author is completely tearing out rails for JS without giving a solid reason or context for it.
> I’m not suggesting that we give up React and es7 and go back to writing server-templated web-apps like it’s 2012 again.
My team is still building server-templated web apps with Django, RoR, Laravel. It's just that most software we make is some sort of CRUD application and React/Redux feels like overengineering, and still a mess when it comes to SEO. Clients are happy and ultimately don't care. Should I be worried?
Static typing is nice, but the tradeoff of all the wonderful ruby library support far outweighs the node ecosystem. I found myself fighting with so many poorly-executed, half-abandoned, relatively popular (mongoose). Stuff in ruby land Just Works™. Do I want to be writing type defs for some dying library, or building features? Unfortunately, this is consistently the node ecosystem trade off.
With TypeScript you can define a single set of interfaces shared by both your client side and server code. If you change an interface to return a different value or rename a member, you immediately know where it’s used and can update it in tandem. Static type checking let’s you know everywhere that something is used without a battery of tests running through your app.
This takes 99% of the fear out of refactoring and expanding APIs which leads to incredible agility in adding features to an existing code base.
I used Typescript from the get-go on a new project recently and it's slowed down both mine and my team's development velocity a lot. Time will tell if it's a smart decision but in terms of prototyping or spiking something, I'm picking Rails every time and I think based on my current experience I'd be apt to retrofit Typescript to an existing project rather than integrate it from the beginning. I don't suppose you could recommend any good resources for better learning Typescript? The docs are OK but if there's a book or anything you'd recommend, I'd certainly appreciate it.
I don't have a book recommendation for you (what helped me was the standard documentation and about a year of daily dev time), but an observation:
Your team is likely using an overly restrictive tsconfig.json. No-implicit-any, for example.
Make it less restrictive, and you then have typing and no penalty for punting on it until later.
If using an IDE, the effort into defining types is immediately rewarded with autocomplete for API/backend AND client code, and we even export the types for use by a Monaco editor inside an internal app.
One more thing that IMO gets overlooked too often: TypeScript can typecheck your JSX markup. Compare that to any string-based templating engine, such as Knockout.js templates or jquery.tmpl, where you have to learn its snowflake DSL, you get no autocomplete, no checks for undefined variables or syntax errors…
If I never have to explain <!-- ko if: !condition --> vs <!-- ko ifnot: condition --> again, I'll be a happy man.
This is the type of thing to which I was referring. A server interface is updated to return a different data type or renamed, the client shares the same interface, type checking for TSX (TypeScript JSX) catches the name or type of the property is invalid, and you can immediately fix it.
No more grepping an entire codebase to see all the places that something is referenced and praying that you updated all of them. (And praying that you updated them correctly!)
>With TypeScript you can define a single set of interfaces shared by both your client side and server code.
If you don't have page-specific (or any, if you can) code on the client side, this stops being a problem in the first place.
It's funny how SPA fans here claim both good separation of concerns via web services and code/type sharing as features while in practice those things are mutually exclusive.
> If you don't have page-specific (or any, if you can) code on the client side, this stops being a problem in the first place.
Sure and that's a valid use case for server rendering. Though even in that situation having a typed mechanism for going from a model and view to HTML wins out over untyped templates that operate primarily on string replacement. You have the same problem server side when "first_name" in your model is renamed to "display_name".
Unless you have tests that lead to rendering every possible if/else branch in your rendering logic, you're not going to realize that you forgot to update your view template until that situation happens in production. The more complicated your views, the more likely you'll run into this situation.
> It's funny how SPA fans here claim both good separation of concerns via web services and code/type sharing as features while in practice those things are mutually exclusive.
I'm not sold on SPA either but for any application that involves an active client that makes it's own requests and maintains state, you end up needing some form of documentation for those interactions. It's not a panacea but well defined interfaces shared between the server and client solve a big part of that.
Ember was rails on the frontend. Still chugging along I guess, but honest to god I haven't seen a soul use it in the past three years. Anywhere I worked, anywhere I asked.
I'm using Phoenix and Elixir these days instead of Rails. But I've also been circling back to C# after 9 years of not using it for anything. C# has become to so incredibly open that you can write C# code and build static binaries for Linux, Mac and Windows, with single commands. Definitely check it out if you want something like that under your toolbelt.
The fact is, the javascript ecosystem is a house of cards. Most definitely the worst ecosystem I've ever used to write software. I sometimes wish a competitor to NPM launched with better organization and rules. NPM is insane, in all the worst ways. Google the left-pad incident. We need JS so we're stuck with NPM I guess.
Maybe with Phoenix LiveView we can get away with _less_ JS - maybe...
I actually dislike RoR but I'm at the same conclusion as OP. There is just something about Ruby that makes me want to keep going back to it. It is difficult choice when given the fact that JS is (and probably always will be) the de-facto language for the web so it's really hard to dismiss Node. But if that wasn't the case, I'd stick with Ruby all day.
If you really like Ruby but don’t love the “magic” side of Rails, you should try Roda and Sequel. The whole ecosystem built by Jeremy Evans is a joy to work with.
I've known rails for years but haven't yet used it seriously. I felt it's good because setting up is easy and the velocity is high.
Until now I use it every day and I found it's really great and better than my previous impression:
1. Compared to JS there's always a specific way of doing things - how to validate, how to dispatch async Job, how to send emails and real-time notification etc.
2. Compared to Spring there's only a recommended default way you can easily start with. You don't struggle with SpringWeb vs WebFlux, different JMS implementations, Hibernate or query builders, etc.
>1. Compared to JS there's always a specific way of doing things - how to validate, how to dispatch async Job, how to send emails and real-time notification etc.
This is so important. When doing something on rails you always get instructions on the exact things you have to do where as JS always seems to either give you 500 different versions of the instructions or just expects you to work out how to set it up based on everything else in your project.
I mean, we're comparing languages to frameworks here. Of course there's going to be multiple different solutions for a language while a framework will have fewer.
> Do you need user accounts with signup / login / forgot password emails / email confirmation? Install devise and you’re done.
I don't understand why these types of features are so sorely lacking on other frameworks. I was looking for a simple user management dashboard for MVC and maybe my google fu was lacking but I just could not find anything easier to implement than spending a day writing my own stupid dashboard...
Rails is just very high level. The comment on meteor makes it clear why a Rails didn't exist in JS-land. Because the fundamentals are so dynamic and so in flux it becomes hard for a high level framework to gain traction when it can become outdated so quickly (though meteor was a particularly incompetent try at it and that's not the only reason for its failure). Once the community grows a stable low level stack then a Rails-like will inexorably emerge imo, but I have a feeling that React is not at that stage yet.
I don't think a Rails equivalent will ever appear on Node.js simply because JS doesn't have a standard library. Rails stands on the shoulders of Ruby's excellent standard library. The two languages are also poles apart in terms of the quality of design. That is always going to impact any JS framework.
I love Rails vision about how to do full stack web development. It is a really good abstraction, that hides unnecessary technical complexity and lets you focus on solving business problems.
A lot of people here complains about Rails performance, and that is one of the reasons why I use the Grails - Java framework. It is not as polished as Rails, and has a few sharp edges, and it has a much smaller community which is still super-friendly and awesome. Grails however can still take the advantage of the enormous Java ecosystem. You have a library for about everything. And many of them is of really high quality too.
I have for the last five years built three successful startups with Grails, where the last one now employs 100 people. Grails has been really helpful here, as it has made it possible to move fast and add,fix,improve,break changes quickly. For my last startup Rails would most likely have struggled with the amount of data we are dealing with, while Java is hardly sweating. It is not something Grails specific, but still a part of the Grails application, that is why I mentioned Java.
My last startup, which now employs over 100 people didn't use React nor Angular either in the beginning, just vanilla Javascript. More speed, less complexity, less errors and so on. We use React today, but that is because new employees really really wants to work with. And developer happiness is really important.
You may gave gotten into Grails at a better time. I more recently attempted a project in Grails and it was a disaster. In fact it was my worst framework experience ever. Mainly because completely inadequate sources of information. Grails 3 had been released but the documentation was terribly incomplete so we had to spend a lot of time searching and about every bit of info we tried to look up returned results strictly for version 2. So some really basic things we just never figured out how to do. I’ll never touch it again.
I have used Grails since version 0.42 and I am a bit surprised to hear that the documentation has been incomplete. I have always found it very detailed, though sometimes lacking clarity as any framework documentation would have. Since the early days, the way you build Grails application has been almost identical to how you write and structure your code with the upcoming 4.0 release. Of course if you have used some plugins that has been unmaintained, that could have caused issues with upgrading. But otherwise I have had a great experience through Grails lifetime.
And if you really needed to get "out of Grails", there has never been an issue using the Spring MVC api or Spring Boot with Grails 3+
It is still now distant enough that I can't recall specific examples, but what I had found is that the solutions in blog posts etc. on Grails 2 (large majority of search results) did not apply to or did not work with Grails 3 when we tried them, unsurprising given a major version change, but frustrating nonetheless. I suspect that since you were following Grails's progression from such an early stage, any incompleteness or lack of clarity in the documentation may have not been so obvious to you because you would have been able to implicitly fill in the gaps, but we as newcomers found it totally inadequate. It was often reduced to black-box trial and error.
Having just deployed Discourse and Diaspora its obvious Ruby and Rails was not designed for end user use. There is complete and total dependency hell and a hard requirement for a build environment for basic app deployment.
This kind of engineering directly leads to endless wasted hours troubleshooting errors, routine build fails and apps that think nothing of pulling in hundreds of dependencies that in turn have their own dependencies that can fail at any time.
This is plainly wasting millions of man hours of end users time if its not a SAAS app. Compared to that Go is an ode to simplicity, PHP just works, Python is relatively painless and even Java causes little stress. Its node and ruby that seem to be designed by people who revel in complexity and have zero concern for deployment and end users.
I don't use rails, but I agree with sentiment in general. I first learnt front-end stuff with desktop UI libraries and I hated it. Creating UIs with programming languages sucks. The first time I used the web environment, I really enjoyed it and it was the reason I decided to focus on programming for the web. I was using PHP and server-side rendering, with some javascript to do some interactive things. I liked that the design aspect (html and css) was completely separate from the programming, and that there were no compile steps.
Then eventually the requirement for more application-like experiences led me to adopting client-side frameworks because server-side just wasn't able to do those things very well. I like the idea of a json-based api talking to a client application, but the client-side libraries have bought back all the things I hated about desktop UI programming.
I think html is great and should be left on its own, not combined with the programming language. That is the reason I don't like React. I can't read all of that jsx/pseudo-javascript together. It looks like a mess. Vue is better, but it is just a big hack of stuffing things into html attributes. Both of them also require a compile step if you want to use them to their full potential. So now all the things I hate are back, and I don't like web programming anymore.
People always forget Ember.js, like it's some relic of the past, despite it having very active development and a toolchain for a consistent Rails-like experience on the frontend. There's no reason why you can't use React or Vue components inside an Ember.js application if that's what you prefer.
As much as I've grown to despise the Ruby community for relying too heavily on metaprogramming and inheritance, leading to abstraction hell, I think Rails is still a great framework for serving web pages. Just because it's not the shiny new thing doesn't mean it can't do most of the things we want from it(not every company is FAANG scale), and there is still an abundance of Rails jobs in 2019.
First of all, you should use the right tool for the job. Having said that, Rails kept giving me the icky feeling. What you gain in speed of development, you lose in performance and server costs and all sorts of crazy gem meta-magic.
My current middle-ground stack is Golang API (I use go-chi) + (LitElement front-end (web components) + Redux). I'm kinda happy, though my gripe is with Go sometimes, not the stack.
To the far right where people are complaining on: React + GraphQL, etc. Well, I think you went into the deep end, so rightfully you think about veering back left again. But hey, there's a middle ground that is more "standard's based".
I tend to describe my issues with Rails in a nutshell: it felt like everything was optimized for day 0 instead of day 30 or 300.
Devise was the ultimate example of this. `rails generate devise:install`. Instant authentication system with almost zero changes to your code base.
Yet now something as central and important as authentication is implemented outside of your application in some highly abstracted software. To do something as simple as figure out the name of the cookie it sets, you have to either dive into its internals or look at the actual cookie it sets instead of just reading code that should've existed in your code base.
Rails was the first "language" I learned so I was its best case subject. It was able to indoctrinate me in the beauty of metaprogramming and things like that. Yet that still wasn't enough to keep the light from shining through the veneer when working on a real world projects where you just want to know how something works by reading application or glue code, not daisy chaining through a bunch of library code or hoping you cache-hit the library's FAQ so you don't have to deep dive.
There seems to be a lot of "why is there no Rails in {JS,Go,Rust,Clojure,...}" lately and it's no surprise to me why there isn't. The same reason Ember and Meteor never took off to the degree that React did.
There was some sort of "glue code just isn't that bad" renaissance.
> Rails was the first "language" I learned so I was its best case subject. It was able to indoctrinate me in the beauty of metaprogramming and things like that. Yet that still wasn't enough to keep the light from shining through the veneer when working on a real world projects where you just want to know how something works by reading application or glue code
I think the hidden magic is the worst part, but after a while I got pretty good at simply diving into various gems to see where the magic's happening (or failing to happen) and I don't mind that aspect now.
pry is an awesome tool. Put a `binding.pry` breakpoint in your code, do a `show-source Foo.borked_method` and explore from there.
Also, popular Rails-related gems tend to have good tests. I learned that those tests often demonstrate things that the docs don't.
Devise however is a good example how some parts of the rails ecosystem grow on complexity with your needs. I can start out with a bare devise system. But first you generate the views and handle them yourself and more often then not I end up overwriting some parts of devise controllers as well.
Sure it's kinda complex but their interface makes every form of extension rather easy.
The current javascript landscape reminds me of PHP circa 2003 + isomorphic single page madness + functional philosophical purism + dreams of type safety + <new fad here every six month>
Thanks for the recommendation of GoRails! I started screencasting a few years back because I missed Railscasts and learned just about everything from Ryan Bates. Wish he was still around in the community.
If anyone ever has suggestions on Ruby / Rails topics to cover, let me know!
Rails is still very much alive and popular, this is kind of a weird take. Server rendering is also very much still a thing.
But I do agree that it seems the JS ecosystem is missing a real Rails equivalent. Specifically an ORM that is as robust as ActiveRecord. I've often thought about building this myself, and then I remember I have a family and full time job.
The lead developer is a ex-Rails developer with a very keen sense of what made Rails successful. One of the reasons that it's still pre-1.0 is that it won't ship until the plugin architecture is good, which speaks to the point of the article.
You don't need advanced syntax in the server code to write Rails applications, so Go may be a good fit for a Rails replacement.
Rails with Webpacker is the best of both worlds IMO. Ruby is a pleasure to write and Rails saves a ton of time. There are just so many things that Rails does that you forget about until you start putting together a Node app.
Every single example the OP laid out is solved by an official laravel package. People love to hate on PHP but I can spin up a laravel app with all of those features in a matter of hours.
I can build a traditional server side rendered app or I can use the front end scaffolding to build an API driven SPA based on vue or react.
We need a framework that makes it easier to build server-rendered, multi-page web apps with Node. Preferably something "batteries included," with support for recent innovations in web tech.
Next.js pages do work for people without javascript too, and it's often paired with something like Express that can handle form post submissions. The Next.js+Express integration could be made smoother though.
I can fondly remember me trying out a Node-based framework back in the day and deciding it wasn't for me because I couldn't decipher an error that was halting the application.
Then, I decided to delete the folder.
I remember watching Windows building the list of about 1GB+ of files to delete. Only to have it try but couldn't complete the deletion process because some file names were too long because of the recursive nature of folders and dependencies in `node_module`.
I recently started working with Django after not using it for almost 10 years. It's really wonderful how nice it is to get projects up and running so fast, and the Python community is stronger than ever. There are many integrations with modern tools like Cognito and Stripe, and it automatically turns my model definitions into an admin interface and REST API (with django-rest-framework). I think I'll be sticking with it for a while.
There are many languages that work on both client and server. Most obviously JavaScript/Typescript, but also Scala and Clojure. If webassembly really takes off you can add Rust to this list.
I'm not sure how a combined framework for server and client side would work.
Whether you use Rails today or moved on, many of the concepts introduced and/or popularized by Rails can be seen in the current generation of popular server-side frameworks across many platforms.
I take modern to mean: Using latest state of the art techniques to increase programmer productivity and happiness.
Rails is still the number 1 backend framework, and the RoR ecosystem is so powerful that the https://hyperstack.org gem lets you code in Ruby on the client, and fully access your AR models directly in your client code (again all written in Ruby.)
You get all the maturity of rails, including be able to use Rspec to test your server and client code in an integrated fashion.
Meanwhile the rest of the world is writing tons of boiler plate, creating reducers, transformers, co-axial independent state repeaters, I don't know what all, but the bottom line is you have to write a ton of code to get anything done.
The arrogance and ignorance of this post is massive. There is nothing wrong with rails or django or symfony or any other server side rendered web framework, whether it's 2012 or 2019. The author seems to think that somehow react SPAs are the only modern apps. The case against SPAs is still huge and for most use cases, they are the wrong tool for the job. This type of cargo cult, fashionable trend thinking undermines his entire argument and questions his qualifications as an engineer. There's no logical explanation for not using rails or something like it. He's complaining about a problem with literally dozens of proven solutions, including rails, that he's even aware of, and yet refuses. What ever happened to use the best tool for the job rather than what's fashionable and popular in 2019? I would not want such an engineer anywhere near my company, that's for sure. I can't think of a worse trait than knowing the right solution to a problem and deciding to use something else just because "everyone else is doing it." Absolutely bonkers.
Rails applications benefit from batteries included boilerplate because Rails "owns" the whole stack.
"Modern" (contemporary?) JS applications benefit from separation of concerns, and flexibility because each layer is interchangeable.
So how do we make this better? We can't reasonably split Rails up to match the benefits of JS. The obvious (naive?) solution is to provide a protocol that JS layers can follow. Specific packages/layers can decide to provide the protocol which makes them interoperable. The developer may then pick and choose, knowing that if they choose packages that comply with the protocol, they can use the "batteries included" features.
It would be fairly trivial to identify the major features that most apps reimplement. Getting it all to play well together would not be as easy.
As the OP described, I think Meteor was a great platform, but had some fatal flaws. If "Meteor-the-company" was "Meteor-the-protocol" I think we would have been in a much better position.
I'm sorry but I am saying this all over the place on this thread. https://hyperstack.org is a logical successor to meteor but it uses Ruby (instead of JS) and Rails on the backend. However its a complete integrated isomorphic stack.
No one here is talking about clients. One of the great benefits of using Rails, Django etc. is that they are stable, very well documented, well supported frameworks with a large ecosystem of libraries and developers. If you are making an app for a client these will generally be much easier to maintain than a bespoke Javascript stack.
I think Rails is amazing. My only gripes with it are that tests run slow and you need plenty of tooling to make things work (redis, sidekiq, anycable).
I have been particularly interested with Phoenix as of late as it fixes all the gripes I have with Rails and Liveview is an amazing pattern that I think would simplify a lot of things.
We started with a Rails project two years ago. It's a bit slow, but dear god we get so much done with it. That being said, having Typescript on the frontend makes it so utterly clear how much better Rails would be with static typing.
I was just playing with Amplify the other day. I was super impressed with the graphql codegen. I think the Rails comparison makes sense with the exception of the vendor lock-in. I haven’t looked at the Serverless framework very closely, but I know it’s not tied to AWS. I wonder if that’s a better comparison to Rails?
I think the Serverless framework is more backend centric.
Amplify has a pluggable interface for different cloud providers, but I guess until Amplify reaches critical market share, nobody will implement the Azure and Google Cloud parts...
Maybe you go multi-cloud and your AWS only competitors crush you, because you spend money and time on the wrong thing and their one-provider-setup just integrated so well and saved so much time and money.
Maybe AWS goes bad quick and you can jump ship with your multi-cloud setup and save your butt while your competitors go down with it.
This is pretty interesting, (not to mention it's a very aesthetically pleasing page). It seems like we're possibly seeing the rise "meta-frameworks", which simply provide a higher level of abstraction by combining multiple disparate tools.
I work primarily on the backend, so this could be incorrect. But I'm curious if anyone else has been aware of this trend, or if I'm identifying something that isn't really there.
I read your blog and I think that's why we still need Rails to keep other frameworks on their toe.
Feature/Improvements introduced in Rails are constantly being picked up by other frameworks but for some reason, people are ignorant about the progress made by Rails in the last couple of years.
I use Rails every day at work and trust me when I say this, It is so easy to get back to the code written last week or even last month(Of course Ruby plays a big role in that). It is a big advantage when you do not have to break your head every time you wanna review your code which is written some time back.
What would be cool is a full stack framework that was built around GraphQL and a SPA but that had essential packages for a broad array of features. Sort of like when rails added REST but within and around the framework. The problem with configuration would be solved if vue or ember or angular had an opinionated server/api stack that was maintained and integrated more tightly. Some people like configuration, that’s fine, lots of options out there. Others like conventions and a unified end to end platform, lots of options for MVC, literally none for SPA/API.
It took me a long time to learn rails, it's very magical and makes many decisions for you. If you constantly find yourself disagreeing or fighting these decisions, rails will never be fun. Maybe this is why so many people are against it, but I loved having a framework teach me about why it made these decisions. To me, nothing comes close to vanilla rails app, after you learn where and when to apply certain patterns it's extremely productive and fun to use. You can get so much farther than you probably think if you haven't used it in a while.
When I first looked into Rails I ended up learning Ruby because it was so fun but Rails was overwhelming. After I got Ruby I found sinatra and my fascination to use Ruby for the Web was finally born. After that I discovered Padrino. Essentially sinatra packed with a ORM and backend.
When I then looked into Rails again (years later) everything felt so natural and right suddenly. However beginner documentation also got a lot better so this was surely part of it.
I’ve been really happy splitting the difference between rails style server side rendering and full client side JS apps using Django. I can easily build REST or GraphQL endpoints for client side web apps to consume, but I have the ability to easily render out server side templates for more lightweight pages. Add to that that the python ecosystem is great for data science / data engineering tasks so it’s easy for developers with different backgrounds to cross over / reuse data model code between projects/tasks.
I believe we are at a turning point for the future of web apps and servers. After using Firebase and serverless (I hate this term) technologies in the last few, I didn't miss doing all what's said in the blog at all.
Need authentication? Just turn the feature on in Firebase and use it. Need storage? Need analytics? Just do the same. The future is bright and we are heading in the right direction. With this, we can get started on our apps with zero configuration and just focus on features.
I could never get into Rails because of all the magic. “It just works” doesn’t cut it for me, if I as an engineer, can’t understand exactly what’s going on under the hood.
After Rails' memory usage, I would say that the "magic" is the worst part of Rails. Wish I could have Rails, except a bit more explicit.
That said, with pry, it's pretty easy to dig down into the "magic" and see wtf's going wrong when something is borked.
Despite that minor grumbling, I'd say that Rails is still darn good! It's very mature framework (or perhaps more accurately, collection of frameworks) at this point. You can get stuff done quickly.
Most things really don't need to be SPA, and many (most?) don't need to serve up more than a few hundred or a few thousand responses per core per second.
Here's how i replace Rails with the "modern stack":
- Compile Graphql schema into Typescript typings + Fragments for "Active Record"
- React Hooks as controllers action.
- React Suspense for HTML rendering.
- Apollo for graphql caching
- ExpressJS for middlewares.
- @reach/router for routing.
- @loadable/component for code splitting.
- Serverless for API.
I missed Rails, too. But i found that the "modern stack" is not bad at all. It just needs more time to investigate to find out the best way to reuse features.
Your post is a perfect example of why the "modern stack" is a horrible developer experience (and lets be honest, probably crummy user experience) compared to Rails.
I hope the DX will get better soon. But this stack beats rails on scalability, universality, user experience, and many more. It's a trade-off that i found worth the effort.
This sounds exhausting! But I'm betting there's some pretty solid benefits or you wouldn't do it. Could you expand on why someone might pick this a little?
I guess this just seems like a massive amount of hoop jumping that, from the outside, looks like OCD levels of premature optimization for future demands that might well not occur.
Put differently: how much more time and energy would you have had to work on your MVP if you had just used Rails?
Actually, the time spent to setup correctly all the toolings is much more than the MVP itself.
The ratio is about 6/1.
Once setup, it took me about 1-2 weeks to complete a MVP.
Want new feature ?
- Add a graphql API (if not exists) and compile to Typescript typings.
- Develop and deploy a React Component for that feature.
Let’s talk in 6 months as those packages evolve and diverge. While rails core team does the work of maintaining all the packages as a consistent whole.
You can’t “take care of it with responsibility” if you have a lot of dependencies since you don’t control the library’s maintenance, or how it evolves with other libraries. So then you have to chose between adding dependency (with very real maintenance downsides) vs writing things yourself and reinventing things that should be solved.
Further, being stuck in a box also means that the community can rely on that very box and add more extensions with the architecture of the box in mind. A box gives assumptions to build on top of. Sure if you really really need a triangle it’s painful, but then you should ask, do I really need a triangle?
I think the real insight of DHH is that most web apps are not as “unique” as developers would like to believe and that the harmony that comes with conventions, the speed that comes with a unified end to end integrated system, and the focus developers gain for actual impactful choices when many unimportant choices are made for them is an amazing improvement.
He said recently, that insight is as controversial today as when he launched rails, and he is surprised more rails competitors haven’t emerged.
I think the first end to end GraphQL > Single Page App framework that has a similar level of integration to rails will dominate.
Actually, this stack is deployed as a serverless function !
"Serverless for API" means i could use any language to develop API.
Serverless provides better scalability in my opinion.
> There’s no longer a standardized way to get user accounts with a login/signup, [...] so instead we need to spend days rewriting this functionality anew on each project
I don't think that ever existed "THE standard way" to build web applications. At the same time Rails was trend, for a lot of people the "standard way" to build web systems was write it from scratch in PHP.
I think one big mistake rails did was to tightly couple view side with server side. This made sure tight coupling. If rails had a layer in between controller and html (with a dumber html templating), with this middle layer either spitting html or json apis, we would not need to get rid of rails
I too find react etc too complicated for a simple crud kind of app. Rails was much faster to achieve the same.
> The world of tech moves fast, and there’s always new frameworks and paradigms popping up that make developers’ lives easier and allow us to build more and more powerful applications.
I wish people didn't start their posts with such proclamations. Why can't one just go ahead and criticize something without first giving it a compulsory doze of praise.
I look forward to a comment section filled with passionate developers rejecting the author's premise, and pitching their favorite framework(s) as proof...
Thereby validating the author's premise that "the majority of the problem is just a result of fragmentation in the modern ecosystem."
>nodejs / typescript graphql backend and React / Apollo on the frontend.
So uh... I run a Rails / graphql backend and React / Apollo frontend. It's not perfect, but I still think it's easier than running a complex node backend by an order of magnitude.
sure, you will miss rails if you are still working on monolith development model (which is still valid in many cases) or if you want to have your Ruby developers who can also do frontend work.
These days, frontend has advanced so much that either you are a minority who is truly full stack and can do both backend and frontend work in good competence otherwise, frontend has become a separate profession altogether and for good reason -- it not only requires artistic capabilities, but it requires good amount of coding now with plethora of frameworks/modules.
Rails is a great framework no doubt but advent of React/Angular along with rise of microservice-oriented architecture has limited the footprint of rails in job market.
Rails is awesome! We’re hiring Rails devs in 2019 for our startup in Seattle. We found a good balance of React and Rails. https://www.sharegrid.com/careers
Ruby on Rails out of the box gets a lot of bad rep for being slow and non-performant. Has anyone replaced MRI with JRuby or TruffleRuby to mitigate that? Were there any significant "gotchas" with integrating it?
I did a POC getting a monorail running on JRuby (probably 6?) years ago. It wasn't for performance reasons (though we did have some GC issues, which JRuby might have helped). It was because we had to integrate with some services which only vended APIs via JARs.
The biggest dealbreaker was that (like most Rails apps) we had a ton of gems, some of which had native extensions. JRuby doesn't support C native extensions.
In the end, it was way easier (and a much less risky change) to spin up our own Java REST APIs in front of those JARs, and let our MRI Rails app integrate with them by talking to those REST endpoints.
Just for fun, I also tried using dRuby so an MRI Rails app and a small JRuby (non-Rails) process could communicate idiomatically. It was cool, but I'm pretty sure dRuby was eventually deprecated.
Been following TruffleRuby, I did recently just spin up a super dummy app where I swapped out mysql to postgresql, made a migration to create a table and generated some fake data. Opened a console and ActiveRecord was able to query. Thats a big step forward as they had said the ActiveRecord connections were some of the biggest hurdles.
Does this story answer your question about performance? Not really, but if I wanted to dive deeper (which I do at some point!) I think TruffleRuby is a real option.
Not sure why everybody nowadays rule out Rails (or Django) like frameworks. Not every web app need to be an SPA only! There are multiple kind of web apps which I would still start with Django today!
8 years in to my programming career, I still LOVE Rails. No other framework I've come across lets me do as much quality work in a short space of time as Rails does.
Groovy and Grails are still around but probably not as big a push anymore.
I would highly recommend JHipster to bootstrap a new Spring Boot app. It does monoliths or microservices and gives you a great scaffold to build on top of.
Absolutely! There's a big 4.0 release happening soon as well that includes micronaut integration. Furthermore, there are profiles you can start with today that let you create a react, angular, or vue SPA app powered by the grails back-end. Add the fact that it's a spring boot app as well and you get an incredible library of resources available to you. We've been running our app in production with relatively few developers.
> Absolutely! There's a big 4.0 release happening soon
Virtually no-one's updated from Grails version 2 to version 3, or released any plugins for version 3, so it's hard to believe anyone's interested in a 4.0 release.
The more modern take on it is micronaut [1]. It's a good fit if you are building a SPA + REST API style app, but want the plugin / addon style ecosystem of grails / rails.
> "Now, I know Rails isn’t universally beloved by developers, and I’m not suggesting that we give up React and es7 and go back to writing server-templated web-apps like it’s 2012 again."
Why not, exactly? It worked well then and it works well now. Not everything needs to be some 10MiB javascript bundle delivered to a late-model version of Chrome served from a static bucket.
There is opportunity for a rails like framework in Typescript and React Hooks which is server-side first.
A lot of the js/react frameworks are rich, client side ..which need a little more conceptual thinking than a server side rendered framework like rails (because you get into unnecessary complexities of API,graphql,her,etc).
The other thing that's missing is db migrations - typeorm has decent migrations, so that can be leveraged.
I believe Firebase + React is actually that. Yes, it's buying into a proprietary system, but it is so productive working in that. Database is taken care of, file uploads, authentication etc. are all taken care of.
It's not comparable to Rails in that we can't have plugins to install new things that work with the entire stack, but whatever we have initially is really good and I feel makes me very productive
There are tons of JS stacks that exist right now - Sails, Adonis, etc. - but I feel they all miss having a hugely profitable business using them in production. Rails had 37signals use it for all their products - along with having DHH too.
Right now you have FRAMEWORKS being used in production at big companies, so if you use React, Angular, etc. you know that you're in good company. I think it would be super interesting having a large company roll out a full stack JS framework that they themselves use.
This reminds me of the Rich Hickey keynote talk[1] at Rails Con 2012. Which boils down to: just out of sheer convenience you no longer own your code and, don't make the easy choice, take your time and make the simple choice.
As a front-end developer I hated Rails, every day was a struggle working with the project, it was so slow. It was around 4 years ago and I was using top of the line Macbook Pro.
Our project wasn't badly written, it was just that slow. Is it better today?
I somehow ended up working with PHP-based back-ends but for smaller projects and I sometimes miss Rails, because Docker for Mac...
You'd have to start by defining some things. Are we talking about AJAX request/response cycles being slow? Are we talking about SSR request/response cycles being slow? What was the app doing, CRUD? Something more interesting?
For reference, the Rails app that I am working on, almost literally right now, is responding to HTTP API requests, performing authentication and resource authorization, creating a background job (or 2 or 3), and posting an event to kafka, in 2-3 ms. This is on my work-issued dev laptop from 2016.
If I start hitting the SSR portions of this same app, I'm getting response times in the 70-80ms range pretty consistently across the 6 or so pages that I just hit to get a quick baseline. No front-end frameworks here. Just turbolinks, ERb, HTML, CSS, and sprinkles of ES6 (served via webpack(er)).
Here's the thing about performance: even "well written" code can be unperformant.
It could be a query that isn't optimised with an index in the db, it could be best practice code that doesn't work well in the context of your app, any number of things.
At my last job we had a page that looked to be very well written, but it was taking 30+ seconds to render the page. Turns out to be a method we were calling 10x too many, because someone had benchmarked it in isolation and it didn't have any performance impact. However in conjunction with some of the data that occasionally passed through that method, those 10x calls ended up being a couple of seconds each.
That's an extreme example but there's little things you can do everywhere on a rails app if you know what you're looking for, and I would expect this to be the case in any web framework.
have you tried Dinghy? Docker for Mac is exceptionally slow on OSX. i advise everyone to stay away from Docker for Mac and install Dinghy w/ xhyve instead.
Oh gawd, not another one of these articles. I appreciate what the author is trying to say, but the premise is just all wrong.
Repeat after me: Rails Is A Modern Web Stack. Seriously. You can do everything you might imagine needing to do for a modern web app:
Need an easy way to create server-side rendered (SSR) pages that still behave in a performant, snappy manner like all the cool kids? ERB + Turbolinks 5 is a powerful combo.
Need to ratchet it up a bit with dynamic interactivity? Slap some Stimulus on that SSR puppy!
Still not "modern" enough for you? Use React! Or Vue! Keep Rails operating just as a JSON-flavored REST API.
Need to push commands from the server to multiple clients at once? ActionCable to the rescue.
Need to offload long-running tasks to background jobs? ActiveJob + Sidekiq is the bee's knees.
At any rate, plenty of us are developing "modern" web apps and sites using Rails, Webpack, and other cool frontend tools, and it's going quite well. I don't feel in the least like I'm missing out on something amazing or obvious by sticking with tried-and-true, stable tools that have been my bread and butter for 11 years and counting. DHH's philosophy of web programming may not appeal to everyone, but for many of us, he continues to a voice of reason in an insane world.
I never liked Rails even when it was hip. Way too much bloat and magic behind the scenes, and also poor performance because of that.
I always preferred Flask, because it gave you a minimal framework, allowing you to cherry pick modules as needed. Sinatra looks similar if your preference is Ruby.
I cannot say that a Node stack is better though. Both Rails and Node are fairly awful, but for entirely different reasons.
When I first started with Rails/Ruby things felt magical. There is still definitely a little magic, but with time I've found it to be less so.
Usually all it takes is to lookup the source (which is well commented/documented) to see where the magic is coming from, the code is fairly easy to understand. If it works well use it, or take what you like/want and write your own methods, classes etc.
I learnt to program for the Web in the late 90s. I used perl and later php. I stopped in the early 00s because I found supporting IE6 was soul destroying. Much more recently I got into it again and saw things like Rails and Django and was amazed. It was like stepping in a time machine and seeing what I always thought web development should have been. But the whole node, react etc. model is nothing like that. It's a regression as far as I can tell. It just makes everything more complicated for little benefit.
You're in luck. Rails 5.2.3 was released 20 hours ago.
More seriously, I feel rails is still excellent and I'm happy to work with it every day. I'd be interested to hear more about what makes rails not modern? I find it a very productive framework.
EDIT: If you're talking about missing a JS equivalent of rails, do you know about Loopback? https://loopback.io/