[HN Gopher] Why we're sticking with Ruby on Rails
___________________________________________________________________
Why we're sticking with Ruby on Rails
Author : lutrinus
Score : 156 points
Date : 2022-07-08 11:47 UTC (11 hours ago)
(HTM) web link (about.gitlab.com)
(TXT) w3m dump (about.gitlab.com)
| vassilevsky wrote:
| It doesn't matter what the backend is written in. What matters is
| user experience. And GitLab's problem is a total lack of any
| usability. Bloated and full of inconsistencies.
| HansLambda wrote:
| I don't see any reasoning for Ruby or Rails, just why they are
| sticking to a modulith rather than decomposing into
| (micro)services.
| whynotkeithberg wrote:
| what I hear here is "i've never worked with an actually complex
| application built over a span of decades + & have no idea what
| it takes to make it into a microservice. I also believe
| everything I read on every article so every single persons
| application must be as simple as mine to deconstruct"
| oxff wrote:
| > You need a fairly sophisticated DevOps organization to
| successfully run microservices. This doesn't really make a
| difference if you run at a scale that requires that
| sophistication anyhow, but it is very likely that you are not
| Google
|
| Correct. Don't use tools aimed for Google levels of complexity if
| you're not dealing with Google levels of complexity.
| pid-1 wrote:
| That said, gitlab.com itself runs on K8s.
| mooreds wrote:
| k8s isn't only for microservices. You can containerize up
| normal applications (12 factor or otherwise architected) and
| run them on k8s.
|
| Is it a good idea? Depends.
|
| On the plus side: You have one underlying runtime and
| orchestration layer, with a lot of useful primitives
| (including and especially around deployments).
|
| On the negative: You introduce yet another layer of
| complexity and abstraction.
| Spivak wrote:
| You just described the counter to "don't run things
| designed for Google if you're not Google."
|
| The real advice is "don't run stacks that make trade-offs
| or give up guarantees to be able to scale to a size you're
| not at or solve problems you don't have."
| prescriptivist wrote:
| The systems in kubernetes for horizontal auto scaling are
| extremely nice and work very well for our large monolith.
| At this point I can't imagine deploying any system with
| significant batch or online workloads any other way.
|
| We switched to k8s early on in the company and that
| little bit of work to get it operating with HPAs, etc has
| paid off in dividends over time.
| james_marks wrote:
| jchw wrote:
| "Don't use tools aimed at Google levels of complexity" is a
| take that has become quite popular, but it's definitely lacking
| nuance. Tools are pretty multi-faceted and rarely have a single
| selling point. For example, Kubernetes solves a whole boatload
| of general service orchestration problems in a unified way;
| perhaps it's true that you only ever _need_ this at Google
| scale, but you can certainly benefit from it at almost any
| scale where it runs. (Which is a lot. k3s is pretty light.)
|
| Does that mean you should write microservices for your toy?
| Probably not. But the trade-off calculus for microservices is
| not scale. It is a lot of things. If you had an application
| that was extremely trivial to run as decoupled services, and
| the boundaries between them are not liable to change much,
| maybe you really should use microservices from zero, and
| benefit from better failure isolation among other things. But
| yes, probably not.
|
| Still, I think the idea that microservices are not really a
| great idea is a flimsy justification for Ruby on Rails in
| general. It's fair enough to say that if your language,
| framework and library choices are working for you and your
| product, you aren't beholden to justify them really. That said,
| that doesn't mean they couldn't be better with different
| decisions, and it's sincerely hard to determine that.
| Sometimes, I get the feeling that articles in this vein are
| just as much about convincing the authors that they made the
| right choice as it is convincing anyone else. But it's not
| really that important, since I don't really feel you actually
| need to convince much of anyone, if you like your decision.
| projectazorian wrote:
| > Sometimes, I get the feeling that articles in this vein are
| just as much about convincing the authors that they made the
| right choice as it is convincing anyone else. But it's not
| really that important, since I don't really feel you actually
| need to convince much of anyone, if you like your decision.
|
| They don't need to convince us random HN readers, that's
| true.
|
| But they do need to convince new hires, potential clients,
| and internal stakeholders that Rails is still the right
| choice. If you've ever worked on a large Rails SaaS app you
| know this subject comes up a lot.
|
| Now when the subject comes up they can just send folks a link
| to the blog post, it's very convenient to have around for
| this purpose.
| vinceguidry wrote:
| Slight correction, you can't run tools aimed for Google levels
| of complexity because Google doesn't release the tools they use
| to handle their scale. They don't use k8s to manage their
| infrastructure, they use Borg. K8s doesn't scale to Google's
| needs. Also, nobody's running at Google scale.
| ezekiel11 wrote:
| serverless environments do not carry the devops overhead
| involved with kubernetes or other container orchestration.
| tmp_anon_22 wrote:
| For non-trivial workloads serverless does still require a lot
| of orchestration and domain knowledge of cloud-specific
| features and constraints. Kubernetes is for sure its own
| beast, but its a ton of work regardless (for gains that at
| the end of the day aren't what you thought they would be...).
|
| Serverless is amazing when you use it the way its intended.
| Its not there to replace your entire ec2 workload.
| ezekiel11 wrote:
| your assessment would've been correct 3 or 4 years ago but
| there's just no need to scaffold ec2, mysql db inside a
| vpc. You can upload your environment via docker and start
| serving serverless. You can then use serverless db that is
| 90% cheaper and far less hassle than scaling up or down ec2
| instances/rds, configuring vpc, setting up nat gateways etc
|
| my view is that if you are not on serverless, you are
| wasting resources that could otherwise been dedicated to
| building out domain knowledge
|
| our team focuses on optimizing each function and less on
| devops/scaling. the plumbing work is gone and all we do is
| now translate business requirements. security concerns are
| also largely removed.
|
| its a great time to be on serverless, it had to overcome
| lot of doubt but it is here to stay. no need to pay $5 /
| month either for your weekend projects. even if your
| project hits front page, it will still work, the billing is
| not even that bad for what you are getting.
| mooreds wrote:
| > serverless db that is 90% cheaper
|
| > building out domain knowledge
|
| What about all the knowledge that is contained in
| applications, services and libraries that run on RDBMs?
|
| I'm serious, one of the reasons I shy away from
| serverless is I want to put together components at a
| higher level than functions. But maybe I'm missing
| something?
| reducesuffering wrote:
| What serverless hosting are you using? What tech stack do
| you run on it?
| ben_jones wrote:
| > configuring vpc
|
| What advances in Serverless platforms like AWS Lambda
| prevent the need for configuring VPCs?
| lolinder wrote:
| How do you configure your serverless environment? I set up my
| company with ECS a while ago, and in order to get the config
| into version control I had to put together a somewhat messy
| collection of bash scripts that use the AWS CLI to push up
| JSON config files. I couldn't find any standardized way to
| configure the whole environment: at least at the time, it
| wasn't possible to do everything in CloudFormation.
|
| I haven't gotten into Kubernetes at all, but from what I've
| heard the bespoke-bash-scripts problem is largely solved in
| that world, so I've been toying with exploring it for our
| next project (still hosted on Fargate).
| dabeeeenster wrote:
| ECS fargate is a great platform but the API interface to it
| is pretty bad. It's such a shame.
| Sparkyte wrote:
| This is why I hate articles that justify the lack of
| scalability with their execuses to justify complacency.
| bovermyer wrote:
| I feel like I've read this before July 6th. Is this a repost or
| something?
| MatthiasPortzel wrote:
| Looks like it was previously posted on a different site and
| only posted to the GitLab blog July 6th.
|
| https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
| philliphaydon wrote:
| https://about.gitlab.com/blog/2018/10/29/why-we-use-rails-to...
|
| You're prob thinking of this one.
| hoppyhoppy2 wrote:
| https://news.ycombinator.com/item?id=31726825 posted 24 days
| ago was the same article as today's post.
| philliphaydon wrote:
| Thanks for the correction.
| pxeger1 wrote:
| Found it: https://news.ycombinator.com/item?id=31726825
|
| It was by GitLab, but not on their own site:
| https://thenewstack.io/why-were-sticking-with-ruby-on-rails-...
| Sparkyte wrote:
| Nothing wrong with using Ruby, but if this is a justification
| build something that doesn't scale you're incredibly wrong and
| complacent. Scale creeps and when it creeps it quickly takes
| over. You should always build infrastructure with scalability in
| mind from day 1. If you're writing in Ruby it shouldn't matter if
| you container it, but what surrounds that application is what
| matters. It also matters if you build a monolith or not.
| kinduff wrote:
| The hardest part of using Ruby on Rails is hiring, in my
| experience and opinion. There are lots of Ruby developers, but
| there's a lot more with experience in other languages.
| TheRealDunkirk wrote:
| That's the beauty of it. You need less "experience" with Rails
| because it curb-stomps Javascript for productivity.
| EduardoBautista wrote:
| I disagree. It is much easier to make big changes, especially
| refactors, using a language such as TypeScript. The amount of
| `undefined method 'example_method' on NilClass` errors in
| Ruby on Rails projects is astounding. After working with a
| typed language on the backend, I am confident it is easier to
| more quickly ship correct code with a typed language, while
| Ruby on Rails makes it easier to quickly ship incorrect code.
| jaredsohn wrote:
| If you don't have static typing, you just need to make sure
| you have good test coverage. I work in ruby/rails and don't
| run into this problem.
| triyambakam wrote:
| Sounds like a lot of extra work.
| quesera wrote:
| Static typing requires good test coverage too.
|
| Tests confirm correct results. The fact that they also
| confirm expected types is a free side effect.
| TheRealDunkirk wrote:
| When I had to work on Java/Javascript, I had to fallback to
| using `any` so often, to get the compilers to work, I gave
| up on the idea that strong typing is useful. Maybe it's
| fine for simple types, but trying to pass non-trivial
| structures around was way more trouble than it was worth.
| projectazorian wrote:
| I think Rails is great and it makes sense for most companies
| established on it to stick with it.
|
| But for individual engineers, going all in on Rails is likely a
| poor career move, in the US at least. It's rapidly becoming a
| commodity skill and salaries seem stagnant.
| revskill wrote:
| I think people think about microservice because they themselves
| failed to achieve modular monothlic.
| giancarlostoro wrote:
| I think it can have its benefits but I don't think it should be
| your entire application. I know some people swear by it, and if
| that's what works for them and keeps them profitable, you know
| what? Go for it.
|
| I think serverless is fantastic on the other hand[1]. I had a
| web application where I was parsing shapefiles to then import
| them into SQL Server. These files could be massive and take
| longer to process than they took to upload. As a result I
| figured that it might make more sense to create a serverless
| function in Azure to parse them once they were uploaded to blob
| storage. This was very easy to implement and transparent. If
| you are using something like Azure and want efficient ways to
| process your data without doing it all in your monolithic
| application and blocking your users, or creating a thread in
| the background which makes me a little uncomfortable, then
| serverless is a godsend.
|
| I think Microservice architecture if I had to pin where it
| might make sense would be for APIs. I would then emphasize on
| versioning each microservice API. If you do a microservice
| architecture for APIs you can update parts of your API without
| taking the whole beast down (unless you use something like
| Erlang or slots in the case of Azure Web Apps, where it
| forwards new requests to new slot). I think this might be a
| reasonable use case for microservices. For a normal website
| though, I think monolithic with some serverless helper
| functions (if needed) is probably good enough otherwise.
|
| [1] Note: Let's not confuse microservices for serverless,
| because it's not necessarily the same thing, although some
| people use serverless to achieve the microservice architecture,
| serverless functions can do so much more!
| jfabre wrote:
| It always baffled me to hear:" Oh we're gonna do microservices,
| because our monolith is a total mess and we're very
| unproductive". If you can't organize a monolith, what makes you
| think you will be able to organize microservices which are
| vastly more complicated to work with. How about you learn as a
| company the proper skills and habits to achieve logical
| modularity within a single process before you try doing that
| with multiple processes.
| jfabre wrote:
| And I would also add:
|
| The reason your monolith is a mess is because your
| organization has low standards on code quality and doesn't
| value it. It is not willing to invest in it, and probably
| your department didn't acquire the skills and habits to
| produce clean code in cheap manner. The developers who are
| used to good code usually leave you out of frustration. No
| one likes to be unproductive, especially productive people.
| gitfan86 wrote:
| "productive" means shipping code to these people. They are
| trying to minimize how often someone says "we are blocked on
| deploying that code"
| jfabre wrote:
| You would need to provide me with a concrete example,
| because I've never really had the issue you're describing.
| I'm willing to bet it's fixable by having better
| management.
| vore wrote:
| Assume you're having to ship a large single release
| bundling the code of multiple integrating teams: a bug in
| one of those teams' code will likely delay the release of
| the entire bundle: bugs are inevitable and no amount of
| better management will solve them. With microservices,
| you add coordination overhead but teams have more
| autonomy in shipping their own individual bundles.
| NortySpock wrote:
| I must be missing something:
|
| 1) if you have a blocking bug or code dependency between
| two microservices OR two monolith modules, that should of
| course block until it is fixed and resolved.
| Microservices do not magically solve that.
|
| 2) other code changes or features that are not blocked,
| can be unblocked by being released in a smaller release (
| git rebase those commits to a new release branch on main,
| and cut, test and deploy a smaller release -- basically
| gitflow)
|
| 3) once the blocking modules are fixed, they should be
| rebased onto the latest main.
|
| The blocking "effect", even in a monolith, seems like it
| would be better solved by using a version control system
| with good rebase support.
|
| Coordination needs to happen for larger changes, and/or
| the changes need to be smaller.
| arwhatever wrote:
| I'm probably the last person on here to discover
| https://grugbrain.dev/, but I like the particular quote:
|
| "grug wonder why big brain take hardest problem, factoring
| system correctly, and introduce network call too"
| [deleted]
| gitfan86 wrote:
| The big advantage of microservices is organizational not
| technical. You can hire teams and tell them that they are
| responsible for an API that receives specific data and should
| return specific data. These teams can operate independently.
| You don't have to force all the teams to use the same language
| or dev process. That could be good or bad depending on the
| circumstances, but at least you have the option with
| microservices.
| quickthrower2 wrote:
| Do you need services though to achieve this? How about
| libraries?
| adra wrote:
| Libraries are great, but you can't deploy new versions of
| library without needing to step on toes. If your dev teams
| are just "shove this at ops" and done, then it may not make
| a difference, but if you need to be responsible for the
| code running in the real world, just library segregation
| doesn't cut it.
| magicalhippo wrote:
| I'm being dense it seems, because I don't see what
| microservices brings to this. What's the fundamental
| difference in this regard between shipping an executable
| with a bunch of dynamic libraries, and deploying a bunch
| of microservices?
| quickthrower2 wrote:
| I can't get my head around that though.
|
| I agree to split into services where "you'r have to do
| that anyway".
|
| But adding services where part A of the monolith needs to
| use part B where a library would do the job seems odd.
|
| If you are trying to solve a specific scaling issue, then
| sure, but this is rare.
| ironmagma wrote:
| All those things are quite achievable with a modular
| monolith. The API is the module.
| windows_sucks wrote:
| yeah but deployments and language choice are no longer a
| single teams choice now. microservices really do allow for
| a "we did our job" development
| ironmagma wrote:
| Language is always brought in as a "pro" for
| microservices. I would call it a "con." Fragmentation
| across languages can be a big problem if your business
| logic is complicated; suddenly you have to link against
| code written in another language, or worse, rewrite it.
| cdavid wrote:
| That's the theory. What I've observed is that that companies
| who cannot achieve modularity w/ monolith are often the same
| ones incapable to achieve modularity w/ MS anyway.
|
| So now you have in practice is a distributed monolith, with
| brittle, ad-hoc dependencies between services. A symptom is
| that most features require touching many MS.
| giancarlostoro wrote:
| Yes, and in some cases, maybe you really need some crucial
| python library but the rest of your systems are in Go, and
| maybe you discovered a new library that does exactly what you
| need, in a third language in the most efficient way possible,
| you can embed a microservice into the mix. I think though, it
| is usually best to hire for one common language as much as
| possible, this way your team can jump across projects if the
| need arises.
| whodidntante wrote:
| What about basic business functionality, for example, a
| function to create a site URL, which can be quite complex,
| and which would be very time consuming and complex and a
| maintenance nightmare if implemented in multiple languages.
|
| You could, of course, create this as a service. And then make
| possibly hundreds of calls to this service to generate a
| single web page.
|
| Or, you can provide a library that does this, and the calls
| are cheap, reliable, and predictable.
|
| Of course, if it is a service, the caller would locally the
| cache the information needed to make all the calls, do a
| batch call to the service, and then backfill in all the
| links. This then precludes generating and sending the page as
| you go, and creates the possibility for an explosion in
| complexity if a simple change in requirements that causes the
| arguments for the URL generation to be dependent on another
| service/library call.
|
| Not everything should be a service call.
| devoutsalsa wrote:
| But they can't work independently. Unless your micro service
| operates in a vacuum, it's sending generating messages that
| will be consumed by other services. All of that communication
| requires a lot of frikkin' work. You need to maintain API
| documentation, update client libraries, remove garbage
| messages from the queue, coordinate deployment schedules, and
| all sorts of other crap. If you have FAANG level resources,
| maybe you can mock out & automate everything to the point
| where you don't need to worry nearly as much, but that's a
| monolithic effort (pun intended).
| Lio wrote:
| The downside to that is that if you get the factoring of the
| app wrong you now have to refactor across disparate codebases
| separated by network calls.
|
| It's much easier to start with a monolith and refactor it
| into microservices later than it is to refactor microservices
| written in different languages by different teams into a
| single codebase.
| fleddr wrote:
| The big disadvantage of microservices is also organizational.
| Barrin92 wrote:
| This isn't a good idea organizationally though. What matters
| is the performance of the system, not the performance of its
| parts, this is kind of a systems 101 lesson.
|
| If you build a car and send each team off to find the best
| parts in isolation and screw them together, you don't have
| the best car, you likely have something that doesn't even
| drive, because the parts don't fit. The performance of a
| system is in the interaction of its parts, not the sum of the
| performance of its parts taken individually.
|
| Teams can never operate independently because it only ever
| makes sense to improve a part if it improves the functioning
| of the entire system. The whole problem with the
| microservices approach it that it optimizes the wrong thing.
| mpyne wrote:
| > This isn't a good idea organizationally though.
|
| It's absolutely necessary for very large organizations
| though. The alternative of trying to centrally plan the IT
| operations of an organization of, say, 500,000, gets to be
| quickly intractable.
|
| Groups try to do it with frameworks like SAFe and while
| that may help a little bit, in the end you need to treat
| different parts of the organization as individual silos
| that are able to control and execute on their specific
| mission set within the wider org. Otherwise the complexity
| of the problem set they're dealing with makes it impossible
| to do anything without breaking other systems or teams.
| BlargMcLarg wrote:
| The main reason I hear when poking more is "so we're not
| dependent on other teams to release our module".
|
| For some reason, I feel this is somewhat of a scapegoat and
| fails in practice. But I don't have enough experience.
| NoGravitas wrote:
| In any case, that sounds like an organizational problem, not
| a technical one.
| iampims wrote:
| Microservices are one way to help with scaling the
| organization, not necessarily the product/code.
| hoppyhoppy2 wrote:
| Discussed a month ago at
| https://news.ycombinator.com/item?id=31726825
|
| And also https://news.ycombinator.com/item?id=32004219 ,
| https://news.ycombinator.com/item?id=31684529
| manchmalscott wrote:
| I was running a self hosted gitlab instance on my homelab, but
| got annoyed with rails (and especially sidekiqs) runaway memory
| usage.
|
| In my own rails projects I've _helped_ mediate this by compiling
| ruby from source with jemalloc, but honestly I don't have the
| mental bandwidth to hack into their whole omnibus thing, so I
| just switched over to gitea instead.
| corrral wrote:
| When I was evaluating options for a self-hosted web git
| service, I ruled out GitLab because I regard such high resource
| use as a serious architecture smell. Just asking for trouble.
|
| Also went with gitea. Runs on a potato. If you have few enough
| users you can stick with SQLite to make it stupid-easy to
| deploy and administrate.
| Spivak wrote:
| Oh hey, another jemalloc user! We just LD_PRELOAD it.
| beardedman wrote:
| All I read was "why we're okay with it being slow".
|
| EDIT: This is also not really a Rails issue per se, but maybe
| architectural.
| andrewmutz wrote:
| Rails being slow is usually not something that the user can
| perceive. Instead, it's just something that increases your
| operating costs (more servers).
|
| For most online businesses, the operating cost of servers is
| small relative to the costs of support, sales, marketing and
| R&D.
|
| So, yes rails is slower, but it usually isn't slow in a way
| that is much of a negative for the business.
| stevebmark wrote:
| Rails costs 2-3x more $ than other servers because of its
| poor performance. I think this is a significant tradeoff to
| make, as well as trading developer familiarity with the
| hardest and most dangerous software to upgrade and refactor.
| Maybe for Gitlab, which is a relatively small and
| straightforward piece of software with limited surface area,
| the sting won't be quite as strong.
| andrewmutz wrote:
| I agree rails costs 2-3x on servers, I just think that
| tends to not matter in a business context because those
| costs are small relative to everything else.
|
| What really moves the needle is R&D effectiveness. If your
| servers cost 2x with rails but your devs also produce 2x,
| that is a trade that is a good one for many businesses
| (especially startups and saas companies)
| ericb wrote:
| > Rails costs 2-3x more $ than other servers because of its
| poor performance.
|
| That's just not true.
|
| The vast majority of time for most web apps is spent in
| database calls. A typical runner up on time spent is remote
| system calls, which, if you accept the monolith tenet that
| maybe you don't need those, are minimised in a Rails app.
|
| If your app does anything meaningful, typically, that
| "meaningful stuff" so massively dwarfs the part of the time
| "in Rails" that worrying about the framework time is
| optimizing the wrong order of magnitude. I base this claim
| on looking at multiple real-world Java, Node, and Rails
| apps in New Relic, and during performance testing. Hint:
| the rails app outperformed both.
|
| Oh, wait--do you mean server costs? If you are talking
| about 2-3x more in servers, perhaps.
|
| Have you compared dev salaries to server costs, though?
| Here again, you'd be optimizing a small cost when you
| should be optimizing the big costs that matter.
| stevebmark wrote:
| > The vast majority of time for most web apps is spent in
| database calls.
|
| Which is why I wouldn't reach for a webserver that can
| only handle one request at a time per process
| andrewmutz wrote:
| Rails can use either threads or processes for
| parallelism.
| stevebmark wrote:
| Sure, and Gitlab doesn't, because it's not practical
| haolez wrote:
| I'm in the process of transferring from being the CTO of one
| company to CTO in another one and I'm wondering if I should just
| start with Rails this time. I get a little uneasy given the
| popularity of the JavaScript ecosystem, and Rails seems a little
| harder to share code between the web app and mobile apps, but I
| don't know... It feels extremely productive to work on Rails.
| mysterydip wrote:
| I'm confused, is this a new company? If not, it seems like
| changing the tech stack as soon as you come in is a recipe for
| disaster.
| haolez wrote:
| It's a new company, the system is still small and they just
| lost 80% of their engineering talent. I think what's left of
| the system doesn't matter that much (but I'll have to check,
| of course). They are currently on C# + Angular.
| rapind wrote:
| Fable is pretty kick ass if you're feeling adventurous
| within the .net ecosystem.
|
| https://fable.io/
| methehack wrote:
| Rails + angular works well, might be a compromise for you.
| You could replace the backend endpoint by endpoint... e.g.
| (or similar to incrementalize it). I mean -- assuming the
| C# is not something you want to carry forward.
| oblio wrote:
| Why drop C#, though? Angular, I get. But modern dotnet is
| quite cool.
| haolez wrote:
| Because it seems that Rails is a lot more productive in
| the end. It's not a C# shortcoming, but rather a Rails
| merit.
| pas wrote:
| why would you drop Angular though? what would you use
| instead?
| WorldMaker wrote:
| I think Angular has a pit of failure for performance
| problems. It's use of RxJS is highly compromised (Angular
| "best practices" are often RxJS worst practices) and that
| infects all of Angular development and fills the entire
| ecosystem with memory leaks and other performance
| problems. (I've blogged about some specifics before and
| I've built/published an open source library to try to
| compensate as best I can as I currently work in codebases
| now sunk cost fallacy stuck to Angular.)
|
| I don't think any of React/Vue/Svelte are nearly as
| compromised and have nearly as big of a pit of failure. I
| find React a good option with an active ecosystem. React
| especially isn't ashamed of and doesn't hide its learning
| curve like Angular tries to, and that learning curve is
| especially designed to more often than not lead towards
| pits of success.
| dominotw wrote:
| react
| brink wrote:
| I'd start by questioning if I need a front-end framework
| at all.
| isbvhodnvemrwvn wrote:
| They lost 80% of engineering talent, baking a custom
| framework every single new joiner would have to learn
| would be a colossal waste of resources.
| Lio wrote:
| Hopefully when Strada, part of Hotwire, is released latter this
| year that will take care of the mobile app part of the puzzle.
| a3w wrote:
| Isn't strada a running app? And also the name of Google's
| gaming streaming service? And probably 5 other things that
| have higher search priority on PageRank?
|
| What is Hotwire , though?
| NDT wrote:
| Strava is the running app
| jdoconnor wrote:
| google's game streaming service - Stadia
| vxNsr wrote:
| I think this answers your questions: https://hotwired.dev/
|
| > _Strada standardizes the way that web and native parts of
| a mobile hybrid application talk to each other via HTML
| bridge attributes. This makes it easy to progressively
| level-up web interactions with native replacements.
|
| Strada will premiere in 2022_
|
| _Hotwire is an alternative approach to building modern web
| applications without using much JavaScript by sending HTML
| instead of JSON over the wire. This makes for fast first-
| load pages, keeps template rendering on the server, and
| allows for a simpler, more productive development
| experience in any programming language, without sacrificing
| any of the speed or responsiveness associated with a
| traditional single-page application._
| wefarrell wrote:
| I'd also look at elixir/phoenix.
| haolez wrote:
| Yeah, I wanted to try it as well, but I don't think the team
| can handle such a drastic change right now (from OOP to
| Functional). But it looks like an awesome platform.
| meesterdude wrote:
| rails is awesome, and with hotwire we can reuse slices of the
| application and cut down required dev time. It's certainly
| optimized for developer productivity and happiness! been doing
| it for 13 years and still love it.
| rco8786 wrote:
| > It feels extremely productive to work on Rails
|
| It is. Nothing comes close. It's a shame there's such a stigma
| around it otherwise.
|
| I do think that we're seeing the pendulum start to swing from
| microservices/cloud/PaaS everything back towards simple
| architectures and simple deployments and I'm hoping Rails sees
| a bit of a renaissance with that.
|
| > Rails seems a little harder to share code between the web app
| and mobile apps
|
| I've personally never seen this done well, ever. At least not
| in a way that the amount of code that can actually be usefully
| shared is worth the effort.
| greggh wrote:
| >Nothing comes close.
|
| Laravel is as easy and productive.
| Sparkyte wrote:
| Just containerize everything put it in kubernetes or some other
| solution. Plenty of CI/CD tools that take the toil out of it.
| number6 wrote:
| Mostly work with Django but have some expire with Rails: the
| speed you have with rails is insane compared with JS.
| Authentification, Routing, management of state, SSR. It's all
| done for you.
|
| Mobile App. Start with Service Workers and PWA and decide then
| if you need an app.
| cardanome wrote:
| Good for them for sticking with Rails I guess. I am just not sure
| who asked or what the value of the article is supposed to be.
|
| Sure it is interesting to see the historic reasons for Ruby but
| these days PHP is a very different language with an arguably much
| better optional typing story than Ruby. The community has matured
| quite a bit and there is lot's of people doing "enterprise-level"
| work. The whole comparison doesn't hold true for modern PHP.
|
| In fact it would be interesting to reflect on the promises that
| Ruby on Rails made. Approachability and developer productivity it
| absolutely delivered but "not messy" ugh not exactly. It requires
| quite a bit of discipline and experience for projects to not get
| messy.
|
| I don't mean to say Ruby on Rails is a bad choice. If you are
| invested in the ecosystem there is no reason to change (except
| when you want something like Elixir maybe). On the other hand
| other languages have long caught up and have their own rails-
| style frameworks that are not much worse. It is not that much of
| a unique selling point anymore.
|
| Fully agree on the microservice part though.
| newaccount2021 wrote:
| ransom1538 wrote:
| If you want the full modern rails setup:
| rails7+docker+mysql+ruby3 this will get you off the ground in a
| few minutes.
|
| https://github.com/james-ransom/rails7-on-docker-mysql
| caseyohara wrote:
| Why MySQL and not Postgres? Most modern Rails apps use Postgres
| in production (at least according to this survey https://rails-
| hosting.com/2022/#databases)
| ransom1538 wrote:
| You can use the parent fork! It is Postgres. I just
| personally hate Postgres and have a huge mysqldb i need to
| support.
| draw_down wrote:
___________________________________________________________________
(page generated 2022-07-08 23:00 UTC)