7 ms·
I know this issue has been brought up many times before, but to some extent the existence of a framework suggests a lack of composability in the language being
by lkrubner 13y ago
I know this issue has been brought up many times before, but to some extent the existence of a framework suggests a lack of composability in the language being discussed. This gets discussed a lot in the context of Clojure, where people new to Clojure often ask, "Where are the frameworks?"
The more meta-programming that a language allows, the more its functions will tend to be composable. The more composable it is, the more its libraries can be tied together without the need for an over-arching framework. The framework is there to provide needed cohesion at exactly those points where the language itself does not provide enough meta reflexion to enable fearless mixing of libraries that have little knowledge of each other.
There is also the historical trend toward lighter frameworks: Rails was lighter than Struts, and more recently we've seen a flood of frameworks that are much lighter than Rails.
The Clojure eco-system has gone furthest down this road. Although at first there was a feeling that there should be a web framework for Clojure (and people made wonderful efforts with Noir) eventually the consensus of the community was that it was sufficient to get by with various libraries, some of which (Ring) have become standards.
We see this with a lot of new Ruby frameworks as well: composability over centralized organization. Javascript is going down this road as well.
Languages that offer less in the way of meta-programming (PHP) have been slower to go down this road.
No matter what language you use, the future direction of the trend seems clear enough: less frameworks, less centralized effort toward organization, more emphasis on composability, better ability to mix libraries for maximum effect.
- girvo 13y agoSurprisingly PHP with Composer, coupled with type hinting and interfaces allows you to achieve what you're discussing. It's how I write web apps now -- small libraries, classes that expect interfaces, and unit testing. It's great - no frameworks!
- secoif 13y agoA fantastic example of this (in javascript) is trending right now on hackernews – myth. https://news.ycombinator.com/item?id=6923141 https://news.ycombinator.com/item?id=6923141 Look at this implementation: it's just a composition of a bunch of other libraries. no logic at all. This is how it should be: https://github.com/segmentio/myth/blob/master/index.js#L37-L45 https://github.com/segmentio/myth/blob/master/index.js#L37-L...
- arianvanp 13y agoWow. that's brilliant. As we would say on tumblr " This is why we can have nice things". I'm actually experimenting with `scotty` for haskell now. Though a tad limited (getting sessions to work is a bit whiney) I had a decently working URL-shortener up and running in an hour of composing haskell modules and writing a max of 20 lines of code. This whole micro-framework thing is getting close to my view of the ideal way of programming. Use as much reusable components at any time. There is always someone who did what you were trying and probably already did it better. I prefer investing time in finding the right micro-frameworks then investing time to learn to program things in new ways (is this a bad thing?). Anyhow, I see a lot of classmates implementing their new login systems for their little websites in pure PHP and i'm just staring at them like 'what the hell'. Especially in things involving security, composable 'micro-modules' are a blessing. I just combine a few libraries and whoop I got an https server that securly talks to a database that securly stores credentials and sessions. I think it's just beautiful. Okay of course I do implement things myself. that that is more out of curiosity. I'm like 'hey how does this security stuff work? how do I break things?' and I read up about it and prototype a little. but I would _never_ use such code in production just because I know someone already did better. So yeah. to sum it up. programming microframeworks give us this: * small, modularized code * where each module on its own is at its best * where the composition of these modules is clear. * and the result is highly maintainable code. I would even want to take it a step further. Where certain kind of frameworks stick to the same standard. Think Promises/A+ or WAI. Now at any time in the future, I can give my whole codebase a speed boost by just changing a single line. Isn't this great?
- collyw 13y agoNot surer I understand the popularity of microframeworks, over fuller frameworks. Using a large framework like Django should allow you to use "as much reusable components" at any time, plus you have the advantage of knowing that they will play nicely together, and should have some sort of consistency between them. Yes you get a bigger download, but it will be stored on the server, not downloaded each time a user clicks a link. Less dependencies, as more is included out of the box.
- bowlofpetunias 13y agoThere is no trend towards lighter frameworks. Frameworks were originally being developed by people with high-end needs. They are then also adopted by people with low-end needs, who conclude that the framework is too big and complicated for them, and start developing/adopting more light weight frameworks. This market is still young, so there are no dominant players like Rails, Django or Symfony yet. It's more a matter of chronological than a trend. Big frameworks are still being used on a massive scale where appropriate, it's just a more stable market where the only news is the next release.
- collyw 13y agoAs a Django user, I hear a lot of people rant about microframeworks, and I have to ask, why? I was amazed at the productivity gains and organization Django brought to my code. If all that bloat is getting in the way, why not go back to CGI? That must be the most minimal of frameworks.
- tbatterii 13y agothere's middle ground between something heavy like django and CGI/WSGI, I think they are called micro frameworks.
- sophacles 13y agoThe problem is not bloat so much as forced paradigm. There are a lot of problems that don't fit nicely in Django, and suddenly you find yourself writing a bunch of code to work around the framework. An example - something I hear a lot of from local Django fans: "Oh that's simple - just ship it off to another process using celery and be done with it". That's great sometimes. Other times why not just use Bottle or flask and do a thin "translate to http" layer and move on? Another problem with many of the existing big frameworks is that they don't do single page apps too well - A lot of stuff I do these days just doesn't need to be designed around the notion of composing templated widgets server side. I just want to ship static html/tpl/etc files and dynamically built data. Wrapping my head around pretending everything is a full page build gets a bit frustrating - why is the response to a query a view or *view? It's just a serialized model I'm pushing over the wire, or a remote function call. Pretending it is a view is a layer of cognitive overheard in between the work I'm doing and the data I'm using.
- inglor 13y agoI couldn't agree more.
- lmm 13y agoThat's not a uniform trend; five years ago in Python you put together a lot of small pieces (and e.g. Turbogears was a nominal framework that was actually a lot of small libraries being composed together). Nowadays Django has a lot more mindshare, and many of those libraries are abandoned. I'm not sure why you're comparing Rails with Struts, which never seemed particularly popular in my experience; Rails certainly feels heavier than spring-webmvc/wicket/tapestry (e.g. it reaches down to the ORM layer, while the Java frameworks expect you to handle that yourself) which is what I saw in use. Many of the Javascript libraries that are coming out are "micro" oriented, but we're also seeing the rise of Angular which is much more of a heavyweight framework. I think you can get the advantages of both if your big framework is built on smaller pieces that make sense in themselves. So in Scala land I'm very pleased to hear that Play is moving to be built on top of Spray (which is a microframework I'm using at the moment - and itself is built out of pieces like spray-json that can be sensibly used in isolation).
- tbatterii 13y ago> five years ago in Python you put together a lot of small pieces (and e.g. Turbogears was a nominal framework that was actually a lot of small libraries being composed together). I loved those days. :)
- sophacles 13y agoFlask is very similar, but they do plugins better - many of the plugins are just thin wrappers around the existing (good) libraries for namespace and context handling -passing the core library functionality to the user. It's also been growing in popularity (hence support and active development).
- r3m6 13y agoAlternative: The iMacros addons for Firefox, Chrome or IE. Not exactly an autofill replacement, more like a macro recorder for web browsers.
- domrdy 13y agoA really good example is the Gorilla toolkit for Go. A few modules for common tasks such as sessions and routing, super easy to use with the standard net/http package thanks to implicit interfaces. http://www.gorillatoolkit.org/ http://www.gorillatoolkit.org/
- asdasf 13y ago>The more meta-programming that a language allows, the more its functions will tend to be composable Where are you coming up with that notion? Clojure's composability comes from being functional, not from meta-programming. >The more composable it is, the more its libraries can be tied together without the need for an over-arching framework A framework is just a library that inverts control. Your code is the library and the framework is the application. Writing main() yourself is not a benefit, and having a framework do it for you isn't detrimental.
- yogthos 13y agoI'm maintaining a micro-framework for Clojure called Luminus (http://www.luminusweb.net/ http://www.luminusweb.net/). The approach I'm taking with it is to provide a standardized template that generates all the common boilerplate. Even when you don't rely on a traditional framework approach you still have to address the problem of finding libraries that are actively maintained and work well together. It's also helpful to have a standard for how an application is organized. While somebody who's already experienced with the ecosystem might not get a lot of value out of this, it makes it provides a much better experience for newcomers.
- papaf 13y agoI haven't done any programming in Clojure for years but that looks really useful. It almost makes me want to start up Emacs and install Leiningen.