3 ms·

I have to say, I disagree with virtually every conclusion here. I don't doubt that there are some bad frameworks, or indeed that some developers have a habit o

I have to say, I disagree with virtually every conclusion here. I don't doubt that there are some bad frameworks, or indeed that some developers have a habit of reaching for the closest framework even when it's not the best solution to a particular problem. This was most obviously demonstrated to me once when several applicants for a developer role submitted a simple CLI coding exercise as an entire Rails app, despite the complete lack of that requirement. We all use abstraction to model problem domains in terms of familiar concepts. There are different levels of these abstractions, and different levels are used in different places where it's appropriate. Sometimes using no framework is suitable; sometimes a small framework is suitable, sometimes a grab-bag of libraries, and sometimes a larger framework. I've used Rails a lot. In some ways, it's a pretty standard implementation of well-known concepts – REST, Active Record, MVC et al. But it removes the work and friction of selecting an ORM, routing library, template renderer, asset pipeline, session management and so on, instead providing workable standard solutions for all of these. In many cases, this is completely fine – there are a class of web applications that Rails is pretty great for. Using it reduces the amount of custom plumbing that is required, and that can be both a short-term and long-term win. On the other hand, some applications don't fit into a particular framework's constraints. Building a server to do some basic websocket communication would probably not be a good fit for Rails, for example, and one might consider building it on top of some libraries in Go, or Node, or something else. Maybe sometimes a larger application has specialised requirements that mean a framework would be an unsuitable choice, and it's better to compose modules in a different way. These different scenarios come up all the time! Avoiding the use of frameworks, in my experience, can often result in developers building their own buggy implementation of 50% of what the framework offers. If the problem exists at all, it exists in the unsuitable usage of frameworks.

augustl 10y ago
I think it depends on the platform, and libraries available on said platform. On the JVM, I create webapps using a @ServletContextListener class, which essentially is a "main" that gets the servlet context passed to it. You could call this implicit, but it is at least the only implicit thing you need. I have 5 lines that read in and left merge some config files. I manually invoke a spring context for setup/teardown of stateful stuff like database connections, queue connections, etc, and initialization of core services using these. Some more lines to set up the Jersey controllers on the servlet, maybe asset-pipeline or something else for handling static files, and we're up to a total of 100-150 lines of initialization/boilerplate. The win here is that there is absolutely nothing implicit about my app besides from the invocation of "main". My main beef with frameworks is the implicitness. Great when it works, but I'm so tired of hitting some kind of bug where some implicit thing stops happening for whatever reason and having to trace it down in the framework bowels. In my experience, there is very little difference between learning a framework vs learning a platform (JVM servlets) and a few core libraries (spring-context, Apache's data source for DB connections, JMS for queue stuff, Jersey for servlets, spring-security for auth).

augustl 10y ago

I think it depends on the platform, and libraries available on said platform. On the JVM, I create webapps using a @ServletContextListener class, which essentially is a "main" that gets the servlet context passed to it. You could call this implicit, but it is at least the only implicit thing you need. I have 5 lines that read in and left merge some config files. I manually invoke a spring context for setup/teardown of stateful stuff like database connections, queue connections, etc, and initialization of core services using these. Some more lines to set up the Jersey controllers on the servlet, maybe asset-pipeline or something else for handling static files, and we're up to a total of 100-150 lines of initialization/boilerplate. The win here is that there is absolutely nothing implicit about my app besides from the invocation of "main". My main beef with frameworks is the implicitness. Great when it works, but I'm so tired of hitting some kind of bug where some implicit thing stops happening for whatever reason and having to trace it down in the framework bowels. In my experience, there is very little difference between learning a framework vs learning a platform (JVM servlets) and a few core libraries (spring-context, Apache's data source for DB connections, JMS for queue stuff, Jersey for servlets, spring-security for auth).