Comment by mfDjB | Hacker News Reader

Comment by mfDjB | Hacker News Reader

It seems like every time a new UI framework comes around, a tradeoff is made between convenience and flexibility, with the advertising always being around "look how easy it is to make a table view", but this doesn't particularly impress me anymore, because as I've used these newer paradigms it seems like I am trading 5 minutes (UIKit) for 3 minutes (SwiftUI) when it comes to basic UI development, but later on trading 30 minutes (UIKit) for 3 hours (SwiftUI) when it comes to anything significantly complex. This is not just true for iOS but web as well.

I'm unsure how feasible it would be but it would be really cool if it were possible to benchmark frameworks both by how quick it is to implement basic UI components as well as more complex UIs and score them based on that.

I do feel like its quite an insidious trap to do a project to 80% completeness in a framework then be forced to make the awkward decision of "Do I continue with the current framework where the extra 20% will take a long unknown amount of time or rewrite in the old framework and take the time hit but with easily estimatable timelines?".

> "look how easy it is to make a table view"

My trap in web dev was "look how easy it is to do responsive layout".

Once CSS flex & grid became broadly available, I quickly began to shed my use of frameworks. It took me ~10 years of hard work to get to the point of feeling comfortable in a 100% vanilla web development ecosystem. MDN is my bible now.

The advantages of owning your entire web development vertical are impossible to overstate. The counter arguments are so painful to hear in 2022 - "why would you want to re-invent the wheel" kind of crap. The truth is, I don't write most of my vanilla web code from scratch anymore. Once you build 1 thing and it's in github, it takes 5 seconds to copy/paste that component to some other project. Good luck doing that same activity between Angular and React code piles. Or even Angular code piles of differing versions.

And then someone else has to come behind you to support your custom framework.

I can’t count the number of times where an “architect” has evolved their own custom framework because they thought their problem was a special snowflake. It’s usually worse, less document and less tested than the popular alternative.

> And then someone else has to come behind you to support your custom framework.

Are you asserting that developing an understanding for a vanilla web codebase is somehow worse than figuring out how to upgrade an Angular2 project to Angular8?

The biggest reason we use "custom" framework is because all the "standard" frameworks change too rapidly to support our business model. They also fall out of support before our B2B contracts expire, creating very difficult situations at due diligence time. We sell software to banks, so we don't get much room to work with regarding our 3rd parties.

> Are you asserting that developing an understanding for a vanilla web codebase is somehow worse than figuring out how to upgrade an Angular2 project to Angular8?

That depends on the details of the vanilla web codebase no? There's no bright line between "vanilla web" and "custom in-house Angular-like framework we created from scratch that stymies new developers." It's all a matter of how the vanilla codebase is developed.

(but sure there are certainly reasons to do something without a pre-built framework, especially if you have certain support commitments)

I’m asserting that as the needs of your website expand and grow, you’re going to need to add cross cutting concerns that are not core to your business logic and you will inevitably end up creating your own framework.

See also: custom ORM, custom logging framework, custom authentication, etc.

On the other hand mainstream frameworks have a big community behind them, while the custom framework's support is only you - thus making it:

1) far more likely that you have undiscovered vulnerabilities in it,

2) actually a lot more work to keep it up to date and properly secured over time, since it's all up to your team (and this becomes exponentially harder with every 3rd party lib that you use).

Not implying it's the case with your company, of course, but most of B2B companies that I've seen that use custom frameworks solve these 2 problems by simply ignoring them and not updating anything - hoping for the best and relying primarily on security through obscurity for protection.

This makes no sense. Frontend web frameworks don’t do anything for security besides escaping HTML occasionally.

> It’s usually worse, less document and less tested than the popular alternative.

That's often true, but the situation is not much different to framework stagnation.

"Popular" frontend frameworks I have worked with throughout the years, which are all more or less obsolete now:

Dojo, KnockoutJS, ExtJS, Backbone.JS, AngularJS, Angular 2+, Ionic

Web frontends are replaced every couple of years, often triggered by new feature development using the shiny new framework, and the cost of supporting the old, now unpopular framework.

Focusing on the actual web standards instead of another framework abstraction has long term value. For example, being able to query a DB using SQL is as relevant as it was 30 years ago, despite the numerous ORM/QueryGenerators on top of it.

And yes when I started web development CSS didn’t exist. Knowing web standards doesn’t keep you from having to learn.

Frameworks for layout in css is one thing, but frameworks are still super useful for skipping the repeated effort of things like dropdowns, navs, typography, sliders, etc.

There's a fun bit of marketing [0] NeXT did when AppKit was the new thing, comparing building a reasonably non-trivial application with it to a Sun workstation using C. Obviously biased, but still an interesting look into the development environment that among other things brought us the Web and DOOM.

0. https://www.youtube.com/watch?v=UGhfB-NICzg

Hear hear.

There's also a lot of noise in the community coming from either juniors or hobbyists praising whatever new shiny feature they just learned about which sells the wrong impression that, in this particular case, SwiftUI is way better or more mature than it actually is.

I think the more you climb the abstraction ladder (make things easier by abstracting the details), the more the chance, not only of saving time, but also of rigidity.

This is an area where I appreciate Angular and Angular Material. Angular Material provides the "easy to make table", which itself is simply a styled version of the underlying Angular CDK library. CDK provides unstyled building blocks for the Material components, which makes it significantly easier to roll your own.

> but later on trading 30 minutes (UIKit) for 3 hours (SwiftUI) when it comes to anything significantly complex

if something is faster/better implemented in UIKit, then do it! And then shove that in a `UIViewRepresentable` and plug it in to your SwiftUI code. :)

The best part of SwiftUI is being able to fall back on UIKit or AppKit.

Reply on news.ycombinator.com