3
16 Comments

I'm building a web framework (maybe!)

Working on this blog post ... which isn't fully complete but it's enough complete to show my journey.

I'm trying to layout my logic for why I think this actually makes sense and isn't just redundant:

  • there's a large group of JavaScript developers who think web development is too complex and is looking for simpler tools (but still build powerful web-based products)
  • there isn't anything like this in the JavaScript ecosystem broadly, but the TypeScript ecosystem a bit more narrowly
  • I'd like to scratch my own itch for IndieHacker-style projects. I've been slowed down by complex setups, and want something higher-productivity but still in JS

I would probably do this as a pure, non-monetized Open Source project ... but there's lots of ways to monetize around it if it takes off.

  1. 2

    https://svelte.dev/ seems to fit this use case.

    I just watched a Youtube video and the next thing they're working on looks amazing (couldn't find the link).

    Nextjs also seems good.

    1. 1

      Thanks for reading!

      Svelte is pretty neat SPA framework for sure. Definitely the most interesting thing happening in JS these days.

      Sapper is the Svelte equivalent of nextjs: https://sapper.svelte.dev/.

      I haven’t built something serious with Next, but I know it’s wildly popular. I should add a section to the blog post comparing what I’m thinking about to stuff like Next, Nuxt, and Sapper.

      1. 1

        I believe the guy said sapper is "ded", because of the huge updates this new framework has.

        1. 1

          @volkandkaya, thanks for all the input.

          I just saw a great article from Tom MacWright: https://macwright.com/2020/10/28/if-not-spas.html

          It hits all the big ones ... Next.js, Blitz, Redwood, etc.

        2. 1

          Huh!

          If you find that link, I’d be super interested to see!

            1. 1

              @volkandkaya, Rich Harris has really been pushing the envelope for a few years now with Rollup and Svelte. What he's working on looks pretty cool ... kind of like a sweet hybrid of SSG and SSR.

              But yeah, sounds like Sapper won't ever hit 1.0 and they'll sunset it once this stable.

  2. 1

    I had this exact set of problems in mind when I built https://mkws.sh/. Really quick way to get some content online.

    1. 1

      Thanks for the reply!

      I’m thinking of a framework more in line with Laravel or Rails but in TypeScript; mkws seems to fit in with Static Site Generators like Jekyll, Hugo, or 11ty. How does it compare to some of those?

      1. 1

        I was talking about the complexity of modern web development (in my case, static site generators).

        Regarding other static site generators, well, there's no custom templating language involved. You just nest shell code inside your templates. You can test your output command in your terminal, and copy paste them in your templates. You can also use shell code inside CSS files for simple preprocessing, no need for SASS, Less or other preprocessor. Same for RSS feeds or even Markdown. Basically, you can script any plain text file using tens of years old, battle tested abstractions specifically created for handling text.

        Extensions are created by creating additional CLI programs that deal with plain text.

        For now there's no package manager involved, you just download the archive and start building your website. You can just have your extensions directly in you source code bundle.

        Now, regarding web frameworks in general, not sure if another MVC framework if the solution, and JavaScript on the server still feels hacky.

        Regarding server side solutions, I was thinking a programming language specifically crafted for server side web development might be the solution. Maybe a simple, cleaned up PHP. That way you would have common web development patterns as close to the metal as possible. If I were to build something like this, I would start with something like https://github.com/totalspectrum/tinyscript, https://github.com/thesephist/ink or
        https://github.com/vtereshkov/umka-lang, but these are are some vague ideas of mine.

        Another idea I think I'll do at some point is to build a server side app using small, simple C/Go programs following the UNIX philosophy, compose them and just have the output handled by https://mkws.sh/pp.html. Think for example a web mail client using https://github.com/leahneukirchen/mblaze that just calls the CLI utilities. You can apply that pattern to any web project. You would have the flexibility of dynamic languages at output and the safety of static languages for business logic.

        All of these could be progressively enhanced.

        1. 1

          Cool, thanks for all the input! That's certainly angles I haven't considered before—good to have a new perspective.

          Now, regarding web frameworks in general, not sure if another MVC framework is the solution, and JavaScript on the server still feels hacky.

          Can you explain a bit more? What about Node (what I assume you mean by JS on the server) feels hacky?

          But also, agree, I'm wagering that another MVC framework is the solution :)

          1. 1

            What feels hacky and I think it actually is, is the fact that JavaScript was created for client side progressive enhancement and it's a hacked up programming language in itself.

            Everything started with JavaScript: The Good Parts:

            Most programming languages contain good and bad parts, but
            JavaScript has more than its share of the bad, having been
            developed and released in a hurry before it could be refined.

            Since then we've been trying to fix JavaScript only by adding features while maintaining backwards compatibility while also cramming it on the server side. Now this backwards compatibility has to be kept for both client and server and all this in the name of progress for the sake of progress mostly. But it seems it's only running in circles. Stuff doesn't really get fixed, just hidden away or hacked up all this under the illusion of advancement.

            You said one way to fix complexity is by having few moving parts, the JavaScript landscape only adds more and it shows no sign of stopping!

            It may be that the ecosystem is just not suited for server side development and barely for client side development.

            My low risk solution for dynamic server side application would be to stay faithful to the original server side solutions, writing small programs in C or shell script, compose them, pipe them, etc... and just translate the output to web technologies using text processing techniques. I think the preprocessor pattern fits well here because you're just outputting text in a different way. Also, I'd rather keep JavaScript on the client side for progressive enhancement.

  3. 1

    Have you seen RedwoodJS

    I'm mentioning it because you talked about wanting the framework to be batteries included. Redwood might fit in that category.

    1. 1

      Thanks for reading, @mattfreire!

      I have seen Redwood and should add a comparison section to my blog post. I think the biggest difference is that Redwood is for the JAMstack world. Redwood is super compelling for JAMstack but still suffers from a complexity if parts in my opinion—this is somewhat of a necessity to take advantage of edge computing.

      I’ll add some more comparison to that and stuff like Next

      1. 1

        What about https://blitzjs.com/ (i saw your comment above) about Rails

Trending on Indie Hackers
How I grew a side project to 100k Unique Visitors in 7 days with 0 audience 47 comments Competing with Product Hunt: a month later 33 comments Why do you hate marketing? 27 comments $15k revenues in <4 months as a solopreneur 14 comments Use Your Product 13 comments How I Launched FrontendEase 13 comments