[fks]

Frontend over-complexity is exactly the problem that this is trying to solve for! You can think of this as a simple post-install tool that removes a huge chunk of the complexity (bundling) from your stack, without limiting what you can build.

If this direction of simplified web development is something you're interested in, you'll enjoy this post I wrote back when we started this project (and it was called @pika/web): "A Future Without Webpack" - https://www.pika.dev/blog/pika-web-a-future-without-webpack/

Disclaimer: I created Snowpack & Pika (pika.dev).

[ohithereyou]

I would have hoped with a focus on security that we'd be moving to front ends that run less untrusted code on the client.

I would use a framework that did the majority of its magic on the back end and emitted either zero code that needs to run on the client or completely gracefully degrades when the client refuses to run untrusted code.

Every day it feels more and more like the web is a tracking framework with the lowest effort content that will keep the cattle clicking than an actual platform that provides real value. Being able to switch off executing remote code but be left with a functioning web experience would go a long way to providing real user privacy, which is, of course, why I have zero hope of it actually happening.

[core-questions]

Adding more tools to abstract and hide away the complexity doesn't actually make the complexity go away, though, does it? It doesn't make it easier to reason about the end result. Just hides it under a veneer.

I think what the guy you're responding to is after is similar to what I'd like to see: a front end that isn't composed of 20 years of hacks layered on top of each other because of poor initial choices.

[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/

[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.

[pdimitar]

I and others applaud the effort.

We are just saying that we'd appreciate something that removes the need for webpack et al.

I'd personally kill for a much simpler (and faster!) webpack.

[fks]

This does! :D

[mthoms]

This looks really great. Kudos!

A question for you: I see the site mentions using Snowpack with Vue but there's no guide like there is for React. Can you point me at some sort of "getting started" guide, blog post, or example repo for using Snowpack with Vue?

[pdimitar]

Sorry, which tool? Snowpack?

[fks]

Yup, from the tl;dr on the site:

> TL;DR - Snowpack removes the need for bundlers (Webpack, Parcel, Rollup) in a traditional application build process by leveraging the ESM syntax you're already writing. Keep using your favorite web frameworks (React, Preact, Vue, Svelte) & build tools (Babel, TypeScript).

[pdimitar]

Then I could see myself trying Snowpack. Thanks for the clarification.

[earthboundkid]

Why the name change? I was confused because I thought this was a competitor to Pika until I saw your comment.