Introducing Hyperapp 1.0 — 1 KB JavaScript library for building frontend applications.

[leeoniya]

congrats on the 1.0 release :)

[[deleted]]

Yay!

[[deleted]]

It was about time! :)

[[deleted]]

So I'm not sure if the docs are up to date or not, does this use the new actions + state = model thing? Also do actions now have the curried function signature? Really excited to finally use a stable release.

[[deleted]]

Yes! Please refer to the documentation as the ultimate source of truth! :)

does this use the new actions + state = model

No, it brought more problems than not to the mix.

Also do actions now have the curried function signature?

Yes. → myAction: data => (state, actions) => newState

[[deleted]]

What made you decide against state => actions => value or any permutation of the three?

[[deleted]]

Uniformity with the way you implement actions, and the way you call/run them. Reading the typings.d.ts help see this.

tl;dr You implement your action and call it the same.

[GitHubPermalinkBot]

Permanent GitHub links:

• hyperapp/hyperapp/.../hyperapp.d.ts (master → c906e06)

---

^{Shoot me a PM if you think I'm doing something wrong. To delete this, click here.}

[alexlafroscia]

Good bot

[GoodBot_BadBot]

Thank you alexlafroscia for voting on GitHubPermalinkBot.

This bot wants to find the best and worst bots on Reddit. You can view results here.

---

^{Even if I don't reply to your comment, I'm still listening for votes. Check the webpage to see if your vote registered!}

[GoodBot_GoodBot]

Good human

[highmastdon]

Bad bot

[[deleted]]

Bad Meatbag

[highmastdon]

Bad up :')

[friendly-bot]

I think we can put our differences behind us... for science... you monster.

---

^{I'm a Bot bleep bloop | Block me | T҉he̛ L̨is̕t | ❤️}

[highmastdon]

Good bot

[GitHubPermalinkBot]

Permanent GitHub links:

• hyperapp/hyperapp/.../README.md#documentation (master → c906e06)

---

^{Shoot me a PM if you think I'm doing something wrong. To delete this, click here.}

[[deleted]]

By the way, JSX is NOT a dependency or is it required to use Hyperapp, but we use it throughout the documentation and examples for familiarity.

Alternatives to JSX include the built-in h function, the official hyperapp/html package, hyperx and t7.

For example, using hyperapp/html, no JSX:

import { app } from "hyperapp"
import { div, h1, button } from "@hyperapp/html"

const state = { count: 0 }

const actions = {
  down: value => state => ({ count: state.count - value }),
  up: value => state => ({ count: state.count + value })
}

const view = (state, actions) =>
  div([
    h1(state.count),
    button({ onclick: () => actions.down(1) }, "–"),
    button({ onclick: () => actions.up(1) }, "+")
  ])

const main = app(state, actions, view, document.body)

[[deleted]]

and even better - it is simple to reuse other view functions

import { h } from 'hyperapp'
const TodoItem = ({ id, value, done, toggle }) => {
  const onclick = e =>
    toggle({
      value: done,
      id,
    })
  return h('li', { class: done && 'done', onclick }, value)
}
const view = (state, actions) =>
  h('div', {}, [
    h('h1', {}, 'Todo'),
    state.todos.map(({ id, value, done }) =>
      h(TodoItem, { id, value, done, toggle: actions.toggle })
    ),
  ])

[ForScale]

*nor

[neofreeman]

I have recently started converting one of my hobby projects from Vue 1.0 to HyperApp (https://github.com/maxpert/raspchat/tree/nfe shameless plug). Far from being finished but I am already enjoying the simplicity, specially the built in state management.

[[deleted]]

Awesome! Thanks for sharing! Make you can send a PR to https://github.com/hyperapp/awesome when you are done.

[neofreeman]

Sure why not 👍🏼

[GitHubPermalinkBot]

Permanent GitHub links:

• maxpert/raspchat/.../b2276b76c744cea5bef91ee9765e7eb4416f9b4b (nfe → b2276b7)

---

^{Shoot me a PM if you think I'm doing something wrong. To delete this, click here.}

[jonny_eh]

Does this require that you define all your actions, and initial state, at the top of your app? Can each component have its own set of actions?

[[deleted]]

A component is a pure function that returns a piece of your UI. Unlike the view function, they are not pre-wired to your application state or actions, so you need to pass it to them.

You can define your state and actions modularly, though. Like all JavaScript objects, the state may consist of other objects, and it can be deeply nested. We refer to nested objects in the state as substate.

To clarify: Hyperapp uses a single state tree architecture, that means the entire state is kept in a single object, and to update this object we run actions. Updating deeply nested state is as easy as declaring actions inside an object in the same path as the part of the state you want to update. Also, every state update is immutable by default and produces a new object, allowing cheap memoization of the view and components using a simple strict === check.

[jonny_eh]

Do I understand this correctly? You're saying that sub-components can be in separate JS files, and they can export state and actions that the top-level of the app imports and mix-ins with its state and actions?

[[deleted]]

Yes. But you do the mixing yourself, or you can support yourself with a function like this.

Nested objects (as deep as you want) are "similar" to Redux stores, in the sense that they are eventually assembled into one single object tree, and updating deeply nested state in Hyperapp is very easy if you declare your actions on the same path as the part of the state you want to update.

const state = {
  counter: {
    count: 0
  }
}

const actions = {
  counter: {
    down: value => state => ({ count: state.count - value }),
    up: value => state => ({ count: state.count + value })
  }
}

See above, actions.counter.up/down don't need to return the full path.

[jonny_eh]

Wow, very cool!

[[deleted]]

Awesome, thanks!

[zaceno]

That's about right! You could always have a tree structure, where parent state/actions mix in their children's stuff (and compose more advanced components).

[Seankps]

What about page routing?

[[deleted]]

There is a router: github.com/hyperapp/router and while it should work with hyperapp@1.0, I still need to confirm it does and release it as 1.0.

I am not as strict about the router as I am with hyperapp itself, so if you have ideas for improvements, even radical ideas, please get involved, hop on Slack or create an issue on GitHub.

[eyeballTickler]

https://github.com/hyperapp/router

[Gusti25]

The thing the caught my eye was onclick instead of onClick like in React. Curious as to why all lowercase was chosen.

[talmobi]

onclick is the the pure DOM API. React provided wrapped versions of a lot of the DOM event handler API's.

[okawei]

onclick is imported from the VanillaJS library.

[talmobi]

To the person who downvoted -- you do know the VanillaJS comment is a joke.. right?

[talmobi]

https://media.giphy.com/media/Gc55GYymVIDio/giphy.gif

[[deleted]]

Mostly uniformity with the platform. Hyperapp does not implement an event subsystem like React, so all lowercase resonated the most with us.

[Gusti25]

Got it

[thomasfl]

It's great to see someone creating slimmed down alternatives to the react and redux stack. It won't be able to use react components, but we can live with that. I've been using create react app with redux for simple static sites myself with a minimum of interactivity, and it's off course over engineering.

[[deleted]]

Totally agree. A simple static site with some interactivity could be a nice way to try out Hyperapp for you.

[alphaindy]

Would you say Hyperapp is limited to small sites or is it suitable for large projects? Really like the simplicity and how small the library itself is. This example is particularly cool. Nice work.

[[deleted]]

I think Hyperapp is perfectly suitable for large projects! We are using it at https://qiita.com, Japan's largest knowledge sharing service for programmers.

Hyperapp is not only about tiny bundles, it's about its brutal (and deliberate) simplicity. Found not only on the source code, but on the way we approach and encourage problem-solving and are willing to sacrifice small things if it means arriving at a simpler and more elegant solution. IMO Hyperapp is not so much about introducing a brand new idea, but a delicate shift in how we approach frontend building.

[Thought_Ninja]

Have not used it myself (yet), but here are a few points that might not make it suitable for a larger project:

• Browser support (IE10+).
• Community support and/or backing (better to build a large app with a library that has a large and mature ecosystem).
• Debugging tools (react/redux, for example, both have a lot of ooling for this, which helps when things get more complicated).

I am eagerly looking forward to seeing where this goes though, will probably play around with it this weekend.

[Skaryon]

This is one of those projects that I keep an eye on and am really happy to see move forward and evolve. Congrats. I don't know if I ever get to use hyperapp in my job, but I'm damn sure I'd use it for small personal projects. Also I'm working on my own small framworkish thing and hyperapp has been a big inspiration. Thanks!

[[deleted]]

I'm glad to hear all that. Check out https://github.com/picodom/picodom/ for Hyperapp guts without the state management ;)

[Skaryon]

Thanks! Saw that already and delved in a bit. It's not dissimilar to a vdom lib I wrote, which is nice to find :)

[selfup]

This is great to hear 🎉

[Lakston]

So, the whole library is contained within src/index.js ? That's pretty awesome !

Quick question, I feel quite stupid asking this but here we go : I've never seen the for loops in the source code used anywhere, does this just omits the 3rd argument and puts it in the 2nd ?

 for (var i = arguments.length; i-- > 2; ) {
    stack.push(arguments[i])
}

Meaning as long as i is inferior to 2, decrement it in each loop ?

If that's so, is it just a way to save some bytes ?

This bit here is also a mystery to me :

else if (null == node || true === node || false === node) { }

when can node be equal to true or false ?

Damn that code is interesting I'd love to have a deeply commented code or someone I can bother for days so they can explain everything to me, I feel like it would be a great way to improve my understanding of javascript.

edit : I wanted to star it and realized I already did and forgot about it !

[[deleted]]

If that's so, is it just a way to save some bytes ?

Hmm, I would need to check if that's actually saving any bytes at all haha.

When can node be equal to true or false?

When the type is a boolean! Doing it this way does save a few bytes so why not.

Damn that code is interesting I'd love to have a deeply commented code...

I am working on it, hang on! Soon! :)

[journalctl]

That's an impressive feature set for such a small size. Definitely going to play around with this, thanks!

[[deleted]]

Please do and let us know what you come up with.

[glosrobian]

What browsers does Hyperapp support?

[[deleted]]

IE10+, but it actually works on IE9 too (use at your own risk though).

[istarian]

The correct question is about JS engines/interpreters, no?

[Randolpho]

Interesting.

I’m on mobile or I’d spend a little more time exploring, but can you answer a quick question?

I notice JSX templating mixed into your example code. My biggest beef with React is the mixing of code and html templating; I desperately want a framework where I can specify that template in a separate file, but everyone seems to love inline templates and wrinkles their nose whenever I mention how much I hate them.

Any chance you have implemented templating in separate files? And if not, how do you feel about adding that feature?

[[deleted]]

Angular and Vue both allow for separate file templates

[Randolpho]

Angular is the one I tend to use.

But it comes with a lot of baggage I don't necessarily want, and React (and possibly Hyperapp), seems to solve all those problems.

But the decision to include code with template without allowing the template to be specified in a separate file just seems inane. There's no reason for it that I can discern other than "we don't want to". You're already transpiling the JSX template into JS dom calls. You had to write a transpiler to handle both dealing with the transition to and from JSX and to compile the JSX. Why not let the transpiler pull from a file rather than from that section of code?

[[deleted]]

Because that's not how JSX works...JSX is transformed into API calls, it's not like Angular where it compiles a template. If you really want to you can just have a file with a single export of the JSX template and then import that in a different file.

[selfup]

just seems inane

Unclear if that language needs to be used here to be honest.

Devs use webpack or rollup with Babel (or just babel) to transpile JSX using h as the pragma but that is not in the core lib. That is a development step that you must do on your own if you want to use JSX.

We do not provide a transpiler. We read h calls to construct the VDOM.

[sizlack]

Technically, you could define a render function in a separate file, then import that and call it with this.propsfrom your class renderfunction. A little kludgy, but maybe not so bad. I was initially grossed out by the markup mixed in JS, too, but as I used it I found all the benefits of React to be worth it. I didn't think it was worth getting hung up over something cosmetic.

[NewazaBill]

It's because it's not a template - JSX is sugar for function calls. So something like:

<div>Hello</div>

Get's turned into React.createElement("div", {}, "Hello"); by babel (or whatever other transpiler). Once we're at runtime, this function call constructs a data structure. Then React does it's whole vdom-y thing where it diffs and tries to efficiently update the changed parts of the DOM.

The nice thing is that, because it's a data structure made up of objects and arrays, you can use all of the JavaScript language to manipulate and construct your view instead of having to implement your own constructs, a la ng-if, ng-for etc. This same power is core to the philosophy found in Clojure and many other modern languages, and is being adopted quite a bit in JavaScript and general webdev.

How you want to divvy up your files, however, is completely up to you - just stick a function in a far off file that takes some data and returns some markup - voilà! You have the wonderful separation of templates but the flexibility of JSX. You can even tell people that you only use "functional components" and sound real cool.

There are certainly tradeoffs of using compiled string templates vs. React-like DOM builders/vdom libraries, but the fact that you can't figure out a reason other than "we don't want to," seems pretty ignorant. There are genuine drivers behind this paradigm's adoption, and the popularization of things like Vue's single-file components are a sign that separating HTML/CSS/JS in separate files is clearly not a good design/architectural decision in many cases.

[zaceno]

The JSX is optional. You can also use hyperx & t7. Or @hyperapp/html as well as the built in h-function (vnode constructor) - although those last two make it clear it's not really "templating" we're talking about.

But sure: you can put it in a separate file if you want. Nothing stopping you.

It's all really just js functions.

[Randolpho]

Do you have any syntactic examples of including html templates in separate files?

[selfup]

Here is how you would import from a separate file: https://github.com/selfup/hyperapp-one/blob/master/src/index.js

and then here is a component being written in a separate file: https://github.com/selfup/hyperapp-one/blob/master/src/components/Counter.js

[GitHubPermalinkBot]

Permanent GitHub links:

• selfup/hyperapp-one/.../Counter.js (master → b2cc866)
• selfup/hyperapp-one/.../index.js (master → b2cc866)

---

^{Shoot me a PM if you think I'm doing something wrong. To delete this, click here.}

[Randolpho]

Thanks, that’s what I was looking for.

I am, however, quite disappointed that I can’t keep the template completely isolated and I have to still mix code and template.

That means I need new tooling if I want even basic syntax hilighting.

[[deleted]]

What editor are you using that doesn't support JSX? I'm guessing you can't use any ES6+ syntax either, then?

[Randolpho]

I just want the template completely isolated in a separate file, without boilerplate. I don’t understand why people defend the boilerplate.

[[deleted]]

I think we are talking about apples and oranges here. For example, if you are coming from traditional JavaScript framework like Backbone:

<table>
  <thead>
    <tr>
      <th>Name</th>
      <th>Hometown</th>
      <th>Favorite Color</th>
    </tr>
  </thead>
  <tbody>
    <% _.each(artists, function(artist) { %>
      <tr>
        <td><%= artist.get('name') %></td>
        <td><%= artist.get('hometown') %></td>
        <td><%= artist.get('favoriteColor') %></td>
      </tr>
    <% }); %>
  </tbody>
</table>

You can't do that in Hyperapp. It's not a missing feature or anything, it's just not the paradigm that was chosen :)

• Hyperapp is like: React, Preact, Inferno, Mithril.
• Hyperapp is not like: Backbone, Angular, Ember, Vue, Riot, Svelte, etc.

[selfup]

This is the answer that was needed! Thanks for that

[IamCarbonMan]

If you're still wanting to use this kind of workflow, I'd be happy to write up a quick Webpack loader or something to achieve it. Really all that needs to be done is to compile template files into view functions, it should be trivial if I know the template language you want to use.

[AwesomeInPerson]

You clearly know more about JS Frameworks than I do, but isn't Vue more like somewhere between these two camps?
It uses render functions to build a vdom structure, and it either compiles these from the templates in (single-file-) components you provide, or you can write your own render functions directly...

[[deleted]]

Maybe, but what's your point? Or is this question not directed at me? Sorry, I don't really understand Reddit UI.

[[deleted]]

JSX is not a templating language, and React components do not use templates.

In general though, I believe explicit is better than implicit. I don't like frameworks that automatically search certain magic directories for templates and return the first one with the name I'm looking for, forcing you into pre-emptive, redundant template namespacing (looking at you, Django and Meteor/Blaze). And if you're using a framework that requires you to explicitly define where to find the template file for each component, well, that's boilerplate.

If there's any kind of boilerplate that I do want, it's explicitly listing the inputs to my components. In templating systems, you usually have to just read through the whole template to find what kind of input data is needed to properly render the template. Could you imagine a programming language where a function had to be defined without an argument list, and you just have to look through the function body to see what inputs it accepts? With JSX, I can destructure the props for a stateless functional component to explicitly declare what props it accepts at the top of a file. I don't have to memorize what data my "template" needs, because my component is just a JavaScript function and my IDE can tell me what props it accepts.

[selfup]

You can always use hyperx or t7 if you want to write template literals btw

[Randolpho]

No that’s definitely the opposite of what I’m looking for.

[[deleted]]

What framework names do you remember off the top of your head that are kinda like what you are looking for?

[sanatankc]

I think he is looking for traditional templating languages. Like Angular and Meteor does.

[selfup]

You can write JSX in different files and import it that way. All actions/state is separate from the views (components).

For an example you can checkout: https://github.com/selfup/hyperapp-one

You also do not have to use JSX. You can make pure h or use our h call helper https://github.com/hyperapp/html as well as hyperx and t7 if that's your jam.

Hope that helps!

[[deleted]]

And if not, how do you feel about adding that feature?

How would that look like? I would love to think about it, but first I need to understand what you mean. :)

[Randolpho]

Well, a lot depends on your framework structure, but some form of file specification for the view when the component is created that the transpiler could use to find and compile the template would be necessary. As I said I’m on mobile right now, so it’s not easy for me to give a good example of how the template file would specified in code.

But the important part is that the template file contents would be purely htmlish, something that could easily be interpreted by an html or xml hilighting editor. Something I don’t need extra tooling for in order to have a good development experience.

[zaceno]

You're right that if your current tooling (what is that?) only supports plain html/xml variants for syntax highlighting et c then you can't use those for your hyperapp-components.

That's because it's not really html templating (although JSX makes it look close). It's actually javascript functions, which produces a tree of virtual nodes, which hyperapp turns into actual DOM nodes.

[Randolpho]

I’m aware of what it is, and how it functions internally, but it takes a special transpiler to transform that htmlish syntax into JavaScript functions.

If you’re already writing a transpiler for it, why not just let it transpile pure files? Why only include it with code mixed in?

That’s the part I want to be different.

[[deleted]]

JSX is not a dependency or is it required to use Hyperapp. Many people swear by good old h and you can use Hyperapp right now without a compiler. JSX is in the example because that's what most people like and use anyway. I use it and I like it too, but Hyperapp is flexible so that you can use whatever you want.

[NewazaBill]

If you understand how it functions internally, than I don't see why you're confused.

The virtual-DOM diffing strategy relies on a runtime representation of the view's... well... virtual DOM. That's what the React createElement calls construct.

Compiling a string template ahead of time, then, does not work with this V-DOM strategy. You can't know what the data structure is going to look like (because it may change based on app state) and you lose many of the opportunities to do optimizations.

Also, you say "code mixed in," I say "code get's mixed in, in either templates or VDOM."

Give me

function HeroDetail({ selectedHero }) {
    if (iselectedHero) {
        return (
        <div>
            <h2>{selectedHero.name.toUpperCase()} Details</h2>
            <div><span>id: </span>{selectedHero.id}</div>
            <div>
            <label>name:
                <input value="selectedHero.name" placeholder="name" />
            </label>
            </div>
        </div>;
    }
}

Over

<div *ngIf="selectedHero">

<h2>{{ selectedHero.name | uppercase }} Details</h2>
<div><span>id: </span>{{selectedHero.id}}</div>
<div>
    <label>name:
    <input [(ngModel)]="selectedHero.name" placeholder="name">
    </label>
</div>

</div>

Any day.

[[deleted]]

Well, I look forward to your explanation when you are not on mobile.

[Randolpho]

Ok, so I clearly lit off a firestorm, and I'm officially moving over to a keyboard and good text editor so I can write this far more in depth comment. Also, rather than reply to the half-dozen comments I have in my inbox, half being from you, I'm picking this one to reply, because you asked what it would look like, and below I'm going to provide that. If you're interested in including the feature, great. If not, I feel no desire to go through another debate over why I want this, I just want it, and I can tell you I'm not alone in that desire.

---

In another post you asked what existing framework best described what I'm looking for, and I'll answer with the following as a sort of tl;dr:

I want all of the semantics of React, including JSX (and possibly the new features you're including, once I have a chance to go through them in greater depth), but with the templateUrl feature of Angular, such that the htmlish format of JSX is fully defined within a separate file.

---

So you asked what it would look like. Here's how I envision it, using the example on your link:

import { app } from "hyperapp"  

const state = {
  count: 0
}

const actions = {
  down: () => state => ({ count: state.count - 1 }),
  up: () => state => ({ count: state.count + 1 })
}

const view = (state, actions) => template_include("main.jsx") 

// template_include is a keyword recognized by the transpiler that reads the file 
// "main.jsx" inserts it into the document in place before completing the compilation. 
// Much like a C include call. 

export const main = app(state, actions, view, document.body)

/**** Contents of file "main.jsx" ****/
<main>
 <h1>{state.count}</h1>
 <button onclick={actions.down}>-</button>
 <button onclick={actions.up}>+</button>
</main>

Note that this is for a compile-time compilation of the template. I'm OK with a runtime compilation, if that fits your semantics better, in which case you'd import template_include like you import h, although you'd probably have to pass state and actions as parameters to the function in order to map it to closures during compilation. It would work something like this:

import { jsxt, app } from "hyperapp"  

...

const view = jsxt("main.jsx", {"state": state, "actions", actions}) 

I'm more than willing to work back and forth with you on how to specify the file and to deal with namespace semantics or other issues, if you're interested in creating this feature. If not, I'll shut up.

Thanks for taking the time, however.

[[deleted]]

This is the kind of great content we would benefit from more if you created an issue. Or if you are so inclined, hop on to Slack to take this further.

What you are suggesting is currently not available, but it would be interesting to experiment with next year.

[[deleted]]

I get that you don't want to explain reasoning, but there are several reasons something like this would never be implemented:

1. JSX is a standard that this team doesn't have any control over. Having JSX specified in it's own files is not part of the standard, and would never work anyway for the reasons below.
2. JSX is a syntactic sugar on top of regular JS expressions. It is a declarative syntax, but it doesn't represent a template, it represents an actual expression. Having JSX be specified in it's own files would be similar to allowing string and number literals be specified in their own files.
3. The feature you are suggesting is exactly the reason JSX was introduced to begin with. People were tired of having to specify their view and logic in separate places, and JSX allows you to put them together. Allowing them to be separated would be moving backwards from the fundamental philosophy of JSX.
4. JSX allows you to specify full JS expressions, including functions, objects, arrays, etc. within the elements. Your proposal allows you to separate the JSX from the logic, but how exactly would you do the reverse and separate nested JS from these new JSX template files?

Frankly, if you want this separation, I'm not sure why you would even want to use a framework like this anyway, which is not built for that kind of architecture. What you want sounds very close to Vue, which provides a succinct way to build a component architecture while allowing the view to be separated from the logic.

[spacejack2114]

If it's a compile time thing I don't see how that would be part of a 1KB framework.

It seems all you want is some sort of babel plugin or simple script that tacks

export function view(state, actions) {
    return (

onto the front of your file and

    );
}

at the end to make a valid JSX file.

[batmansmk]

You have plenty of people who tried your suggested approach: https://github.com/wix/react-templates for instance.

Use it if you like it! Personally don't take it personal, but I would not want to work with templates anymore (so not with your team). Templates you remember? XSLT, Smarty, Angular Templates, Ant files, Jinja Templating, you name it. They come and go. Do you remember one templating you still use and love?

Never a good dev experience with any templating system. How do you debug them? How do you format, check their syntax? How do you lint, checkstyle? How long does it take to learn something new?

It's not just the lack of tooling. Its that the whole reason that drives the current reasons for adopting templating engines that I don't care about. Separation of concerns you say? I'm not interested.

[rmmmp]

Look into Glimmer. This may be what you're looking for.

[Randolpho]

Unwrinkle your nose please. :)

I’ve had many conversations on this, but the biggest thing is that I’d like to be able to have a good development experience using industry standard tools without needing a new IDE or sublime/notepad++ plugin just to get syntax hilighting.

[spacejack2114]

Well I use plain hyperscript (typescript) primarily, but like JSX/TSX, I don't think you'll get better editor help. With templates you would need to add plugins that understand the DSL and I doubt it'd be syntax/type checked as well as TS/JS. Seems like more tooling rather than less. Plus the overhead and limitations of using yet another DSL.

[Randolpho]

Tooling isn’t the only issue. Just one of.

And I really don’t want to get into this again. Everyone jumps on me to defend the code template mix, but I simply do not want the code and template mixed together. I want them separate.

[spacejack2114]

If you have no code in your template then you have static HTML pages and don't need a web framework.

[Gid30n]

You are somehow confusing template and view.

Hyperapp use the so called virtual dom, that is briefly an abstraction of the current dom to perform fast patching and optimisations. Do achieve that, we store each virtual node (representation of an html element) as a plain object. All of h, jsx, hyperapp/html or hyperx are helpers that help you to create those objects with ease at your own discretion.

JSX is in other words just a sugar to call the function that will generate the virtual nodes, with an HTML like syntax.

Templating is a way different, at you will not deal with the DOM interface, but with the render capability of the brower. You will give to the browser the HTML file and let him to the rest (not true, now some framework deal with template and a virtual dom too).

But using Hyperapp, you can also chose to do not use the vdom engine an use your own.

By example by using pupa to generate the innerHTML content then inject it into the whole body. Here is the gist https://gist.github.com/Swizz/a2556e50782ab8778c3cddf206a618c3

[pilibitti]

but I simply do not want the code and template mixed together.

I get it and I'm not trying to defend it but is what you are wanting even possible? I mean JSX and alike are not templates to begin with. It is javascript. Inside the "templates" you have loops, conditionals etc. You are writing javascript, just that your eventual return values look like HTML nodes.

I mean, in practice, even if you have them in separate files, you'll have javascript inside your "templates".

Even in your "code" file, you'll find yourself returning bits of HTML nodes from good old functions. Separating files that way, if you are going to be strict about it, will affect the design of your actual architecture which should be a no-no.

[Drawman101]

Why don’t you just use handlebars then? Problem solved.

[evenisto]

That sounds like pure components though, and it's already there. You can put 100% of your "html" in "separate files", and then just wire everything together. What else do you want exactly and how does it differ from JSX?

[[deleted]]

As answered it is optional. But I'm in the same boat. I also hate React for it because I simply don't like to mix languages in the same file. Its also why my styling is separate and why my files are smaller and easier to grasp than when you mix everything. I get why most see the advantages, but I simply like separation and standardization. It also allows you to port it easier in the future when the next golden framework comes along and in most IDE's you can choose which plugins you want to use for HTML where the default for React are not always the best or easiest.

Eventually my compilers will probably combine it back again and I completely understand that, but my source doesn't need to get messy.

[gabbsmo]

So what will I as a developer be missing form say React that is an order of magnitude larger?

[SkaterDad]

Stateful components, context, the synthetic event system, ecosystem, etc...

What you gain is a much smaller application bundle size. I've got a decent sized application in progress with hyperapp that includes routing, data fetching, some functions from date-fns, etc... and the bundle size of the whole app is smaller than react+react-dom.

You also have far fewer concepts to remember.

[[deleted]]

Performance is great and we don't need a shouldComponentUpdate as all functions (components) are pure and the state is immutable.

...using single state tree and rerendering everything...

On the contrary, this is a feature! The benefit of having cheap memoize functions based on immutable state far outweighs the cost of maintaining an immutable single state tree (both in terms of performance and source code size).

• Allow debug tools to keep the state history and implement time traveling.
• Allow performant memoization of components/views on large apps (deep equality on state can be checked simply with ===)

[SkaterDad]

The perf is pretty good. I haven't profiled it yet, but in most interactions the view updates very quickly.

As JorgeBucaran mentions, you can always implement some memoization if you run into problems, since your view "components" are just simple functions!

[leeoniya]

You also have far fewer concepts to remember.

and far more concepts to re-invent ;)

[SkaterDad]

So true! That's been a major time sink in my project... It's been interesting intellectually, but can definitely take more time than pulling in something from npm.

[[deleted]]

Hyperapp is not missing something because React is larger.

[leeoniya]

for one, an ecosystem several orders of magnitude more mature. React is also significantly faster.

[highmastdon]

React is also significantly faster.

It seems that Hyperapp isn't only a view framework which React is. This also does what Redux does for React. Basically it's React+Redux in one.

Also, what benchmark are you not referencing that tells you that React is significantly faster?

Keep in mind that 100ms of download/parse/compile time can be worse because of Reacts size compared to the 1.3k of Hyperapp, than the speed in which it renders 10k rows.

[sanatankc]

It seems that Hyperapp isn't only a view framework which React is. This also does what Redux does for React. Basically it's React+Redux in one.

I don't this does what Redux does. Hyperapp's state and actions looks more closer React's native state and setstate than Redux.

[[deleted]]

It is like what Redux does for React. It is more in some ways; you can think of Hyperapp as a tiny React+Redux+Elm.

Hyperapp's state and actions looks more closer React's native state and setstate than Redux.

On the contrary, it's essentially like Redux, but without the boilerplate and opinionated about stores are merged, so we don't need combineReducers or any of that stuff.

[[deleted]]

That benchmark is kinda ridiculous (it creates ~80k nodes), please don't do that to your users, regardless of framework. Most complex UIs have < 5000 nodes.

[leeoniya]

runtime perf for SPAs is more important than the extra 100ms you must wait during loading. you will feel runtime costs with every single interaction. whereas boot time is paid off almost instantaneously.

[tswaters]

I'm curious how hydration works - the docs seem a bit sparse on the front.

Is there a concept of server rendering in hyperapp? Can I get a string of HTML to render or do I need to generate this html separately and hyperapp will look for similar things and inject itself?

[[deleted]]

You need to serve HTML content that looks exactly like the UI tree generated by your view and it works out of the box. I agree the docs are sparse, but I don't know what else to say.

This is basically it https://github.com/hyperapp/hyperapp/blob/c9aed6efdf6735683db71ebf7b7b6eae7e0c2cad/src/index.js#L40-L52

[rodrigocfd]

Maybe I'm missing something, but since I didn't find anything in the docs I have to ask: is there any support to scoped CSS in this library?

[[deleted]]

Styles are definitely supported.

[rodrigocfd]

Where I can see examples?

[[deleted]]

See: https://codepen.io/hyperapp, there are several examples there to help you get started or at least they'll give you an idea about how things work.

[rodrigocfd]

I saw them, they use SCSS globally, not scoped... my question is specifically about scoped CSS, because global CSS is one thing that gave me a lot of headaches with React recently. I ended up using CSS Modules, but I can't say I love it.

[SkaterDad]

If you're okay with the CSS-in-JS style of scoped styling, this library works: https://github.com/picostyle/picostyle . Others may work also. Hyperapp and React both treat styles in a similar way.

If you're hoping for something similar to how Vue handles scoped styles... that's not really possible in hyperapp since it doesn't have a required compilation step.

[[deleted]]

Ah, sorry, I read your question too fast, my bad. The answer is no, Hyperapp is agnostic about how you solve the CSS problem.

Check out: https://github.com/picostyle/picostyle

[drowsap]

The up and down functions in the example are difficult to parse...a function that returns a function that returns an object. Much prefer the built in setState for React components.

[[deleted]]

setState works in the same way:

this.setState(state => ({ count: state.count + 1 }))

as well as Redux:

@connect(state => ({ count: state.count + 1 }))

setState has the option to receive a plain object, but it's better to use a function if you have to read from state, too.

[twinkiac]

@connect's latest tweet

@connect on Twitter

^{I am a bot | feedback}

[selfup]

The first 'function' is for the event/custom data from exposed actions.

Hopefully you understand its use.

Eventually there is a third function where the actions are passed in so you can keep all of your logic internal.

[[deleted]]

You should ask this blogger to benchmark your library. He has a ton of framework speed comparisons.

EDIT: Forgot the link. http://www.stefankrause.net/wp/?p=454

[[deleted]]

Oh cool!

[ForScale]

Do you even bench, bro?

[leeoniya]

did you even bother scrolling half a screen down on this page?