Ask HN: What's the lowest churn web stack?

23 points by xupybd ↗ HN
Have you found a web stack you love that suffer from churn.

I'm starting to realise the inefficiencies in keeping JS tooling up to date is a massive drain on resources. Is there a better option?

42 comments

[ 4.8 ms ] story [ 83.6 ms ] thread
Anything server-side-rendered is going to be low churn compared to the JS world. My backend framework of choice is Django.
Django definitely. Try find a stable ORM for JS - impossible!
Not an ORM and no integration with typescript. But yeh it’s a cool library that I’ve used a lot. I’m not sure how maintained it is though these days.
Is Prisma not an orm? I feel like that’s a been getting the most attention lately.
True. But after spending a long time looking for the “JavaScript Rails”, I realized that I didn’t actually need an ORM. Learning SQL is just as difficult as learning a new ORM’s API. Slonik + Postgres + Graphile is now my go-to.
Been using vanilla-js for over 20 years with server-side rendered web applications. Almost no churn. Only thing missing is a nice password dialog, so drop a link if you know one.
Use create-react-app and don’t eject or add any fancy custom tooling. Nest.js is pretty good on the backend.
>don’t eject or add any fancy custom tooling

Doesn't React require the latest and greatest in build tooling to make it work?

CRA includes all tooling it needs and makes sure there is a clear and smooth update path.
PHP has calmed quite down over the years. The framework wars have been mostly decided between a handful of them, we dont have much in the way of package management issues and you dont have to compile it.
Yup, this is why we use PHP/Laravel for our stuff. Stable language + powerful framework = can focus on solving business problems.
EmberJS is probably the most stable of the frontend frameworks in that it's very internally consistent and opinionated. As far as the back-end goes, I think PHP, Rails and Django are all pretty stable, but I'm not familiar with the microsoft stack.
Django / Ruby On Rails
We just got RoR 6 and Ruby 3 this year. It's not a massive change, but there is a constant churn. Especially with gems updating to support both.
React with Django handling url routing and user sessions. Single page applications reduce footprint of javascript tooling.
I would put Laravel/PHP against anything else out there right now. Based on my (albeit limited) experiences with Node.js and Java/SpringBoot, I would choose Laravel for the vast majority of applications.
> What's the lowest churn web stack?

cgi-bin/ obviously. But sometimes you can get away with just public_html.

SPA w/ AngularJS 1.x and Flask on the backend.
In my opinion: Ruby On Rails. It has an awesome community, lots of gems (libraries) for web stuff. An opinionated way of doing frontend and backend. No waste of time taking decisions about what state management to use, how to organize stuff, etc. Just focus on stable, accepted, well maintained conventions and focus on your business problems instead.

It might be harder to find people interested in working with it depending where you are, but I guarantee you that you will need a lot less people to build the same thing with lower level tools (SPAs, Go, Erlang, Rust, whatever...).

I would also say Django, but the problem with it is that it just solves the backend side of things. You will still have to find an answer for how to do the frontend as it has no opinions there (and the templating and forms stuff it has built in falls really short in my experience).

I've heard good things about php/symfony, but never used it myself.

Interesting. In your opinion, is it worth learning RoR over Django? I'm historically a Python dev, but find Django and Python web development in general a very poor experience.
Absolutely. I've used django professionally for about 8 years and I agree with you. Python (and django) is great but solves only the backend side of things.

Things that are by far superior in Rails in my opinion:

* It is a real full stack solution. From migrations to css to credentials storage to assets compilation to file uploads to rich text editing to we sockets, etc.

* Ruby might not be as popular as python, but it is a lot better designed (and a lot more consistent).

* Gems/bundler and everything about packaging works a lot better.

* The routing, controllers and validations make a lot more sense to me

The only thing I like more from django is the built in admin. Although there are also external gems for rails which provide same functionality for rails.

Thanks for your response - very informative!
Also, the organization into "apps" in django is total nonsense in my opinion.
I've been using Rails for 8 years or so now. There's a lot to like about it, but IMHO the productivity gains are somewhat of an illusion. It makes building the easy stuff fast at the expense of making the hard stuff slow. If you stay with the easy stuff then no problem. If it grows to a bigger team or high load? Problems.
> If it grows to a bigger team or high load? Problems

Then that's when you should definitely start looking to specific solutions to specific problems.

Are you having scaling/performance issues? Look into kubernetes.

Are you having problems with "too many cooks in the kitchen"? Start looking splitting things to separate services.

Are you having problems hiring "full stack" people than can work on both ruby and frontend? Then start thinking about an SPA.

That's the power of Rails.... you can get really, really far with it... when your business is a total success and you have steady income, then start looking into the specifics.

Starting from the get go with an SPA, kubernetes, microservices, monorepos, etc is, in my opinion, a recipe for failure.

(not that you have said that of course, just something I see too much around and I just take every opportunity to rant against it )

This post is kind of acknowledging the problem but thinking it's ok. Like the story of people adjusting to a broken stair or not using a broken toilet in a house. Yeah, those are solutions and work around but really they are "solutions" and work arounds that you shouldn't have to do. Like the whole idea of use Rails until you become a big success and then rewrite it all is kind of crazy.

Your dichotomy of Rails vs a bunch of complicated stuff aren't the only options. We can have something like Rails minus a bunch of magic in a performant language. Maybe it's a little bit less productive at the beginning, but you're not hating life in 18 months when your team reaches 15 developers or you've got to scale.

Out of curiosity, if not rails than what would you recommend?
I think Go is the closest. It's missing a consensus batteries included framework. At least, the last time I looked. But everything you need is there even if you gotta get it from multiple places. It will take longer to get started but what you end up with will be way better.

Java/Spring's magic is just as bad with annotations and XML, but you do get better performance and types. It'd be my second choice.

It is not abour rewriting. It is about extracting functionality into separate services or projects as the TEAMS/PEOPLE grow so that they not step on each other.

> We can have something like Rails minus a bunch of magic

Examples? Because I'd be very interesting in this.

Also, in the world of web development, the magic Rails does is pretty necessary. If you're not using its magic, you're probably going to write it yourself. It just won't look as magic to yourself because you wrote it, but it will to others joining later. Except they won't have as good documentation, community, etc.

I'm talking about stuff like passing instance variables from controllers to views, method_missing, monkey patching, use of send, and meta programming. This magic makes code pretty and allows a lot of stuff to just work. But when you have to debug or update code that someone else wrote it makes it really difficult to see what's going on.

As an example, if you what to refactor a method it's impossible to be 100% confident that you've found all the places it's used. That makes it very hard to be productive as the team size grows or when you're working in legacy code bases.

Thanks for the insight. I am wary of "greener grass".
I'm curious, what makes you feel web development is a very poor experience (i'm a python dev too)
I'm not primarily a Web developer but have a small Saas built with Ember.

I previously had a webapp built in Django, and just couldn't grok it. I made it work but always felt like I was fighting it. I tried Flask, but you have to build absolutely everything yourself.

I have a tiny team (2 devs) and hate spending time building and maintaining cookie cutter functionality like sign in flows, teams, etc.

I mean I always use a simple express server for json api/websockets/some routes for auth, static assets behind cdn. Where is the churn here?

You can swap out the frontend end for whatever framework you want, your api layer is thin, you can swap that out too. Where are you guys getting trapped in churn? The server side rendering bullshit?

I recommend (subjectively of course) Ruby on Rails.

It is a full-stack offering together with Ruby Gems ecosystem solutions to a wide range of things that I want to achieve with a webapp. I like a lot how people in this community tries to simplify a lot of the complexities of modern tools.

In the Ruby (and Rails ecosystem) you should take a look at https://hotwire.dev - helping create amazing web apps with less Javascript code. There are a lot of things to like there, but you can start small with Stimulus JS, which for me offers good enough JS code to do small UI things.

Then there is https://docs.stimulusreflex.com - for creating reactive web apps without going full SPA mode.

And here it is the latest addition to this eco-system (that I know of): https://github.com/rails/tailwindcss-rails. This is integrating Tailwind directly in assets pipeline of Rails. No need to configure webpack and postcss and whatever other configs. You can directly use Tailwind by adding this gem.

Rails, PHP, or Django. Tried and tested, strong communities.