6 ms·
Low ceremony? Complexity in real world applications requires complexity in the frameworks that address them. Users will be more disappointed by simplicity that
by mdpm 6y ago
Low ceremony? Complexity in real world applications requires complexity in the frameworks that address them. Users will be more disappointed by simplicity that leaves them addressing complexity without guardrails, conventions, and tooling support.
If your view of low ceremony is matching HTTP verbs to methods, you may happily code your own against the HTTP primitives; if you want a framework that abstracts the complexity and provides a shiny-happy path, you may have to allow for some ceremony. The tooling is the antidote to this.
I think the place you trip up here is in not wanting to use a batteries included approach, while using a framework that makes the necessary abstraction/complexity tradeoffs for projects of mid to large scale. The appropriate tradeoffs _cannot_ be one size fits all.
F#'s support is tricky, as the number of users here is dwarfed by those in C#; and although .NET supports this language diversity, there are no direct idiomatic 'conversions' possible between C# and F# in many cases. This multiplies the effort of providing documentation and examples. I too would like to see it treated as a first class citizen, and for that - the code is OSS.
- rishav_sharan 6y ago> I think the place you trip up here is in not wanting to use a batteries included approach, while using a framework that makes the necessary abstraction/complexity tradeoffs for projects of mid to large scale You have hit the core of my issue here. I am more used to the node-express or golang's way of working where you start off with the smallest and simplest scaffolding and then add on the bits that you need. Rails and ASP .Net are not something I want to use for my small time projects. Its probably unreasonable for me to expect .Net to be something completely different from what it really is, but I really hope that .Net grows up to enable other way of using it.
- manigandham 6y ago(ASP).NET is also like that. The default templates just include more to start with since the platform is designed to scale to many scenarios and features. You can trim out a lot. Take a look at the techempower benchmarks to see examples of different usage of the framework.
- jtdev 6y ago> “ Complexity in real world applications requires complexity in the frameworks that address them.” This is a dangerous way to think about complexity management.
- mdpm 6y agoThis falls under the principle of "Complexity has to go somewhere".
- manigandham 6y agoWhy is it dangerous?
- christophilus 6y ago> Complexity in real world applications requires complexity in the frameworks that address them. Does it? The frameworks I use today are really, really simple. Polka on Node and Go + a few helper libraries. It's all really simple and clear what's going on, and I can solve problems of just about any complexity I've come across with just those basic tools.
- mdpm 6y agoXSRF, rate limiting, permissions/RBAC, feature toggles/TIP, analytics, profiling, silly examples like recent samesite changes - Just a few examples, and that's without touching the developer tooling. As each of these orthogonal concerns starts drifting in, applications become more and more complex as they 'tack on' support for these in code, rather than having structures in place to allow for extensions and modifications. Abstractions always have their cost. Complexity exists in the problem domain of the web, and always will. .NET Core is generally well architected in response to a long experience in enterprise and developer concerns. It's not a magical answer to every domain's requirements, but it's generally a damn good compromise ime.
- christophilus 6y agoEvery one of those things is just composable middleware in the Node/Go stacks, and I think in Phoenix and most FP stacks. Middleware composition seems like the right approach to me.
- mdpm 6y ago.NET Core shares your opinion. Many of these are just registered/configured by default.