Road to V2

[WebReflection]

While latest API and logic is mature and battle-tested enough, there are few things that worked well but others that didn't shine in V1.

Following a list of things I'd like to improve for the next release:

• ES2015+ code. I'm happy about current hyperHTML compatibility and features detection capabilities, but the code is a little monolith written in old ES5, hence not too welcoming for contributors
• ES2015 modules. I'd like to split all internals in modules and utilities. This should give me the ability to produce a light version of hyperHTML that doesn't include method and wire adopt-ability
• there is already a 100% code covered viperHTML branch that produces layouts with hyper friendly comments in the right place. This would make hyperHTML adopt capability way easier, reaching attributes with ease but also making multiple placeholders discovery a no-brainer. Factoring out from main package adopt-ability would make hyperHTML lighter and hyperHTML.adopt accurate. Moreover, the current adopt logic is partially broken in core due unability to discover templates previously used.

This will be a big effort in terms of code refactoring, it will partially change/break current adoptability (an experimental feature not many are using so far anyway), but it will not change the API as we know it.

However, adopt will be not available by default (breaking change) and because of that I think V2 makes sense (as also previously suggested).

---

If you have anything in particular you'd like to see in a V2 please add a comment to this future-plan issue, thank you.

[kidwm]

would you prefer it to throw instead, if already defined ?

I have no preference on this, if I really want to avoid the collision, maybe I can use Symbol as the object key?

you are comparing apples and oranges. define is for utilities that can be shared across components.

Yes, FWIW, If I treat it like context in React, define would be a good solution and even better.

Last, but not least, if you have real-world use cases that cannot be solved with current primitives, please show them, thanks.

Sure, I'm working to port my react component to utilize hyperHTML, will ask you some questions about it soon.

[WebReflection]

if I really want to avoid the collision, maybe I can use Symbol as the object key?

in theory, yes. in practice, I'm currently using a for/in which would miss a Symbol as key. However, I think Symbol as transformer key are a solution to all the use-cases so ... thanks for the hint, I'll land ASAP!

Regarding throwing ... I don't think that's needed. The reason define is easy-peasy is that its purpose is to be easily mocked at runtime, whenever it's needed.

Sure, I'm working to port my react component to utilize hyperHTML, will ask you some questions about it soon.

happy to help, although I'm not sure this is the right place for doing it. Open eventually new issues, ask in StackOverflow using hyperhtml tag, or ping me via Twitter (DM open)

[WebReflection]

@kidwm FYI version 1.9.0 is now compatible with Symbols too

[WebReflection]

FYI, as extra proof that hyperHTML primitives are all there for our daily needs, a component helper just landed on npm to help solving connected and disconnected use cases, and without needing any change to hyperHTML itself.

Check hyperhtml-comp out.

[ematipico]

FYI version 1.9.0 is now compatible with Symbols too

Is there a changelog available somewhere?

[WebReflection]

I just wrote it:

version 1.9.0 is now compatible with Symbols too

the change log is in commits so far

[ematipico]

Yeah I know that you just wrote it. My question was about where is the changelog, not what you added in 1.9.0.

[WebReflection]

where is the changelog

where every change log is born in any repository here: commits

when you see the version bump, that's npm version minor/patch and before that you see fixes for bugs (patches) or new features (minor) described per each commit.

This is all I've got so far, it will improve once v2 is out.

[WebReflection]

FYI I've found a smart way to have better performance directly in core so hyperhtml-comp has been deprecated and version 1.10+ of hyperHTML will ship with component capables of connected and disconnected events.

Commits here: https://github.com/WebReflection/hyperHTML/commit/cfcc8e03e6d5bb6477982daaf0387491c4862929

[WebReflection]

P.S. this might be the last change before I completely rewrite the adopt part and, once fully green, rewrite the project for V2.

[WebReflection]

@esbenjuul why are you posting this here instead of StackOverflow? there is a hyperhtml tag there :wink:

[WebReflection]

Yes please

[mindplay-dk]

If you're going for a full rewrite, please consider Typescript, or fully JSDoc - which comes down to about the same thing, only you'd get so much more safety and strictness with TS (in strict mode) forcing you to write code that "does what it says" and to fully document everything as you go. It's worth the extra effort :-)

[WebReflection]

I have 100% code coverage to ensure what I write works the way it's meant to, TypeScript will never land in any of my personal projects, I'm simply pro standards.

[mindplay-dk]

I'm pro standards - I'm also pro type-safety. Each to his own :-)

[mindplay-dk]

@WebReflection just out of curiosity, what do you think about Flow and JSDoc and related tools?

From my perspective, they're essentially doing much of what Typescript does, but with the non-standard syntax hidden in standard comments, which IMO doesn't truly make them anymore "standards compliant" than Typescript - the compiled output of Typescript is standard JS (which is Typescript without the type-hints) and you'd "compile" Flow or JSDoc just the same to check and remove the type-hints, so the process and the mix of standards with proprietary type-syntax/checking are much the same. In my opinion, the only conceptual difference is Flow and JSDoc hide the proprietary syntax in doc-blocks.

I'm curious to know why you're so dead-set against Typescript though? We seem to have a lot of the same goals and objectives - I have many of the same minimalist points of view that you express in your blog posts and documentation. I view Typescript not so much as a language though - I view it mostly as a tool that helps me write correct, self-documenting, type-safe code with good IDE support.

Each to his own, I'm just curious to learn more about where you're coming from :-)

[WebReflection]

what do you think about Flow and JSDoc and related tools?

I wish flow was ECMAScript standard and I don't believe in JSDoc much 'cause I've worked with projects obsessed with it and yet I had no clue what the application using all those methods was doing.

Writing examples above methods that are contained to the method only also seem useless to me but yeah ... good documentation is hard either ways.

I'm curious to know why you're so dead-set against Typescript though?

• it's not standard
• it's a joke

I'm just curious to learn more about where you're coming from

I come from 18+ years of standards, advocating standards, and using them as much as I could.

The only issues I've ever really had in my experience as developers have been caused by non standard solutions.

The JavaScript i've written 18 years ago still works without any tool.

The ActionScript 1 doesn't work anymore, my old working projects are death. The ActionScript 2 doesn't work anymore, my relatively recent projects are death. TypeScript will do the exact same end of Dart. It's not standard, fewer and fewer will adopt it while JS will keep evolving through the standard path.

I've always bet in standards, and never[*] regret in doing so.

[*] ok, ok, WebSQL deprecation is still something I hate

[WebReflection]

worth clarifying that Dart is actually standard, but not de-facto standard for the Web.

[marcoscaceres]

My experience mirror's @WebReflection's: I've been burnt too many times by proprietary things like TypeScript: they are not well suited for libraries/project that are supposed to last a decade or more (such as this one).

On the JSDoc stuff... if it's demonstrable that something like Visual Studio Code would pick up the definitions out of the box, in an unobtrusive manner, then it might be worth discussing - but I think showing the benefit is a precondition to any consideration for inclusion.

[ematipico]

JSDoc are just comments that explain things. I do like it, it's not obstructive, are just comments that explain developers what is what. There are some IDEs or editors that take advantage of that and they give you autocomplete and such things, but it's just a bonus. Having comments is harmless

[WebReflection]

There are comments in hyperHTML and the API is basically two methods.

I just don’t care about strict jsdoc rules and I might prefer TypeScript definition file which AFAIK helps IDEs even more and it might be the only thing I like of .ts 😅

[WebReflection]

I’m also closing this since the discussion lost focus. V2 will come out soon, no extra addictions/changes will be made beside huge refactoring in terms of standard and modern syntax + better project structures.

Thanks for all hints and suggestions

[WebReflection]

P.S. adopt won’t be in by default in V2

[AlexGalays]

Just wanted to give you a different perspective.

The latest stateofjs proves you wrong regarding the fate of typescript, at least in the short term.

JavaScript is standard, but so is WebAssembly, so be prepared to see way more languages being used on the web in the future. Perhaps even multiple languages in the same project. This is a very good thing!

Writing tests for non nullable arguments, properties, number of args, etc is a complete waste of time.

lit-html may have taken tons of inspiration from this project (I have no idea but you wrote this much) but one thing is certain: the fact that it's written in TypeScript (and a pretty strict flavor of it at that) and will always have up-to-date typings is enough of a differentiating factor and pro for me and a few other people to not even look back at hyperHTML.

[pinguxx]

there is typing definitions provided by the community, if its missing parts, please do tell or help out to complete them.

I personally don't use typescript nor plan to use it, i like the flexibility of js.

If something is missing that can help you out on the development of your apps, i would like to know and probably the community would like to hear it too, but just saying typescript is better because it works for me doesn't mean this library or any other must change to it imo.

[AlexGalays]

there is typing definitions provided by the community, if its missing parts, please do tell or help out to complete them.

I personally don't use typescript nor plan to use it, i like the flexibility of js.

If something is missing that can help you out on the development of your apps, i would like to know and probably the community would like to hear it too, but just saying typescript is better because it works for me doesn't mean this library or any other must change to it imo.

I never asked for this library to change anything. I only said there is room for other "non standard" approaches and that is good.

I also like the expressiveness of JS but when types are externalized and the lib design is done without any consideration for typings, then you usually end up with something too awkward to type properly.

Also, I don't think there are typings for neverland?

[WebReflection]

@AlexGalays I've no idea who you are, where you come from, or why you decided it was a good idea to write whatever you wanted in this deadly old thread, but thanks for reminding me I should close deadly old threads because there's always someone with the will to attack me and this project for no reason whatsoever and dead threads are usually the best place to do so.