11
28 Comments

Where Are the "Modern" Web Frameworks?

Back in what looks like 2007 or so, I took my first shot at striking out on my own in the software industry. I stumbled across Ruby on Rails, which was still somewhat obscure outside the startup space, but by far more advanced than anything else in the space. With "scaffolding," a functioning web application could be had for a few minutes of planning. Those ventures didn't go anywhere, for a variety of reasons---well, one was able to pay its own bills, but not mine---but it was still a huge upgrade, in terms of getting work done.

Fast forward almost fifteen years, and Rails more stable and faster, and I appreciate that, but building web applications is basically the same process. Meanwhile, most other web frameworks have replicated the Rails workflow, which...I still prefer Rails for many uses (especially with static checkers to make the language seem more rigorous), but it makes it less relevant.

That has led me to start wondering: What web application frameworks am I not seeing right now, that are fifteen years in everybody else's future? I know that Rails briefly had Hobo on top of it and JavaScript briefly had Hoodie with some interesting default features, and gave both of them a try at some point and liked them, but they didn't get any traction and the projects are basically dead. So, are there other up-and-coming frameworks that make the competitors look like they were designed over a decade ago...?

  1. 4

    To me, the only next-gen framework is Elixir/Phoenix. Companies build global distributed systems, and can take advantage of multi-core processors. Everything else out there is just a poorer copy of Rails -- and for that I would personally stay with Rails.

    The only alternative would be something from Rust or Go, but neither has something like Phoenix, and I still think Beam is unique enough to have an edge here (thanks to built in actor system).

    1. 2

      Elixir and Phoenix is just on a whole different level in terms of performance, productivity and capabilities. And not because of the syntax, but because of the Beam and VM.

    2. 0

      That's what I was afraid of. Like I said, it feels like Rails came out, and everybody said that was good enough, except for the implementation. That seems bad, in an industry where there's always more to do with less time...

  2. 4

    There's Phoenix, which is a Rails-like framework built in Elixir. I love it and I've been using it for several years, but recently started working with it professionally. I've experienced some rough edges, but I think those are more specific to the company I'm at than the framework and language as a whole.

    1. 0

      I mostly include Phoenix in the same barrel as Rails, ASP.NET, and so forth. It's fine, and I don't dislike Elixir, but there didn't seem to be any new ideas when I tinkered.

      1. 2

        Did you tinker with OTP in Elixir at all? Those other languages aren't even technically capable of distributed systems. Elixir/Erlang are in a different league - a better comparison would be Golang

  3. 4

    The answer is that the "modern" frameworks are currently a WIP. There have been a lot of moving parts and the JS ecosystem is just becoming stable enough to build a long-lasting framework on. (Current leaders are in development hell as they can't upgrade their platforms without immense breaking changes which will destroy any momentum they have)

    We recently launched a new free analytics service called Darwin on a framework we built based on Vue3 and Vite.

    Prior to this we open-sourced another older framework called Factor (https://www.factor.dev) but ended up tabling it due to breaking changes (vue3) and an intense desire to stop using Webpack.

    Anyway, if we get enough interest we will likely open source the newer much better version of Factor later this year.

    1. 1

      Just sign up to try your analytics tools.

      1. 1

        cool, feedback is welcome.

    2. 1

      JavaScript was never the answer.

  4. 3

    There is a Go framework called Buffalo that is the Rails of the Go world. For a simple deployment and implementation I mostly use NextJS with its API routes(which are lambda functions underneath).

  5. 2

    What web application frameworks am I not seeing right now, that are fifteen years in everybody else's future?

    I think the patterns for server-side established in RoR will largely stand the test of time. Models, Controller, Views, Templates, Middleware, etc will continue to be pretty good patterns for developing web applications. These patterns weren't pioneered by RoR but RoR brought them together in a fun to use way.

    The patterns that are nascent today are around IaaS and specifically, Serverless computing. The frameworks that make it really easy and fun to work with AWS Lambda and it's ilk, in particular, and cloud infrastructure in general, will have a chance to have the level of impact RoR has had. Deploying an application on Lambda today is a painful process, even with a frameworks like Serverless Framework.

    1. 1

      Maybe, but those existed before Rails. Rails just started the idea of the computer doing the tedious work automatically. There's still plenty of tedious work, with my favorite blunt example is that Rails-generated code still refuses to adhere to Rubocop style guidelines. But authentication, administration, default styling, handling parent/child relationships, and updating controllers and views when the model changes are all time-sinks on most typical projects that Rails (or something similar) could probably solve once.

  6. 2

    Check out IHP (https://ihp.digitallyinduced.com/). Here's a demo: https://www.youtube.com/watch?v=UbDtS_mUMpI

    IHP has one of the most productive development environments you can find out there :-) We launched it around a year ago and it's now already haskell's largest web framework and it keeps growing. People regularly call it the best web framework they've ever used.

    Some cool features:

    • Live reloading for a super fast feedback loop
    • Best-in-class type-safety: An ecosystem where "null exceptions" just don't happen, this is a huge leverage for productivity. It's 10x better than most other type systems (e.g. TypeScript).
    • web-based dev tooling, makes it very easy to get started with
    • zero-setup dev env: Fixes "doesn't work on my machine"-kind of problems
    • out of the box it has a faster-than-SPA-performance without you needing to write any JS

    And then there's tons of advanced features no other framework has right now:

    • IHP AutoRefresh: You write a view, you add a single keyword to the action, any database tables that are used in the construction of that view are being watched and the view is automatically re-rendered from the server-side. Super useful for e.g. live dashboards
    • IHP Server Side Components: Write components with the full access to all backend libraries and the database
    1. 2

      It's an interesting environment worth watching. Not really the direction I'm trying to go, though, since it's (unless I'm not deep enough into it to see) still basically the Rails approach. That's good, because Haskell doesn't otherwise have that, but also not enough to pull me over until I get back to Haskell...

  7. 1

    Unpopular opinion web frameworks are dead.

    Use https://supabase.io/ to create an API and something like Nextjs for the frontend.

    You will code faster, less bugs and create better websites.

    For scripts on the backend use JS.

    1. 1

      I agree. Supabase feels like progress. In my mind, you get whatever Rails, Laravel, and the likes give you plus a managed DB. Next step would be to add a few more low-code features. Possibly a great drag and drop UI where you can add your custom logic. Like enso.org is doing for the data folks.

      1. 0

        Exactly, with drag and drop low coders could build some powerful logic.

        Developers could then focus on more complex coding.

    2. 1

      I agree with this except the JavaScript part. Hasura and Supabase are game changers.

      1. 3

        Interesting I got downvoted multiple times.

        The reason I say JS is because most devs will be using it for frontend and it is pretty fast.

        1. 1

          Yes, it's a very practical approach for sure (to reuse JS knowledge).

  8. -2

    This comment has been voted down. Click to show.

    1. 2

      It's weird that you interpreted the post to say something that I didn't, but here we are. The Rails workflow hasn't changed much in its sixteen years, and we've learned a lot about software development since then. But sure, try to turn this into a language war...

    2. 1

      Stimulus Reflex isn't something new, it's a copy of LiveView that Phoenix introduced. Ruby is a nice language and I started my career with Rails and am thankful for it, but it doesn't hold a candle to Elixir/Phoenix and the capabilities of OTP.

      1. 0

        Indie Hackers rule #1: mention Rails and an insecure Elixir developer will appear to remind everyone about Erlang.

        You should talk up its time travelling capabilities more, because every time you do this, I point out that CableReady predates LiveView by over a year, that the StimulusReflex repo was created first and that StimulusReflex was publicly available before LiveView.

        We drew heavy inspiration from Chris when we implemented our declared markup syntax. Originally, you'd call a Reflex from JavaScript only - and today it's about 50/50, depending on what you're trying to do.

        Chris' video was also what inspired me to go looking for StimulusReflex, because like most people, I thought "man, if only I could do this in Ruby".

        Turns out... I could! It's a freaking mystery why this upsets you so much.

        1. 2

          There were some other similar projects in Elixir for a few years before LiveView. These and LiveView are only possible due to OTP and the concepts Elixir/Erlang bring.

          With the copy cats, they aren't going to scale as well, require more code, and require a backing state store like Redis (which is another service to manage, scale and pay for).

          1. 0

            We could do this all day, but if you're not @cpursley and interested in nuance, this HN comment says it better than I can:

            In 2021, the problem is that going into the Erlang ecosystem tends to lock you into a whole package of things that vary from "not best of breed but mostly OK" to "significantly inferior to the modern alternatives". All it really has is very nice integration of its not-best-of-breed stuff, but even that kinda becomes a trap after a while, like when you realize you need a real database after all, then maybe you have to integrate with another message bus so you can integrate with non-Erlang code, and, you know, a couple more cycles around that loop and you'll really regret having chosen Erlang.

Trending on Indie Hackers
How I grew a side project to 100k Unique Visitors in 7 days with 0 audience 55 comments Competing with Product Hunt: a month later 33 comments Why do you hate marketing? 29 comments My Top 20 Free Tools That I Use Everyday as an Indie Hacker 18 comments $15k revenues in <4 months as a solopreneur 14 comments Use Your Product 13 comments