A 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, b…
The repeated joke about killing your ex-girlfriend did not age well.
Write Libraries, Not Frameworks
31–40 of 338 posts
Re: Write Libraries, Not Frameworks
#32So there'll be a rewrite or a complete new framework born. But a library will live forever whatever technology changed or not.
But framework is useful to integrate or test out many libraries into one to build something fast. Think it's like a boilerplate to reuse.
TLDR: Library is the primitive to build upon. Framework is just one use of libraries.
Re: Write Libraries, Not Frameworks
#33However, I think to push this line of thought, it would help if we had examples of how to build significant applications without a framework. Ideally someone could provide a walkthrough of an app like that. Unfortunately I can’t volunteer myself: the last time I built without a framework, it was a mess.
Re: Write Libraries, Not Frameworks
#34Earlier 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.
> "I won't name names because I don't wish to drag anyone through the mud." If it's a large framework like Angular they can take it...
Re: Write Libraries, Not Frameworks
#35A 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, b…
The repeated joke about killing your ex-girlfriend did not age well.
Re: Write Libraries, Not Frameworks
#36> 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…
I think all the major frontend frameworks are overly complex beasts, they're too big and can't be used as libraries - for example, you can't replace some functionality out of the box without making a fork. I also didn't find any other reactive frontend framework that could fill this requirement, so I decided to write my own. [0] It is the simplest thing I could conceive (to build, not to use - I plan to provide more…
Re: Write Libraries, Not Frameworks
#37That way you could write a lightweight framework with a powerful library under it.
Re: Write Libraries, Not Frameworks
#38I’m pretty sympathetic to this, as my experience with Spring has been “it’s convenient when it works, but awful to deal with when it’s not working”. However, I think to push this line of thought, it would help if we had examples of how to build significant applications without a framework. Ideally someone could provide a walkthrough of an app like that. Unfortunately I can’t volunteer myself: the last time I built wi…
Re: Write Libraries, Not Frameworks
#39> 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…
I think all the major frontend frameworks are overly complex beasts, they're too big and can't be used as libraries - for example, you can't replace some functionality out of the box without making a fork. I also didn't find any other reactive frontend framework that could fill this requirement, so I decided to write my own. [0] It is the simplest thing I could conceive (to build, not to use - I plan to provide more…
const elem = React.createElement('div', null, 'Hello World');
ReactDOM.render(elem, document.querySelector('body'));
It's 35.9kB gzipped, although "too big" is subjective. I may be unimaginative, but over my last 5 years or so with it, there isn't much I've wanted to change. As a library consumer, I don't personally mind if a VDOM is used or not, so long as performance is good enough not to ship a noticeably lagging UI to my users. Having experienced both React and Angular --one uses VDOM, the other not-- I haven't found this implementation detail to meaningfully impact performance, but I spent my time building straightforward CRUD apps.
I would consider sharing an example to Ari of something that's hard to do in React/Vue/Angular, and how it's made simple with AriJS. That might help elucidate where it shines, and the key problem being solved.
Re: Write Libraries, Not Frameworks
#40Just write whatever you want. I cite the following rule: Given enough time, the best code will inevitably be perceived as crap. – Ravenstine's Law