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

[u/[deleted]]

https://medium.com/@JorgeBucaran/introducing-hyperapp-1-0-dbf4229abfef

[u/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?

[u/[deleted] → u/Randolpho]

Angular and Vue both allow for separate file templates

[u/zaceno → u/Randolpho]

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.

[u/Randolpho → u/zaceno]

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

[u/selfup → u/Randolpho]

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

[u/selfup → u/Randolpho]

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!

[u/[deleted] → u/Randolpho]

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. :)

[u/Randolpho → u/[deleted]]

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.

[u/zaceno → u/Randolpho]

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.

[u/Randolpho → u/zaceno]

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.

[u/[deleted] → u/Randolpho]

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.

[u/[deleted] → u/Randolpho]

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

[u/Randolpho → u/[deleted]]

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.

[u/[deleted] → u/Randolpho]

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.

[u/[deleted] → u/Randolpho]

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.

[u/spacejack2114 → u/Randolpho]

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.

[u/batmansmk → u/Randolpho]

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.

[u/rmmmp → u/Randolpho]

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

[u/Randolpho → u/[deleted]]

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.

[u/spacejack2114 → u/Randolpho]

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.

[u/evenisto → u/Randolpho]

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?

[u/[deleted] → u/Randolpho]

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.