Echo JS 0.11.0

<~>

xweb comments

xweb 112 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!
xweb 112 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.
xweb 294 days ago. link 2 points
Mark - This is awesome! Great to have all the steps spelled out, and also the reasons why. Hope you will continue to iterate and really keep it current. Really useful resource as of today.
xweb 391 days ago. link 1 point
My #1 resource for interesting JS stories. Great job!
xweb 595 days ago. link 9 points
I am not sure if this is an anomaly or by design, but I downvoted three spam articles recently and seem to have lost 10 reputation for each downvote. If by design, this is a disincentive to downvote. 

A "report spam" link would be better, as calling out spam is really a different intent than downvoting.
xweb 630 days ago. link 2 points
Wow...reading this made me dumber. (As if that's possible, hah!) I read the whole thing waiting for some sort of insight or at least evidence of thought, but in vain. Why publish this? 

This clickbait has earned my first intentional downvote.
xweb 663 days ago. link 1 point
Here's the real link https://medium.com/@thinkfunctional/elm-architecture-with-jquery-152cb98a62f#.jjw86e6u3 - if this gets fixed, remove my downvote
xweb 838 days ago. link 1 point
This article is really a fantastic checklist of some node best practices to follow. Very practical and useful.
xweb 839 days ago. link 1 point
This seems like a very useful concept; hopefully it is functional in improving UI responsiveness and is adopted across browsers.
xweb 890 days ago. link 4 points
Maybe EchoJS should take it over? These were the two javascript news sites I really used.