Echo JS 0.11.0

<~>
xweb 2677 days ago. link 3 points ▲ ▼
Just speaking for myself, I am continually surveying the landscape for the "right" view library. I have an aversion to boilerplate and to having to manually trigger updates that has made me distrustful of React, so I am always on the lookout for other libraries. The discussion in the hacker news article re-triggered my interest in Marko, because I think it better suits that aversion. Here's the list of alternatives I currently consider possibilities:

- Hyperapp
- Marko
- Mithril
- Cycle
- HyperHTML (not much traction, confusing docs)

Preact and Inferno seem great, but by retaining the React style, they are not right for me.

Always looking for something new that is the right lib for me. Maybe I should just write it myself. :-)

Here's the list of want-to-haves I am looking for:

1. Small client-side footprint, fast loading for mobile.
2. Little-to-no boilerplate (extra code increases cognitive load).
3. Mostly "regular" JS/HTML/CSS - use the browser capabilities as best as possible.
4. Reactive/watch functionality.
5. No two-way binding. Use an update-emit-redraw cycle. (I.E. React, Elm)
6. Simple template language, preferably ES2015 template strings.
7. Able to drop a single component into an existing page (not SPA or bust).
8. Functions, not reliant on classes. (Classes are a code smell to me for best-practice javascript dev.)
9. Great documentation (this is a big challenge for the smaller projects to get momentum).
10. Don't swing the pendulum too far to functional development. I'm just a self-taught guy, I don't care if the library meets some abstract mathematical definition of what a function is. To be clear, I absolutely LOVE pure functions and strive to build them, but ease of developer use is more important than the abstraction.

I've come around on the build step, having used Webpack for my last project because I wanted to use ES2015 features safely. It is great.

I watch this website (echojs), hacker news, reddit, for evidence of new libraries that would suit me. Thanks for that purfectstack link, that is great.

Replies

bigopon 2677 days ago. link 0 point ▲ ▼
Its nice that you mention hyperHTML, may I ask which part of the docs seems confusing?
xweb 2677 days ago. link 3 points ▲ ▼
Well, in general, for me, they lack somewhat the context for decisions. So, to take for one example, the discussion of partial attributes here: 

https://viperhtml.js.org/hyperhtml/documentation/#essentials-7

I read through this section, and I have the following questions. Please bear in mind that I am not a trained computer scientist, mathematician, or language designer. I'm just an everyday web developer who's been doing this for 20+ years. I'm not trying to pick hairs, but these are genuinely the questions I have on reading this section. 

Questions:

- What is a partial attribute, and why should I care that it is not supported? I presume this is a counter-reaction to something in Angular or React or some online discussion of framework design, but I don't know why it is relevant to know this.

- So, I see the difference between these two lines, but I don't quite get why #2 should be problematic, and the discussion in this section does not really explain it:
1) html`<div style=${`top:${top}; left:${left};`}>x</div>`;
2) html`<div style="top:${top}; left:${left};">x</div>`;
Like, what if I have a set of classNames on an element, but they are toggled from different sources. Doesn't that seem like it would work more like #2? I mean, I do think I get that you're saying that there are performance costs to splitting up an attribute that has multiple values. It's just not clear why this has to be discussed specifically to this length, and what breaks when I try #2.

Not trying to rag on the library at all - and by the way, I feel like these docs are much improved over the earlier versions - just trying to explain my comment above. I will take another crack at it now that the docs are so much more explicit. 

In fact, I'd suggest in order to take off, hyperHTML needs more "soft" content comparing specific features and tradeoffs made vs. the other libs. Articles and tutorials and deep dives and stuff.

Like, I read this under "API": 

"Even though hyperHTML is a function, it should be used as a namespace.
Every method is detached from its context so that you can easily destructure them.

const {bind:hyper, wire} = hyperHTML;
 
hyper(document.body)`
  ${wire()`<h1>Hello Content</h1>`}
`;
"

I can only say, huh? 

It's clear that a lot of thought went into the choices made for this library, but not as clear why those choices matter, and how they inform the decisions I will make as a developer. 

I'd go so far as to say that documentation drives the success of Vue as it did React before that, more so than the technical merits of these libraries. I want to believe that hyperhtml is the superior choice, as it feels "right" to me, but the path from liking it to using it seems daunting.

Anyway, keep it going - I like what I see!