4 ms·

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

by fks 7y ago

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/ https://www.pika.dev/blog/pika-web-a-future-without-webpack/ Disclaimer: I created Snowpack & Pika (pika.dev).

core-questions 7y ago
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 7y ago
  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://perf.link - https://github.com/lukejacksonn/perflink https://github.com/lukejacksonn/perflink https://www.pika.dev 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 7y ago
    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 7y ago
      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 7y ago
        Now that web components are maturing, is there any working group that is chartered to improve the standard HTML UI compnent library?
        acemarke 7y ago
        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 https://github.com/WICG/virtual-scroller [1] https://blogs.windows.com/msedgedev/2019/10/15/form-controls-microsoft-edge-chromium/ https://blogs.windows.com/msedgedev/2019/10/15/form-controls... [2] https://www.smashingmagazine.com/2019/01/html5-input-types/ https://www.smashingmagazine.com/2019/01/html5-input-types/
pdimitar 7y ago
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 7y ago
  This does! :D
  - pdimitar 7y ago
    Sorry, which tool? Snowpack?
    - fks 7y ago
      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 7y ago
        Then I could see myself trying Snowpack. Thanks for the clarification.
  - mthoms 7y ago
    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?
ohithereyou 7y ago
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.
earthboundkid 7y ago
Why the name change? I was confused because I thought this was a competitor to Pika until I saw your comment.

by fks 7y ago

core-questions 7y ago

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 7y ago
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://perf.link - https://github.com/lukejacksonn/perflink https://github.com/lukejacksonn/perflink https://www.pika.dev 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 7y ago
  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 7y ago
    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 7y ago
      Now that web components are maturing, is there any working group that is chartered to improve the standard HTML UI compnent library?
      - acemarke 7y ago
        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 https://github.com/WICG/virtual-scroller [1] https://blogs.windows.com/msedgedev/2019/10/15/form-controls-microsoft-edge-chromium/ https://blogs.windows.com/msedgedev/2019/10/15/form-controls... [2] https://www.smashingmagazine.com/2019/01/html5-input-types/ https://www.smashingmagazine.com/2019/01/html5-input-types/

pdimitar 7y ago

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 7y ago
This does! :D
- pdimitar 7y ago
  Sorry, which tool? Snowpack?
  - fks 7y ago
    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 7y ago
      Then I could see myself trying Snowpack. Thanks for the clarification.
- mthoms 7y ago
  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?

ohithereyou 7y ago

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.

earthboundkid 7y ago

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