4 ms·
It's interesting how so many of these microframework+app server type things spread across many languages have converged on a very, very, similar set of conventi
by SwellJoe 10y ago
It's interesting how so many of these microframework+app server type things spread across many languages have converged on a very, very, similar set of conventions and practices. The example code looks strikingly like every other recent JavaScript/Perl/Python/Ruby microframework+server that I've tinkered with lately (Express, Koa, and Hapi in JS, Mojolicious in Perl, and Flask in Python). Aside from the obvious language differences, the concepts are all so similar.
I wonder if this is a convergence on a local maximum for writing web apps, or if it's just a situation where the most popular ones did it this way, so everyone does it this way. Not that it matters too much, in the general case. The route and app setup plumbing is a small part of most applications, so it's rarely going to be ruinous if you spend an extra hour or two getting it working right. But, since I've been evaluating a bunch of different ways to build web app backends lately, I've just noticed how similar they all are, no matter what language you choose. Most of the ones I've been looking at are asynchronous, so this also has that similarity to most of the others.
While one could argue that it's obvious that they would look the same...but, web development didn't always look this way. The first 10-15 years of web application development I did looked very different, in fact (CGI or mod_perl or PHP, which has some quite different conventions).
- minitech 10y agoThe README suggests this one is written to be Flask-like, and Koa is based on Express/Connect.
- MildlySerious 10y agoAnd Express as well as many others are loosely based on what Rails did iirc
- minitech 10y agoI don’t see how Express is at all based on Rails. They both have… similar URL pattern syntax that Rails didn’t invent?
- mirekrusin 10y agoJust to clarify, Koa can be considered an evolution of Express. It's not "based on Express" per se - there's no dependency there. It has been written by authors of Express - in that sense, conceptually, "it's based" on good ideas behind Express.
- Jgrubb 10y agoI've had this blog post in my head for a couple years now that some day I'll get around to writing. It's titled "Toward a Common API", and it's basically about this - the convergence of best practices, naming conventions, patterns, etc across languages and frameworks that (IMHO) is a wonderful thing in that it reduces ramp up time when coming to something new. It came to me after playing with Rails for several years and then taking a look at Laravel, which is clearly Rails inspired in many ways but made some different decisions in the naming of a few things that are present in both frameworks.
- mangeletti 10y ago> I wonder if this is a convergence on a local maximum... It's more like a global minimum. With many of these micro-frameworks, you're observing what is near the minimum API required for mapping a web request to a single function.
- SwellJoe 10y agoAh, yes, global minimum does fit better as a descriptor. > you're observing what is near the minimum API required for mapping a web request to a single function. I mean, sure, it is functionality needs to be there across the board...but, it could be named differently or used differently. An "app" object is seemingly universal everywhere, a run method is super common; router configuration is very similar across several frameworks, though in this and Flask it is a decorator while it's a method in Express or Mojolicious, but still look a lot alike. Anyway, I just think it's nice. It means that when I poke around in projects I've never seen before in frameworks I'm not familiar with, it isn't terribly difficult to get up to speed on at least the basics of what it's doing and how to change minor things about it. Building a big project from scratch still requires some time to get up to speed, but I think it's likely to provide developers more mobility across projects and companies, which is a good thing. Standards are nice, even when they're de facto and just came about because "everybody's doing it". I haven't had a chance to tinker with the async elements of this, but I'm betting it's similarly transferable knowledge across all of the frameworks that are async. Anyway, none of this is really an amazing revelation, I guess for people who've been working on modern web apps for a while. But, I'm catching up from doing it in a variety of old ways (for examples of doing it very different ways, just take a look at some Drupal or WordPress or Mediawiki or old school Perl web application code...these projects are still very heavily used and have thousands of developers working on them, and they look literally nothing like the model we're talking about, and often don't really even look that much like each other). My point is that there's been convergence, and it really hasn't always been obvious how it should be done. Knowledge of Drupal, WordPress, or Mediawiki, does not readily translate to anything else. I have to get back up to speed every time I dive into any of them (and I still do have to do so now and then). There are tons of projects that are like that. Also, interop is getting a lot better. I don't feel like it would be crazy to stick a Mojolicious app alongside an Express app, working with the same data sources and even talking to the same web/mobile frontends, for example. Making those old projects interact nicely with others is often an exercise in frustration.