3 ms·

I always ship single file pages whenever possible. My original reasoning for this was that you should be able to press view source and see everything. (It follo

by andai 3y ago

I always ship single file pages whenever possible. My original reasoning for this was that you should be able to press view source and see everything. (It follows that pages should be reasonably small and readable.) An unexpected side effect is that they are self contained. You can download pages, drag them onto a browser to use them offline, or reupload them. I used to author the whole HTML file at once, but lately I am fond of TypeScript, and made a simple build system to let me write games in TS and have them built to one HTML file. (The sprites are base64 encoded.) On that note, it seems (there is a proposal) that browsers will eventually get support for TypeScript syntax, at which point I won't need a compiler / build step anymore. (Sadly they won't do type checking, but hey... baby steps!)

phatskat 3y ago
Do you happen to have any resources on writing games in TS? I will def google, but game development has always been oddly hard for me and I’ve been in typescript land for a while now so figure it’s a good time to try again
toastedwedge 3y ago
If I may ask, where can I read more about this? I wouldn't really know where to look for something like that, I'm afraid. Edit: wording.
teaearlgraycold 3y ago
The proposal: https://github.com/tc39/proposal-type-annotations https://github.com/tc39/proposal-type-annotations
slmjkdbtl 3y ago
I used to only do single file HTML pages too, until I have a page that have multiple occurrences of the same image, it's wasteful to have the dataurl string every time that img occurs. Maybe I can save the dataurl string in JS once and assign it to those img in JS, but most of the time my page doesn't have any JS it feels bad to use JS just for this.
- csande17 3y ago
  You could use the <use> element in an inline SVG to duplicate the same bitmap <image> to multiple parts of the page.
  - slmjkdbtl 3y ago
    Interesting, I'll try that later. But I guess that won't have some useful attributes on <img> like "alt"?
    - oneeyedpigeon 3y ago
      I found [this suggestion](https://stackoverflow.com/questions/4697100/accessibility-recommended-alt-text-convention-for-svg-and-mathml https://stackoverflow.com/questions/4697100/accessibility-re...), although it's pretty old. Maybe screen readers have made improvements to this scenario in the last few years? <svg role="img" aria-label="[title + description]"> <title>[title]</title> <desc>[long description]</desc> ... </svg>
noduerme 3y ago
Doesn't this make the dead screen time rather long if you have to load all the game assets before you can even display a loader? (I guess you don't even have or need progress bars?)
hasty_pudding 3y ago
how do you share CSS between pages?
- oneeyedpigeon 3y ago
  I'm guessing they use a build process to embed it inline in a <style> element.
  - andai 3y ago
    Yeah, for the CSS I don't even have a handler because it just goes right in the head. I don't usually have more than a few lines. Perhaps my use case is unusual though, I work on simple web apps, games, interactive simulations. I'm about to get into writing, and I expect a small amount of CSS will be sufficient for that too. Though that would probably expand over time, heh. You want to add a quote, and then a floating image...
_flux 3y ago
> On that note, it seems (there is a proposal) that browsers will eventually get support for TypeScript syntax, at which point I won't need a compiler / build step anymore. (Sadly they won't do type checking, but hey... baby steps!) Careful what you wish for. Assuming the browser is able to run original TS without processing and you want type checking, then that also seems to effecticely lock the typechecking abilities of TS to their current level. Even without type checking it would already hinder the ability to add new syntax or standard types to TS. Given TS is made for providing expressive typing over JS instead of constructively coming up with a type system with a language, there's still a lot of ground to cover, as can be seen by the improvements made in every TS release.
- Sammi 3y ago
  No the proposal is _not_ to include Typescript type checking in the browser. The proposal is to make the browser understand where the ts types are so it can _ignore_ them. So that you can write ts and have it be type checked on your machine, and them ship the ts and have it run on client machines _without_ any type checking running there. The browser will run the ts as though it was js. So the types will actually be able to be anything. It can be a completely different type checking superset language than Typescript even! Nothing will be locked at the current level. It's a frikkin magical proposal. https://github.com/tc39/proposal-type-annotations https://github.com/tc39/proposal-type-annotations
  - _flux 3y ago
    Here we can see concretely the benefits of TypeScript taking the strict stance of not generating any code, so basically stripping types will work. Though, weren't there some exceptions to that? It seems though the syntactical structures that are chosen to be ignored need to be listed in the proposal, making the support in browser non-trivial and still hindering the future extensions of TS and similar languages, because all future constructs would need to be supersets of this proposal—or whatever version is practically supported by current browsers. If a language brings up a new construct all the users of that construct need to revert back from shipping their source-code as is, increasing the cost of introducing such things in the future. Personally I don't see great benefits in having straight up TS work as-is in the browsers as you still need to run type checking phase locally, but I do see that some would like to see that happen and that it would simplify some release processes. It would not simplify the release process of folks that want to minify and obfuscate their sources, but it's probably fine to make that comparatively even harder ;).

by andai 3y ago

phatskat 3y ago

Do you happen to have any resources on writing games in TS? I will def google, but game development has always been oddly hard for me and I’ve been in typescript land for a while now so figure it’s a good time to try again

toastedwedge 3y ago

If I may ask, where can I read more about this? I wouldn't really know where to look for something like that, I'm afraid. Edit: wording.

teaearlgraycold 3y ago

The proposal: https://github.com/tc39/proposal-type-annotations https://github.com/tc39/proposal-type-annotations

slmjkdbtl 3y ago

I used to only do single file HTML pages too, until I have a page that have multiple occurrences of the same image, it's wasteful to have the dataurl string every time that img occurs. Maybe I can save the dataurl string in JS once and assign it to those img in JS, but most of the time my page doesn't have any JS it feels bad to use JS just for this.

csande17 3y ago
You could use the <use> element in an inline SVG to duplicate the same bitmap <image> to multiple parts of the page.
- slmjkdbtl 3y ago
  Interesting, I'll try that later. But I guess that won't have some useful attributes on <img> like "alt"?
  - oneeyedpigeon 3y ago
    I found [this suggestion](https://stackoverflow.com/questions/4697100/accessibility-recommended-alt-text-convention-for-svg-and-mathml https://stackoverflow.com/questions/4697100/accessibility-re...), although it's pretty old. Maybe screen readers have made improvements to this scenario in the last few years? <svg role="img" aria-label="[title + description]"> <title>[title]</title> <desc>[long description]</desc> ... </svg>

noduerme 3y ago

Doesn't this make the dead screen time rather long if you have to load all the game assets before you can even display a loader? (I guess you don't even have or need progress bars?)

hasty_pudding 3y ago

how do you share CSS between pages?

oneeyedpigeon 3y ago
I'm guessing they use a build process to embed it inline in a <style> element.
- andai 3y ago
  Yeah, for the CSS I don't even have a handler because it just goes right in the head. I don't usually have more than a few lines. Perhaps my use case is unusual though, I work on simple web apps, games, interactive simulations. I'm about to get into writing, and I expect a small amount of CSS will be sufficient for that too. Though that would probably expand over time, heh. You want to add a quote, and then a floating image...

_flux 3y ago

> On that note, it seems (there is a proposal) that browsers will eventually get support for TypeScript syntax, at which point I won't need a compiler / build step anymore. (Sadly they won't do type checking, but hey... baby steps!) Careful what you wish for. Assuming the browser is able to run original TS without processing and you want type checking, then that also seems to effecticely lock the typechecking abilities of TS to their current level. Even without type checking it would already hinder the ability to add new syntax or standard types to TS. Given TS is made for providing expressive typing over JS instead of constructively coming up with a type system with a language, there's still a lot of ground to cover, as can be seen by the improvements made in every TS release.

Sammi 3y ago
No the proposal is _not_ to include Typescript type checking in the browser. The proposal is to make the browser understand where the ts types are so it can _ignore_ them. So that you can write ts and have it be type checked on your machine, and them ship the ts and have it run on client machines _without_ any type checking running there. The browser will run the ts as though it was js. So the types will actually be able to be anything. It can be a completely different type checking superset language than Typescript even! Nothing will be locked at the current level. It's a frikkin magical proposal. https://github.com/tc39/proposal-type-annotations https://github.com/tc39/proposal-type-annotations
- _flux 3y ago
  Here we can see concretely the benefits of TypeScript taking the strict stance of not generating any code, so basically stripping types will work. Though, weren't there some exceptions to that? It seems though the syntactical structures that are chosen to be ignored need to be listed in the proposal, making the support in browser non-trivial and still hindering the future extensions of TS and similar languages, because all future constructs would need to be supersets of this proposal—or whatever version is practically supported by current browsers. If a language brings up a new construct all the users of that construct need to revert back from shipping their source-code as is, increasing the cost of introducing such things in the future. Personally I don't see great benefits in having straight up TS work as-is in the browsers as you still need to run type checking phase locally, but I do see that some would like to see that happen and that it would simplify some release processes. It would not simplify the release process of folks that want to minify and obfuscate their sources, but it's probably fine to make that comparatively even harder ;).