Should HyperApp Wait For The DOM Before Rendering? about hyperapp HOT 14 CLOSED

Just to show how this fails when attempting to use a script in the head tag, check out this jsbin example. If you open up the console you'll see that the code fails when the app attempts to create the default root element.

I always attach scripts in the body, so I never see this issue, but #64 seems like a minimal change in order to support also including scripts in the head, which some users may do.

I also believe in the fail-fast mentality, so at the very least it might be worth noting in the docs that users should include scripts just before you need it, and no sooner, i.e. in the body.

from hyperapp.

Also related #64.

from hyperapp.

I'd prefer to keep it out for now. It's good to be explicit, and the majority have no problems with the way it is now. However, that being said I see both sides and I don't really mind if it gets included.

from hyperapp.

@terkelg Yes, since the subscriptions issue is fixed this doesn't bug me anymore either. I'm used to DOM frameworks breaking if not attached to an event listener.

It might also be worth it to investigate if window.addEventListener('load', () => app(...)) would not do anything if the load is implicit.

from hyperapp.

@tzellman Great coverage of the issue so far. I would also like to hear your feedback wrt whether it's our concern to do this for the user or transfer the responsibility to them.

Clearly you want to support this since that's what the PR is about, but is it the right thing to do?

from hyperapp.

@tzellman support also including scripts in the head, which some users may do.

Why would they do that?

Perhaps you can elaborate on this @dodekeract, since you were who first raised this concern in #61. 🙏

from hyperapp.

Yeah, I fully hear you on that. SoC is an idiom I fully subscribe to. I heavily use DI, so often it is assumed that you aren't allowed to start using something before it is properly initialized (e.g. via constructor/setter injection).

I think you won't see the issue in the first place since most users will properly initialize by ordering their scripts in the body. I can't say for certain that everyone will do this. There is a lot of mis-information online and it's only a matter of time when someone comes asking, so it's best to at least document the best practice.

The main reason I made the PR was because the change seemed very minimal and would actually not have any affect on current usage, plus it would support the non-ideal behavior of including scripts in the head.

from hyperapp.

@jbucaran Well, in my case I'm currently writing the Video SDK for @attach-live. It has to be easily embedded by as many third-party developers as possible. Hence I can't force the position where the <script/> is added.

It also may not be possible to add a <script/> to the body if you can't influence everything in the particular system (e.g. some CMS).

In addition to that I actually really dislike putting <script/>s in the body. It feels like a hack/workaround to me. I'm a fan of <script async/> though to prevent blocking script-loading.

I guess the reason why I don't like it is that CSS is embedded into the head too and I personally think that the body is for HTML, not JavaScript. I know that doesn't work with <img/> though (except if you only use CSS for images, lol).

from hyperapp.

No matter what is the use case, it is absolutely user job to include the app wherever he want. It is just enough to not crash and to work the same way. Please no magics.

It should be just documented that in case you want to include it in head then you should do this and that.

So 👎

from hyperapp.

If you look at the change in #64 then you'll see there is no magic.

from hyperapp.

@tunnckoCore I value your opinion, but I need to make sure you understand what @tzellman is proposing.

The idea is to only call the first render once the DOM has loaded. So, I'm not sure if it's really magic anymore. I'm still not sure though.

In the future, I'd like to support Electron, so it will be necessary to decouple the document API. That's simple enough, but I was wondering if Electron has something like DOMContentLoaded or what the equivalent is.

from hyperapp.

@jbucaran electron would be awesome. I think it actually has document inside the renderer-files though. Not 100% sure though since I never used it. Only used node-webkit when that was still a thing.

from hyperapp.

@jbucaran thanks! :) My "please no magic" was referred to the first post. As about #64 I didn't follow the discussion there, just reviewed the code for a sec.

Don't know. I'm not sure. I'm going to scan the #64 :)

edit: i like that question

What do other frameworks usually do here? Does anybody know?

from hyperapp.

This is implemented since 0.3.0 or 0.4.0, can't remember.

from hyperapp.