101–110 of 550 posts
I think his website could use a framework and some off-the-shelf templates to make it easier to read :)
Discrediting the article with blanket statements and criticizing the format of the site are both against HN guidelines which you can review at the bottom of this page.
Earlier quoted context omitted.
> 1. Every sufficiently complex framework-free application contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of a framework. After 25 years of experience writing software I can honestly say I have encountered many people that agree with this, and perhaps all of them (every single one) have not actually experienced writing an application without a framework. This sentiment sounds correc…
> perhaps all of them (every single one) have not actually experienced writing an application without a framework I actually have written software without a framework, so by this standard I feel qualified to comment. Not all software has an implied framework within it. Most Unix command-line utilities do not, for example, with only a few exceptions, and discounting the C standard library as something worthy of the la…
The definitions of "framework" are always a sticky issue. If you take "framework" at face value, it's minimally a set of idioms. "an essential supporting structure which other things are built on top of" - which necessarily includes a mental model of execution. This relates closely to why naming, in software development, is considered so difficult.
All software has an inherent framework. First is the mental model and then the implementation. Implementation middleware to simplify utilizing these idioms or enforce them, are incidental. If you're lucky, you can derive some of the underlying design from documentation.
Ironically, those who claim that they never use a framework are largely making implicit claims about what they consider a framework to be or have.
Earlier quoted context omitted.
All frameworks are collections of libraries and that usually means you can import and use parts of the framework. Django is exactly what the author is saying is hard to maintain. And mostly all things Django start via wsgi, asgi or manage.py. As the lead developer on three Django based commercial saas products, there is a trade off. Spend your time reinventing the same basic things or spend your time building your pr…
In my experience its not Django that makes apps hard to maintain. Your experience is certainly valid, it just has not been my experience with it at all.
Maintainability is how long it takes you to solve a problem. If the reliability of the framework exceeds that of code you could write then we're limiting the overall scope that must be maintained to begin with. Now on to what issues look like with frameworks, if you use the framework as designed, the code should follow convention - convention improves maintainability. If your framework can't do what's asked, it's bee…
Earlier quoted context omitted.
> I think many, maybe most, companies that try to build loosely coupled and highly cohesive code bases end up failing and it ends up being a mess. Companies who try to build any type of codebase end up with a mess. Always. No exception. There is no reason to pretend software development's natural tendency to increase entropy is exclusive to a specific type of software architecture. In fact, some developers even go to…
> Companies who try to build any type of codebase end up with a mess. Always. No exception. I love how demonstratively wrong this is
1. Every sufficiently complex framework-free application contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of a framework. 2. If you have a talented team, that half of a framework can be much better than using a one-size-fits-all framework that is popular because it used to be lean and mean with a small surface area, but has grown over time to do everything for everyone, becoming a com…
This is good and I pretty much agree. One thing though is that I think #1 and #4 actually also apply to framework'd applications. In my experience, even apps built on Rails end up with a business logic-level "framework" that is ad hoc and not obvious to newcomers, which results in bugs. Not to mention, the frameworks tend to be hard to use "correctly". Rails devs will have heard the term "the Rails way". In fact this…
This applies to whatever in-house monstrosities get built too, except that without docs or a million eyeballs to judge whether a workflow makes some sense to an outsider.
Earlier quoted context omitted.
No, it's not "simply false". It's something that many of us have repeatedly observed happening and probably done ourselves at some point. There are of course exceptions, but it's not really fair to bluntly dismiss it. One of your greatest desires should be to have strong propietry technology that you control Yes – and you should be investing your time in making that "strong proprietary technology" more effective, and…
This notion that frameworks save you time is just ridicluous. Unless the framework is doing something really complicated and difficult (like, say, a 3D game engine such as the Unreal Engine), chances are it's costing you time and effort. What often ends up happening is you have to do a lot of useless work to get around the limitation of the framework you decided to use at the start. Since most people on HN are in the…
* HTML forms * and admin * a plug-and-play security framework that's already worked out all the kinks of crypto libraries * an ORM and DB libraries for a half dozen production-ready DBs, with their kinks in transaction and connection management already sorted out
I have a bridge in Crimea to sell you.
Earlier quoted context omitted.
Rails really does not scale. In performance or development. It’s still a great option for small sites though.
Off the top of my head, I think Github and Gitlab are both based on Rails, as well as Shopify and Airbnb. So there are for sure some very large companies that use Rails successfully at scale. I can't speak to how difficult it was to develop or deploy, and it seems like Ruby as a whole has lost some popularity, but Rails has worked and continues to work for a lot of organizations.
Personally I find that Ruby is more the problem than Rails. Having an untyped language makes things extremely difficult to work with as the app grows. Gem updates are very difficult to do safely.
1. Every sufficiently complex framework-free application contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of a framework. 2. If you have a talented team, that half of a framework can be much better than using a one-size-fits-all framework that is popular because it used to be lean and mean with a small surface area, but has grown over time to do everything for everyone, becoming a com…
It is no fun when an open-source framework pushes a new major version, then deprecates the version you were on, or dependencies fail to find matching version, and you beg github developers to fix the bug and your issue sits open for months and is then closed with no warning.
Earlier quoted context omitted.
Agreed - I think most programming language communities have settled on one major framework (though there are plenty of other smaller ones) and they've survived. Spring: June 2003 Rails: August 2004 Django: July 2005 Symfony: October 2005
Many don’t survive. You mentioned Symfony, Zend used to be equally popular. Not many people use it now.