Write Libraries, Not Frameworks
brandons.me
Write Libraries, Not Frameworks
1–10 of 338 posts
Re: Write Libraries, Not Frameworks
#2Well that just makes me want to know what his week was like / brought him to that point.
Not that I can't imagine, I just want to hear about the train wreck.
Re: Write Libraries, Not Frameworks
#3> Do you introduce a domain-specific language? You're now responsible for part of the build chain, and for editor integration.
> Now, if there's a major organization backing the framework, maybe the calculus works out. Google can back Angular...
In my experience, even large orgs don't necessarily have the capacity for building out full-featured editor integration and build tools. Google has a great team managing Angular and it still has no tool for performing codeshifts. The editor integration to date still leaves much to be desired.
With the number of years and man-hours dedicated to this point, I'd imagine these thing would've happened by now, or they may not happen at all. Lately, Angular's push has to been to 'make it faster', which helps with developer productivity, but not much movement on the developer experience (better editor integration) part.
Agree with the thesis, but it's still understated how expensive creating your own DSL is.
Re: Write Libraries, Not Frameworks
#4> Do you introduce a domain-specific language? You're now responsible for part of the build chain, and for editor integration. > Now, if there's a major organization backing the framework, maybe the calculus works out. Google can back Angular... In my experience, even large orgs don't necessarily have the capacity for building out full-featured editor integration and build tools. Google has a great team managing Angu…
Yeah, the outcomes vary for sure. For a counter-example you can look to JSX which has excellent support in most major editors, but it's definitely the exception to the norm.
Re: Write Libraries, Not Frameworks
#5I was expecting a one-sided rant. Instead, I got a reasoned distinction between two different approaches, the trade-offs of each, and a discussion about the cases where one approach (frameworks) can be beneficial but also identifying the added risks of going that route. I agree with the conclusion, and why.
I wish even more people were willing to write down a discussion of alternatives and their trade-offs. Instead of "Google does it this way, so it's obviously the way everyone should do it"... a reasoned discussion of the pros and cons. Good to see.
Re: Write Libraries, Not Frameworks
#6Well that just makes me want to know what his week was like / brought him to that point. Not that I can't imagine, I just want to hear about the train wreck.
Wrestling with an overly-magical and under-supported framework. I won't name names because I don't wish to drag anyone through the mud.
Re: Write Libraries, Not Frameworks
#7> Do you introduce a domain-specific language? You're now responsible for part of the build chain, and for editor integration. > Now, if there's a major organization backing the framework, maybe the calculus works out. Google can back Angular... In my experience, even large orgs don't necessarily have the capacity for building out full-featured editor integration and build tools. Google has a great team managing Angu…
Yeah, the outcomes vary for sure. For a counter-example you can look to JSX which has excellent support in most major editors, but it's definitely the exception to the norm.
Agreed, the size and scope of the DSL will impact the amount of man-hours necessary for developer experience related work. Resourcing that effort is a separate concern, but one that should be considered for the DSL's viability.
JSX, being a sugared syntax for the React.createElement API, likely doesn't need a team of 20 for editor integration, whereas Angular templating language has more to it: pipes, directives (shorthand and non-shorthand syntax), property bindings, expressions, etc -- and templates need to be evaluated in context of their corresponding TypeScript Component.
Re: Write Libraries, Not Frameworks
#8Well that just makes me want to know what his week was like / brought him to that point. Not that I can't imagine, I just want to hear about the train wreck.
Wrestling with an overly-magical and under-supported framework. I won't name names because I don't wish to drag anyone through the mud.
Totally understandable.
You hit another good word there, magic. Frameworks IMO get to be magical or at least extra magical ... but with that extra magic comes responsibility (documentation, support, etc).
Re: Write Libraries, Not Frameworks
#9A framework, usually, must predict ahead of time every kind of thing a user of it might need to do within its walls.
The one thing not mentioned in the article is that the above line of thinking is almost guaranteed to lead to an insane level of abstraction, which was parodied in this classic article from nearly 15 years ago:
http://web.archive.org/web/20141018110445/http://discuss.joe...
(Sadly, that site is gone, but the memories live on...)
Addendum: to see this in practice, one needs to look no farther than Spring, the famous Java framework:
https://docs.spring.io/spring-framework/docs/current/javadoc...
https://docs.spring.io/spring-framework/docs/current/javadoc...
https://docs.spring.io/spring-framework/docs/current/javadoc...
Re: Write Libraries, Not Frameworks
#10Earlier quoted context omitted.
Wrestling with an overly-magical and under-supported framework. I won't name names because I don't wish to drag anyone through the mud.
Totally understandable. You hit another good word there, magic. Frameworks IMO get to be magical or at least extra magical ... but with that extra magic comes responsibility (documentation, support, etc).
Definitely. Like frameworks themselves, magic isn't necessarily bad, but it is an added liability that shouldn't be taken lightly, and should only be introduced when it's really worth it.