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.
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.
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.
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.
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.
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.
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
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 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.
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.
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.
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
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.
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.
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.
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."
> 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.
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.
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.
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.
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....
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'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.
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.
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
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.
> 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.)
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
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.
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".
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.
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.
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 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
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!
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.
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.
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.
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
> 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...
> “...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.
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.
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.
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.
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 :).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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?).
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.
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.
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
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?
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/
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.
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!
> 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.
>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.
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.
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.
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.
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.
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’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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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'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 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 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!
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...
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 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.
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.
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...
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.
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.
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.
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.
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...
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.
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.
521 comments
[ 0.24 ms ] story [ 296 ms ] threadSysgears has some other projects that is moving towards the ability to import functional modules from npm
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.
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.
It’s not perfect yet, but as a first version is remarkably capable already.
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.
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.
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.
One of the frequently overlooked properties of Javascript/Node is that it's async-everything.
I'd be curious to hear more about this benchmark.
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.
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.
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: 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.https://github.com/eventmachine/eventmachine
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.
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.
If we're being fair, what you say is true only if you are starting a greenfield project.
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.
Thereby validating the author's premise that "the majority of the problem is just a result of fragmentation in the modern ecosystem."
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/
https://groups.google.com/d/msg/django-developers/mLlWYEC8_G...
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.
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?
https://www.djangoproject.com/weblog/2016/sep/09/channels-ad...
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”.
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....
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.
Symfony 4 however is wonderful, they modularised everything, kept backwards compatibility, properly deprecate things and it's fast, like really fast.
Yes they don't follow semver but a modified version of paradigm.major.minor
Lazy loading in Rails tends to refer to how Active Record waits until access time to send the query: https://rubyinrails.com/2014/01/08/what-is-lazy-loading-in-r...
It's still synchronous.
Both do quite a bit better for cleanliness and setup time than any of the other platforms I’ve used for web development.
...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.)
It depends on how big your project is. If you only have one developer it's fine to have to it tightly integrated.
Given the insecurity without huge token authorization, I'm not entirely surprised.
They can try again when they figure out encrypted and variable token creation.
> 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
Loopback 4 seems to be the same team, but I believe they have learned a lesson on coupling. https://loopback.io/doc/en/lb4/Crafting-LoopBack-4.html
> Models are overloaded with multiple responsibilities, such as data representation, persistence, and mapping to REST.
They have a way to go to reach feature parity with LB3: https://github.com/strongloop/loopback-next/issues/1920.
BTW, I also miss Rails.
Not that i don't know how to write SQL queries by hand, it's just raw SQL queries with conditions is just ugly.
https://knexjs.org/
https://sailsjs.com/
Unless there have been some major changes I highly advise staying away from sails.js.
1. https://github.com/balderdashy/waterline
2. https://hapijs.com/
Related: https://dev.to/imthedeveloper/comment/2615
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
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.
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.
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.
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.
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
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...
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)
while gmail brought a nicer ui/ux, i still credit ms owa for showing the world what js could be when it grew up.
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.
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.
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.
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.
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.
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.
Concurrency in this situation almost becomes free at the expense of changing
to 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:
Or starting one async early, waiting on another, and then ensuring that the first async thing is done later on: And once again I think this is the a great example of a useful abstraction when writing anything with an I/O boundary: 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.
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.
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.
It's not perfect by any means, but I think it shows the shape of things to come.
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.
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.
We had a discussion about Ruby's type annotations 4 years ago at https://news.ycombinator.com/item?id=9481186
I found it by googling the status of the work on Ruby 3 type annotations. The top comment is mine and I still agree with the past myself.
https://github.com/ChangJoo-Park/amber-realworld-example-app...
(I couldn't find any code snippets on the official Amber framework page, I hope this is representative.)
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.
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.
https://sorbet.run/
Stripe have been working on a type-checker. No idea when they're going to release it to the public though.
(but yeah, ActionCable was a no-go. We use Pusher instead)
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.
So, Python has the ton of data science libraries, and it also happens to have Django...
http://kemalcr.com
https://nuxtjs.org/
https://laravel.com/
http://taffy.io/
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?
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!
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.
[1] https://typeorm.io [2] https://github.com/typestack/routing-controllers
The whole thing he explains in the post: he wants an all-rounder like Rails but which covers the SPA/JS side.
For folks here doing startups, imagine the speed boost of maintaining one less entire application than your competitors.
Everything more than that just feels to much like having multiple code bases.
But I suppose that DHH got burned with Prototype and then CoffeeScript and wouldn't endorse something like this.
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.
Now, which
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.
"The Rails 5 Way" (1088 pages)
"Ruby on Rails Tutorial: Learn Web Development with Rail" (816 pages)
Rails is enterprise.
Do we only use undiscovered indie frameworks now?
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.
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.
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.
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.
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.
All of this just soured me on "enterprise."
This is a great summary of much of the frustration of using Spring.
https://en.wikipedia.org/wiki/Ruby_on_Rails#History
Start with Rails and optimize in Go for the services that get expensive to run in Rails, like https://gitlab.com/gitlab-org/gitaly
I'm not sure how a combined framework for server and client side would work.
It already has impressive code generators for GraphQL.
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.
I just don't know :)
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.
I'm stoked about the potential of live view and I'm curating a list of demos of things built with it: https://tefter.io/zorbash/lists/phoenix-liveview-examples
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.
https://twitter.com/i/web/status/1111641314955849728
[1]: https://www.youtube.com/watch?v=rI8tNMsozo0
Having tasted the joys of static type checks combined with a unified front/back data model, IMHO, that’s unthinkable.
Would you mind elaborating on the specific benefits?
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.
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.
If I never have to explain <!-- ko if: !condition --> vs <!-- ko ifnot: condition --> again, I'll be a happy man.
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!)
How do you get that? Are you using GWT?
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.
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.
Actually I have gone back to server-template development using Django for selected projects, after many years working with React, which I still love.
Server side templated development with Django can be extremely fast in terms of development time, very direct and effective.
There no need to use React for all the things.
Sometimes React is the right tool, sometimes server side templated is the right tool.
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.
There is a JHipster Kotlin blueprint that generates the backend code with Kotlin instead of Java. Can't wait to use it.
I hate it but I'm no Java expert.
[1] http://micronaut.io
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.
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:
https://hnprofile.com/
Works like a charm!
I even recommend Rails to new people starting out because I think it sets best practices.
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.
More like 40; it's from late 70s Smalltalk.
http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html
Then what is the abstraction that you think it should replace it?
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.
And if you pick a neat tech provider and it goes belly up (like Parse!) you’re in some real pain.
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 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'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.
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?
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.
Then again not everything I work on has to do with web or API’s so maybe that colours things a bit for me.
I think I know exactly what you’re saying and I agree. Also no less the hypocrite here, but like WW said “I am large, I contain multitudes”!
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.
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?
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.
[1] https://gitlab.com/tombert/frameworkeyPromiseEdition [2] https://gitlab.com/tombert/Frameworkey-Erlang
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 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).
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!
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...
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.
Is it that we need to offer offline clients to meet user expectations?
Better raw performance on the front end?
Cheaper server costs or easier to deploy serverlessly?
For the progressive enhancement of your resume?
https://youtu.be/SWEts0rlezA?t=203
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.
Moreover, no one stops you from separating concerns on the server side.
I’m not sure if the 20 extra client/server roundtrips increase raw performance though.
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.)
This is my feeling too. Composition and JSX beat logic in templates.
Though I've seen some pretty hairy React, I still prefer it to badly implemented template files.
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.
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.
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.
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...
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)).
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.