Is Hyperapp a library or a framework?

[jorgebucaran]

Hyperapp 1.0 is coming out soon (sooner than you think) and before the release I'd like to decide if we should present ourselves as a library or framework.

[zaceno]

Framework

[Swizz]

https://stackoverflow.com/questions/148747/what-is-the-difference-between-a-framework-and-a-library

The answer goes to Framework in the Hyperapp case.

[jorgebucaran]

Hyperapp sounds like in the middle of that.

See also: https://en.wikipedia.org/wiki/React_(JavaScript_library)

[tunnckoCore]

definitely a library. react is such too.

[zaceno]

There isn't much in way of formal, technical definition here, but that's not what matters. This is a question about branding and public perception. What do people expect when they go looking for a library vs when they go looking for a framework.

The way I see it:

You go looking for a library when you already have some code, and you're looking for a way to simplify or solve a problem without completely reshaping what you've already got.

You go looking for a framework when you're about to start something new (or a big refactor), and you don't mind (re-)shaping the bulk of your code to the requirements of the framework, as long as it means some problems are already solved for you by the framework.

Regardless of technical definitions it's the people who are looking for a framework that will be best served by hyperapp. So that's what it should say on the box.

[Zhami]

To me, a library is something one includes which provides specific functionality, whereas a framework connotes how things are done. Most frameworks are opinionated. When we constrain hyperapp to the browser, there's nothing that precludes a "page" from including other DOM manipulating mechanisms (each would own/manage different portions of the page's DOM). By this I would categorize hyperapp as a library. However, when we add other mechanisms, such as a router, or we integrate SSR and state hydration, we are moving into the domain of a framework.

I believe that there will also emerge a hyperapp way-to-do-things (such as how to compose a complex application and incorporate other mechanisms), which would constitute a framework.

This may be why hyper app feels like it is in the middle of the two. It may be useful to distinguish these going forward, though that may at first come across as confusing.

btw: I am new to the community here, and have been dabbling with hyperapp and appreciate it. I must confess to some great challenges in getting my apps to work because I'd look at examples, and they didn't function with the latest (0.16.2) version of the "library." Once the interface is stable (1.0), then I suggest that many of the examples be upgraded.

In support of my distinction here between library and framework, as I work to build a single- page application, I am confronting "framework" issues and questions regarding the best way to compose such an application. I am actually considering using multiple hyperapp instances to manage different parts of the application. I don't know if this flies in the face of Redux-like architecture practices. I don't mean to raise that question in this thread, but mention it because it supports my contention that such a question is one of framework (how to use hyperapp), and not library (what hyper app does).

I believe that the choice of positioning hyperapp as a library means that hyperapp can be adopted incrementally, even in an existing application, by having hyperapp provide for management of a portion of a page. I'd be interested to know if you concur that hyperapp can be adopted this way (incrementally). If so, that path should/could be promoted to gain adoption.

[zaceno]

@Zhami Yes, I'd say incremental adoption / incrementally porting is certainly possible with hyperapp. But it hasn't been a huge concern, in terms of api design, and I haven't seen any examples documented anywhere yet, so I'm not sure it would be wise to promote it too heavily.

At the same time it's an important thing for getting people on board. It's a bigger leap of faith to start a new project with a new framework, than to "dip your toes" by porting a small part of an existing app.

[mindplay-dk]

Micro framework: it's opinionated, but it only really concerns itself with one thing.

Picodom is the library version of Hyperapp: totally unopinionated, would support (micro) frameworks such as Hyperapp, as well as others with entirely different opinions.

(In fact, one may have wondered why the core of Hyperapp needs to duplicate the Picodom library internally?)

[whaaaley]

Library

Picodom is not the "lib version" of Hyperapp. Picodom is a vdom lib. Hyperapp is a state management lib with vdom. There are other standalone state management libs. Hyperapp has both. I use Hyperapp with other libraries to create apps.

[tunnckoCore]

@mindplay-dk yup. I am asking and thinking that from day one of picodom. It just not make any sense and definitely believe that hyperapp will/should use it for v1.

@zaceno @Zhami, agree. It's kinda hard to distinguish both things. When using hyperapp, you almost don't need anything other that what it gives you. Which makes me thinking it as framework, but i would bet on "library", because most of the people are some kinda scared when see "framework" and this might not play in positive way.

Aside of that, it already is promoted as "framework" in some articles, so... Don't know. I would bet on "library".

[SkaterDad]

I agree with @mindplay-dk about hyperapp being a micro-framework. It does concern itself with more than one thing, and mildly dictates your code structure.

[codingphasedotcom]

I would say micro-framework

[whaaaley]

Something that may be important to note is that you don't HAVE to use Hyperapp standalone. I've been eagerly waiting for @selfup to write an article about embedding Hyperapp into other apps. 😬 In this case would HA still be a framework?

[mindplay-dk]

One reason this is not a library, is because Picodom - a library - lets me choose my model approach: I can choose immutable models and pure action function, or I can choose mutable models and pure view-models/functions, e.g. the SAM pattern.

Libraries gives you architectural choices, whereas frameworks make them for you.

Granted, Hyperapp dictates basically only one (or two closely related) things, but that's enough in my opinion to make it more than just a library. Since it's only dictating one or two aspects and still leaves you with a lot of freedom of other aspects of architecture, I'd qualify it as a micro framework.

[okwolf]

I consider Hyperapp to be both a library and an app architecture (inspired by The Elm Architecture, but more flexible) that the library is optimized for implementing.

[selfup]

I am going to write that post soon I promise. Things have finally settled down for me 😂

In terms of Hyperapp, I still think it's a library. It has an API that enables you to talk to it via exposed actions. However there are some framework like aspects. But all APIs expect some kind of specific object/function regardless. Also some people can use Hyperapp with other frontend frameworks making it more in the library sector.

It is very very hackable, and the upfront opinions we share in the docs can be greatly ignored other than Immutable state and argument order.

So library/micro-framework is my vote 👌

[selfup]

Also like others have said, frameworks tend to be opinionated. Angular, Vue, Rails, Ember, etc.. all seem to have very favorable ways of writing stuff (if not forced ways of writing things - use of generators are pretty much the only way to learn how to use the frameworks themselves).

Just my 2 cents 😁

Vue is much more open and hackable, but they do have an official style guide and application architecture documentation. So I would consider it a framework even though it can be used like a library.

I would also say that the size of Hyperapp aides in it's library / micro-framework destinction 🎉

[zaceno]

@selfup I'm with you on a lot of points, but on this one:

It is very very hackable,

I have to disagree. The "key mechanism" - how the actions are bound to get access to & update the state, and repaint, is off limits. For example it's not possible to create new actions runtime.

It was a different story back when we had app events and custom events, and mixins. But this was all removed specifically to make hyperapp less hackable and more strictly enforce the "one way".

Not saying that's a bad thing, by any means. But anyone getting into hyperapp should be prepared to write their hyperapp code the hyperapp way.

That's why I feel it's a framework rather than a library. Micro-framework sounds appropriate too, though, since it doesn't have an opinion about everything - just state management.

It is true though, that this makes hyperapp quite integrate-able. So any code you don't want to write the hyperapp way can quite happily live on the outside.

[leeoniya]

it's a micro-framework.

[zaceno]

Sounds like regardless of where you stand on the "library vs framework" question most everyone seems on board with micro-framework

[okwolf]

I think we are a bit schizophrenic on this branding today.

Our description in GitHub and our package.json says:

1 KB JavaScript library for building frontend applications.

But then below that in the README.md it says:

Hyperapp is a JavaScript framework for building frontend applications.

[mindplay-dk]

Perhaps the definition is blurry because it kind of is a micro-framework with a built-in library.

Maybe it’s time to consider replacing the built-in library with picodom, as these are more or less identical anyhow? The definition would be clear to anybody then: picodom is the library, hyperapp is a micro-framework internally using that library.

The reason picodom was derived from hyperapp in the first place, is because the library part of hyperapp was an internal/private implementation detail - it was inaccessible as a library. Well, now the library exists and the two projects are basically tracking each other back and forth, trying to keep up with what the other project is doing and learning. I guess that could be beneficial, or it might be a waste of time?

Just a thought.

[Swizz]

As I request Picoapp since a while. We should make Hyperapp the framework that combine Picodom and Picoapp 🎉

(Joking, maybe)

[zaceno]

@Swizz, perhaps you mean picodom + picostate ;)

Anyway, I see where you're coming from and I kind of agree. I care a lot about picodom, and it'd be a shame to see it fall behind or diverge too far from hyperapp.

At the same time, I know the reason hyperapp doesn't depend on picodom today is because that would require a build step that would add unnecessary bytes. In the future that might be avoidable though.

[kosirm]

I think that it depends on intended use and in my case it is more framework than library. Anyway, current description is pretty good because hyperapp can be both. Who cares ... 😃

First thing which cross my mind when I think about this project is this:

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.

Antoine de Saint-Exupery

[jorgebucaran]

Let's go with "library" for official mediums, but everyone is welcome to think about Hyperapp as a micro-framework, view layer, framework, library, etc.

Thank you everyone for your input! 👋

[okwolf]

The more I think about this, I don't think this is actually a property of Hyperapp, but how you use it.

• Does it make up a small portion of a much larger app or is Hyperapp at the very top of your tree?
• Do you embrace the functional concepts encouraged by the project or just use it as a lower overhead library for writing MVC apps?
• How much of the supporting ecosystem (html, router, fx as data 😉 🔌 ) do you use or are you rolling your own solution around Hyperapp?

Ultimately, there isn't one answer to this for every user of Hyperapp.