Skip to content

Instantly share code, notes, and snippets.

@mythril
Created July 16, 2023 16:41
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save mythril/cc13e2a644b2bdfbfc6415510471e61c to your computer and use it in GitHub Desktop.
Save mythril/cc13e2a644b2bdfbfc6415510471e61c to your computer and use it in GitHub Desktop.
web wish-list / ideas
  • Opinionated code formatter that targets making code better for maintainers and collaboration, not just being 'prettier' I.E. favoring things that make cleaner diffs over things that look nicer in the editor, specifically:
    • newline before each html attribute
    • newline before each "semantic unit" in CSS (for example each box-shadow portion, or background definition)
    • commas / list seperators at the beginnig of the line in css and in lists in general
    • ignoring unconventional line-breaking patterns under defined scenarios
    • general rule of thumb: simpler diff is more important than textual prettiness
    • anything that can change in isolation should be isolated (think one html attribute per line)
      • may be counters to this, for example, parameter definitions can get irritating if they are broken out too much
      • longish terms in 'if' statements might also be odd to break out
      • css classnames / html class attributes could be a nightmare
    • idc about spaces or tabs, but one should be the consistent choice
  • A complimentary tunable 'prettiness' formatter that can do whatever it is that people dislike about the above in a way that is only visible in their editor and doesn't actually change the way it's stored
    • needs to be idempotent
    • needs to somehow preserve the non-mechanical line-breaking stuff from above
    • general rule of thumb: if it can be configurable and still preserve idempotence, it should be configurable - this is for how the end-user likes it, not a collaboration thing
  • A tool that could identify edge cases in code formatting and suggest minor rewrites for readability & brevity
    • maybe suggest long terms in 'if' statements be named functions instead
  • web standards implemented as loadable, aggressively cached and optimized, wasm modules instead of built in to the browser
    • speed up implementation of standards
    • reduce security issues
    • reduce basically abandoned but sort-of-maintained-when-things-break-badly web standards
    • should have a way for vendors to override the standard with their custom integrations
  • a compression algorithm and standard dictionary that is aware of the common web standards token sequences
    • at least one standard dictionary set built into the browser
    • dictionary can be referenced as a small hash
    • Somehow this needs to be versioned so that it can be negotiated between client and server (idk why but I think a merkle tree might help)
    • implemented at a relatively low level (http, quic, speedy, etc) but have a mechanism so that you can specify where the dictionaries are coming from
    • HTML (and related) tags and attributes
    • javascript globals / DOM API names, keys and literals
    • non-custom CSS selectors and properties
    • small set of common tokens from popular libraries
    • search engines / browser vendors could probably analyse a ton of code to determine the best dictionaries in ascending "market share" order
    • generalized algorithms are probably good enough, but I imagine that a large corpo could save a lot of bandwith with a well-selected dictionary
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment