4 ms·

I think the question that is left unanswered here is - if not frameworks, what should we use? Conceptually, there are only two solutions either: a - write ev

I think the question that is left unanswered here is - if not frameworks, what should we use? Conceptually, there are only two solutions either: a - write everything from scratch, which I think we all agree will be disastrous. or b - compose tons of libraries together - for a typical webapp, that means connecting your ORM library to your routing library, to your template rendering library, to your authorization library, to your authentication library, session management, caching, deployment management, logging, monitoring , etc... Obviously, the big giant downside is that it takes really long to connect all those things, and you usually do it badly and break abstraction layers anyway (not to mention security). You end up spending 10 hours on every one of the dozens of things you need to make a proper webapp instead of spending a few hours setting up most of your app with the framework of you choice and spend 30 hours on that 1 or 2 damn situations that don't quite fit into the framework's golden path. Really, you can work to create better frameworks, but the cost-benefit analysis will always sit with working with a framework rather then joining things together - unless the project is trivially small or you have enough resources to practically build your own framework. And that's before we take into account new hires and the reduced cost of training if they already are familiar with the popular framework you chose to use, or the ability to create plugins/extensions/add-ons to a framework that crosses concerns (For example a plugin that can deal with both add a model and a new route).

augustl 10y ago
I've found that without a framework, there is very little to actually connect. I use something like spring-context for stateful things like datasources and queue connections, for clean setup/teardown. In the controller, I call a service which returns a plain map with data, and pass that data to a mustache template. I tend to just invoke stuff and pass around data. What is the difference between `mustasche("foo.mustache", myService.baz())` and some implicit render logic a la Rails? One extra line with the template name instead of a framework that implicitly resolves the template? Setting up a new app usually takes me 10-15 minutes and 100-150 lines of boilerplate (read config files, create spring context, wire up controllers, ...), which is definitely worth the (low) cost in my opinion to achieve the blissful state of absolutely no implicit stuff happening beyond my "main" being invoked. This win gets bigger the more the project grows.
Terretta 10y ago
(b) can look like this: Luminus is a Clojure micro-framework based on a set of lightweight libraries. It aims to provide a robust, scalable, and easy to use platform. With Luminus you can focus on developing your app the way you want ... http://www.luminusweb.net/ http://www.luminusweb.net/ http://www.luminusweb.net/docs/useful_libraries.md http://www.luminusweb.net/docs/useful_libraries.md
jdlshore 10y ago
You're overestimating the complexity of (b). Composing libraries is pretty trivial, and in my experience easier than learning to do meaningful work in a framework, and certainly easier than working around framework limitations. The problems with (b) isn't the composition, which is easy, but the availability of quality libraries. Popular libraries are often written (and re-written, and re-written, and re-written) as plug-ins for specific frameworks. For example, it used to be hard to find a JavaScript drag-and-drop library that worked independently of JQuery. That said, I'll take that pain over the pain of a framework. When you get to the interesting bits of an application, it's so much easier to evolve my own design than to work around framework design decisions.

augustl 10y ago

I've found that without a framework, there is very little to actually connect. I use something like spring-context for stateful things like datasources and queue connections, for clean setup/teardown. In the controller, I call a service which returns a plain map with data, and pass that data to a mustache template. I tend to just invoke stuff and pass around data. What is the difference between `mustasche("foo.mustache", myService.baz())` and some implicit render logic a la Rails? One extra line with the template name instead of a framework that implicitly resolves the template? Setting up a new app usually takes me 10-15 minutes and 100-150 lines of boilerplate (read config files, create spring context, wire up controllers, ...), which is definitely worth the (low) cost in my opinion to achieve the blissful state of absolutely no implicit stuff happening beyond my "main" being invoked. This win gets bigger the more the project grows.

Terretta 10y ago

(b) can look like this: Luminus is a Clojure micro-framework based on a set of lightweight libraries. It aims to provide a robust, scalable, and easy to use platform. With Luminus you can focus on developing your app the way you want ... http://www.luminusweb.net/ http://www.luminusweb.net/ http://www.luminusweb.net/docs/useful_libraries.md http://www.luminusweb.net/docs/useful_libraries.md

jdlshore 10y ago

You're overestimating the complexity of (b). Composing libraries is pretty trivial, and in my experience easier than learning to do meaningful work in a framework, and certainly easier than working around framework limitations. The problems with (b) isn't the composition, which is easy, but the availability of quality libraries. Popular libraries are often written (and re-written, and re-written, and re-written) as plug-ins for specific frameworks. For example, it used to be hard to find a JavaScript drag-and-drop library that worked independently of JQuery. That said, I'll take that pain over the pain of a framework. When you get to the interesting bits of an application, it's so much easier to evolve my own design than to work around framework design decisions.