[fks]

That's whats so cool about this: Unlike Create React App or other "starter apps" that try to hide complexity from you, Snowpack actually removes that complexity entirely. If you didn't want to use a single other tool, you could use Snowpack to build a fully modern web app by shipping your source code directly to the browser (cue the "View Source" nostalgia :)

Luke Jacksonn is someone who's done some interesting work in this space with zero-build-tooling sites: https://perf.link - https://github.com/lukejacksonn/perflink

https://www.pika.dev is built with Babel and TypeScript, so it's not technically "zero-tooling", but we still get almost instant iteration by skipping a "bundle" step during development.

[core-questions]

Even TypeScript having to compile down to JS for the browser just feels fundamentally wrong. Why write something in some new, domain-specific language that compiles down to an inferior language to run in the browser?

Hopefully with WASM we see the rise of client-side frameworks that bypass all of this bullshit entirely and give us a clean slate to develop on that picks up the best of the 90s low-code projects and makes them cloudworthy. There's no reason why 99% of the UI that most sites need isn't just assembled from a nice list of stock UI widgets.

Disclaimer, am old and miss 90s desktop apps

[acemarke]

Gotta nitpick here.

JS _is_ the native language for browsers. Therefore, it's reasonable to target it.

While it's entirely possible to compile your language interpreter of choice to WASM and run that in a browser, you're now in sort of the reverse position that folks complain about with Electron: adding tons of extra bloat, overhead, and complexity, just to duplicate some other runtime environment into a place it wasn't particularly intended to be used in the first place.

In addition, with most "compile other language to WASM" demos I've seen so far, they end up just drawing things on canvas, thus losing all the accessibility aspects that are built into the DOM already. (Yes, I know WASM has some DOM interop abilities and more coming, but that's not generally what I'm seeing done atm.)

What's _really_ needed is way better UI elements built directly into HTML, but those are sadly lacking.

[brylie]

Now that web components are maturing, is there any working group that is chartered to improve the standard HTML UI compnent library?

[acemarke]

There's been some discussion of making things like a virtual scroller available under an "std" global namespace [0], and the Chrome/Edge teams recently did a refresh of just the visual appearance of the standard built-in HTML inputs [1] (which, frankly, I think look even worse now).

Beyond that, nothing meaningful is happening. Even the input types defined as part of the HTML5 spec are still barely supported [2], and if browsers can't manage to implement decent date/time/range/color inputs, there's no way of getting more complex components designed and standardized.

Of course, the other aspect of that is, anything that is part of the web API is there forever, which means bugs and mistakes aren't really fixable. So, there's some benefits to having a purely community-driven ecosystem instead.

[0] https://github.com/WICG/virtual-scroller

[1] https://blogs.windows.com/msedgedev/2019/10/15/form-controls...

[2] https://www.smashingmagazine.com/2019/01/html5-input-types/

[brylie]

What framework-agnostic HTML UI component library would you recommend? Most of the options I have seen either have framework-specific dependencies (React, Polymer, Aurelia, Angular, Vue) or are just low-level frameworks for building your own UI/web components.

[lamplightdev]

Any UI library based on web components is your best bet for a 'framework-less' solution. Some more popular ones are:

- Material Design Web Components, https://github.com/material-components/material-components-w...

- Vaadin, https://vaadin.com/components

- UI5, https://sap.github.io/ui5-webcomponents/

[lamplightdev]

There's a video from the latest Chrome Dev Summit on this very topic https://www.youtube.com/watch?v=ZFvPLrKZywA&feature=youtu.be

[jeremyjh]

Are you actually going to write WASM by hand? Or are going to use a ... you know... compiler to generate the WASM from your source file? If you compiled Typescript to WASM instead of js, would that somehow be a different development experience?

[munmaek]

1. WASM is not a replacement for JS. You still need javascript glue code to actually load and run the WASM.

2. You're not writing WASM by hand, exactly like how you don't write assembly by hand. There's little semantic difference of compiling from <your_language> to WASM versus transpiling from typescript to javascript.

3. Typescript isn't really that new.