7 ms·

Although I've contributed to some React projects, the last time I had to do user-facing web frontend stuff was with the original Angular. Looking at this, I'm r

Although I've contributed to some React projects, the last time I had to do user-facing web frontend stuff was with the original Angular. Looking at this, I'm really glad I don't do frontend anymore. I've touched some vue.js too, but I just hate the direction everything is going. These projects are just insanely complex. Component frameworks may be easier to develop with, but they add so much damn bloat and crazy amounts of tooling. I get frustrated enough with Jekyll and that's just a static content generator. I really miss the simplicity of plain old jQuery and some backend.

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.
ggregoire 7y ago
You probably never maintained a codebase with 10k+ lines of jQuery.
- Aeolun 7y ago
  That might have been horrible and confusing, but it never felt like magic to me.
  - kvz 7y ago
    I realize magic can be bad, but would you really prefer horrible and confusing over it?
    - Aeolun 7y ago
      I would. Magic implies that I do not understand it. If something goes wrong with magic you are fucked.
robertoandred 7y ago
Trying to do anything more complex than a slider was a PITA with jQuery. Managing states, managing templates, trying to keep everything in sync, etc.
ng12 7y ago
Maybe you do but I don't. I spent a week learning Webpack four years ago and it's been paying dividends ever since. 99% of my job is building features, <1% is fuddling with tooling and configuration. If the hard part of your project is setting it up the tools you've picked are too complex for the problem you're trying to solve.
- microcolonel 7y ago
  Of all the bundlers and build systems, Webpack has been the most productive for me by far. We had a heck of a time with a couple of bundlers we were trying out a few months ago, and when we switched to Webpack, all of the things we struggled with on the previous bundlers came together seamlessly in less than half an hour.
- pdimitar 7y ago
  > If the hard part of your project is setting it up the tools you've picked are too complex for the problem you're trying to solve. Sure, but what tooling choice do we have? Webpack is pretty much a standard and is expected almost everywhere, with rollup and parcel used here and there.
  - ng12 7y ago
    Your choice is to not build an SPA. There's nothing wrong with HTML, jQuery, and Bootstrap. I'm fairly convinced most JavaScript fatigue is the result of trying to build very simple web pages with tools designed for 10k+ LoC SPAs.
    - pdimitar 7y ago
      Part of the time you're right. But I do like to dabble with JS again -- after being backender only for years -- and I want to future-proof my work (if at all possible in the JS land). And I throw my hands in the air every time. Stuff like React or Vue generators seem to work fine but then I am left confused what do all the files do and why don't I have a stricter control over what gets pulled inside the project.
JMTQp8lwXL 7y ago
Unpopular opinion: It isn't that bad. If you understand the purpose of a bundler and you understand the purpose of a transpiler, it's not difficult to understand how to put two and two together. You, for example, write ES6, you use babel to transpile to ES5, and webpack collapses all the require(...) calls into a smaller set of files (maybe even a single file, depending on your configuration). It's all well documented, so if you need further details, there's nothing magic about these tools. If you really don't want to be bothered with it, just use create react app, vue cli, or angular cli. Some people aren't that interested tooling, I get it.
- JoshTriplett 7y ago
  > write ES6, you use babel to transpile to ES5 If you have the luxury to only care about modern browsers, do you need to bother transpiling? Every modern browser supports ES6 natively. > and webpack collapses all the require(...) calls into a smaller set of files Also less of an issue if you're using http/2 or http/3. Is there a "preview of the future" framework out there that people can use if they want to see what a world looks like that doesn't have to work around old browsers?
  - JMTQp8lwXL 7y ago
    There are people making applications with requirements where we have to support the legacy browsers, unfortunately. That's how Enterprise goes (but even large consumer-facing apps have the same requirements too, I would be shocked if Facebook "didn't work" on IE 11 today). In my particular case, my infrastructure team will not, and has no plans on, enabling HTTP/2 in our upstream servers. The joy of application development at scale. You can't get everything you want, unless you control it all. Things are too distributed for me to practically sell the team on HTTP/2.
    - Aeolun 7y ago
      Hire an expensive consultant to tell them what they need to hear. I’m sure if they pay $100k for the privilege of hearing they need HTTP/2 they’ll be more receptive to the need.
nahfamwegood 7y ago
Damn, you're right. I can't believe React took over and the jQuery project was shut down and barred from the web. Oh wait. That didn't happen. What is preventing you from using only jQuery and "some" backend? That's right. Just you.
- jamil7 7y ago
  You're making the assumption everyone has the luxury of picking their stack or throwing away and rewriting their whole product. That isn't the case for a lot of developers.
  - nahfamwegood 7y ago
    What is preventing you from making that choice?
keyle 7y ago
You can however build extremely large applications in Vue/React without much of a sweat. Try without them with jquery only and you'll hit some walls. You'd basically ending up by rolling your own stuff with something vaguely similar. Sure you can do static pages all day, but the whole idea is maintaining state and stateful transitions.
ljm 7y ago
I find myself agreeing in some ways. I had my hey-day on the frontend, enjoying all the new things being built for JS devs. Not just the big libraries like React or Vue, but others ones like Rx, Ramda, Lodash, and every other novel abstraction you can imagine. There's some really cool tech there but as a whole it's immature as hell. My satisfaction as a software dev has increased massively since I've renewed my focus on the backend, and also spent some time with Java and other mature languages. We still get things badly wrong but at least it's wrong in a way I can understand. I've looked at some new frontend projects and I would have to learn 7 or 8 different abstractions, inside a monorepo, just to understand how to build a simple interface to a collection of APIs. Fuck that. The churn is too high and you might wonder how people built GUIs at all when you look at a modern web-app codebase.
cryptica 7y ago
>> I've touched some vue.js too, but I just hate the direction everything is going. I've had the exact same thoughts. For a long time, I was a big VueJS fan because of its simplicity and I could build really nice clean and fast apps without a bundler. When your app has few dependencies, bundling is overkill. For some personal projects, I didn't even bundle for production; still, it loaded faster and the user experience felt smoother than the vast majority of web applications that we have today. Now I can see VueJS is moving towards TypeScript and forced bundling. It's beyond frustrating. It's refreshing to read comments like above because so few people are experienced enough to see it as a problem. There was a period in front end development a bit less than a decade ago when it felt like things where always getting better every year; bundlers were only used for production for some projects and HTTP2 was going to allow us to push scripts to the browser so that we wouldn't even need to bundle for production... The future was bright. Then Webpack came along and it became crazy popular, then suddenly people started bundling during development? WTF! Then CoffeeScript came along, added essentially no value at all but people were crazy about it, then transpiling and bundling during development became completely normal. I never thought I'd live to see the day that people would be debugging machine-mangled code. All the work that had been done before since the invention of the computer was about making machine code more readable for humans so this was a shocking reversal of progress. Most younger people think that bundling is normal... Always existing kind of thing. They don't realize that bundling and transpilation is a massive hack that was meant to be temporary and really should never have existed. Very experienced engineers from previous generations invested a lot of time and effort into making fast interpreters for dynamic languages like JavaScript so that people didn't have to wait for code to compile. I remember watching interviews with Google Engineers who worked on V8 thinking to myself how great it was that they were able to get interpreted JavaScript to almost match the performance of compiled languages like Java; that was a huge achievement. Waiting for the code to compile was considered a major problem back then; especially for front end web development. Let's face it, the underlying problems of front end development are trivial, but the ecosystem itself has turned simple problems into highly complex ones. If you've used programming languages like C/C++ where you have to link static and dynamic libraries together, the value of a fast interpreted language is very clear and JavaScript fits the use case quite well. Front end development was never rocket science though it seems to be getting there. Now people added a massive, highly complex and poorly thought out bundling and transpilation layer between the efficient browser engine and their web apps which essentially takes away all the value and efficiency that had been thoughtfully and painstakingly added to all the layers underneath since the dawn of time. Then people start complaining about how bloated and bulky and difficult software development is, but before we can all realize that the answer is to throw out all the unnecessary crap that was added on top, some genius will come along out of nowhere with hot new technology which will add even more crap on top and which gives the illusion of solving the problems that people were complaining about but it will in fact cause new, even worse problems... and the cycle of bloat and disappointment will continue. But at least we will all have more jobs... For a while. I swear if this industry gets any more retarded, they'll be able to replace us with monkeys. Some genius with an MBA will figure out that same productivity with lower costs = higher profits.

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.

ggregoire 7y ago

You probably never maintained a codebase with 10k+ lines of jQuery.

Aeolun 7y ago
That might have been horrible and confusing, but it never felt like magic to me.
- kvz 7y ago
  I realize magic can be bad, but would you really prefer horrible and confusing over it?
  - Aeolun 7y ago
    I would. Magic implies that I do not understand it. If something goes wrong with magic you are fucked.

robertoandred 7y ago

Trying to do anything more complex than a slider was a PITA with jQuery. Managing states, managing templates, trying to keep everything in sync, etc.

ng12 7y ago

Maybe you do but I don't. I spent a week learning Webpack four years ago and it's been paying dividends ever since. 99% of my job is building features, <1% is fuddling with tooling and configuration. If the hard part of your project is setting it up the tools you've picked are too complex for the problem you're trying to solve.

microcolonel 7y ago
Of all the bundlers and build systems, Webpack has been the most productive for me by far. We had a heck of a time with a couple of bundlers we were trying out a few months ago, and when we switched to Webpack, all of the things we struggled with on the previous bundlers came together seamlessly in less than half an hour.
pdimitar 7y ago
> If the hard part of your project is setting it up the tools you've picked are too complex for the problem you're trying to solve. Sure, but what tooling choice do we have? Webpack is pretty much a standard and is expected almost everywhere, with rollup and parcel used here and there.
- ng12 7y ago
  Your choice is to not build an SPA. There's nothing wrong with HTML, jQuery, and Bootstrap. I'm fairly convinced most JavaScript fatigue is the result of trying to build very simple web pages with tools designed for 10k+ LoC SPAs.
  - pdimitar 7y ago
    Part of the time you're right. But I do like to dabble with JS again -- after being backender only for years -- and I want to future-proof my work (if at all possible in the JS land). And I throw my hands in the air every time. Stuff like React or Vue generators seem to work fine but then I am left confused what do all the files do and why don't I have a stricter control over what gets pulled inside the project.

JMTQp8lwXL 7y ago

Unpopular opinion: It isn't that bad. If you understand the purpose of a bundler and you understand the purpose of a transpiler, it's not difficult to understand how to put two and two together. You, for example, write ES6, you use babel to transpile to ES5, and webpack collapses all the require(...) calls into a smaller set of files (maybe even a single file, depending on your configuration). It's all well documented, so if you need further details, there's nothing magic about these tools. If you really don't want to be bothered with it, just use create react app, vue cli, or angular cli. Some people aren't that interested tooling, I get it.

JoshTriplett 7y ago
> write ES6, you use babel to transpile to ES5 If you have the luxury to only care about modern browsers, do you need to bother transpiling? Every modern browser supports ES6 natively. > and webpack collapses all the require(...) calls into a smaller set of files Also less of an issue if you're using http/2 or http/3. Is there a "preview of the future" framework out there that people can use if they want to see what a world looks like that doesn't have to work around old browsers?
- JMTQp8lwXL 7y ago
  There are people making applications with requirements where we have to support the legacy browsers, unfortunately. That's how Enterprise goes (but even large consumer-facing apps have the same requirements too, I would be shocked if Facebook "didn't work" on IE 11 today). In my particular case, my infrastructure team will not, and has no plans on, enabling HTTP/2 in our upstream servers. The joy of application development at scale. You can't get everything you want, unless you control it all. Things are too distributed for me to practically sell the team on HTTP/2.
  - Aeolun 7y ago
    Hire an expensive consultant to tell them what they need to hear. I’m sure if they pay $100k for the privilege of hearing they need HTTP/2 they’ll be more receptive to the need.

nahfamwegood 7y ago

Damn, you're right. I can't believe React took over and the jQuery project was shut down and barred from the web. Oh wait. That didn't happen. What is preventing you from using only jQuery and "some" backend? That's right. Just you.

jamil7 7y ago
You're making the assumption everyone has the luxury of picking their stack or throwing away and rewriting their whole product. That isn't the case for a lot of developers.
- nahfamwegood 7y ago
  What is preventing you from making that choice?

keyle 7y ago

You can however build extremely large applications in Vue/React without much of a sweat. Try without them with jquery only and you'll hit some walls. You'd basically ending up by rolling your own stuff with something vaguely similar. Sure you can do static pages all day, but the whole idea is maintaining state and stateful transitions.

ljm 7y ago

I find myself agreeing in some ways. I had my hey-day on the frontend, enjoying all the new things being built for JS devs. Not just the big libraries like React or Vue, but others ones like Rx, Ramda, Lodash, and every other novel abstraction you can imagine. There's some really cool tech there but as a whole it's immature as hell. My satisfaction as a software dev has increased massively since I've renewed my focus on the backend, and also spent some time with Java and other mature languages. We still get things badly wrong but at least it's wrong in a way I can understand. I've looked at some new frontend projects and I would have to learn 7 or 8 different abstractions, inside a monorepo, just to understand how to build a simple interface to a collection of APIs. Fuck that. The churn is too high and you might wonder how people built GUIs at all when you look at a modern web-app codebase.

cryptica 7y ago

>> I've touched some vue.js too, but I just hate the direction everything is going. I've had the exact same thoughts. For a long time, I was a big VueJS fan because of its simplicity and I could build really nice clean and fast apps without a bundler. When your app has few dependencies, bundling is overkill. For some personal projects, I didn't even bundle for production; still, it loaded faster and the user experience felt smoother than the vast majority of web applications that we have today. Now I can see VueJS is moving towards TypeScript and forced bundling. It's beyond frustrating. It's refreshing to read comments like above because so few people are experienced enough to see it as a problem. There was a period in front end development a bit less than a decade ago when it felt like things where always getting better every year; bundlers were only used for production for some projects and HTTP2 was going to allow us to push scripts to the browser so that we wouldn't even need to bundle for production... The future was bright. Then Webpack came along and it became crazy popular, then suddenly people started bundling during development? WTF! Then CoffeeScript came along, added essentially no value at all but people were crazy about it, then transpiling and bundling during development became completely normal. I never thought I'd live to see the day that people would be debugging machine-mangled code. All the work that had been done before since the invention of the computer was about making machine code more readable for humans so this was a shocking reversal of progress. Most younger people think that bundling is normal... Always existing kind of thing. They don't realize that bundling and transpilation is a massive hack that was meant to be temporary and really should never have existed. Very experienced engineers from previous generations invested a lot of time and effort into making fast interpreters for dynamic languages like JavaScript so that people didn't have to wait for code to compile. I remember watching interviews with Google Engineers who worked on V8 thinking to myself how great it was that they were able to get interpreted JavaScript to almost match the performance of compiled languages like Java; that was a huge achievement. Waiting for the code to compile was considered a major problem back then; especially for front end web development. Let's face it, the underlying problems of front end development are trivial, but the ecosystem itself has turned simple problems into highly complex ones. If you've used programming languages like C/C++ where you have to link static and dynamic libraries together, the value of a fast interpreted language is very clear and JavaScript fits the use case quite well. Front end development was never rocket science though it seems to be getting there. Now people added a massive, highly complex and poorly thought out bundling and transpilation layer between the efficient browser engine and their web apps which essentially takes away all the value and efficiency that had been thoughtfully and painstakingly added to all the layers underneath since the dawn of time. Then people start complaining about how bloated and bulky and difficult software development is, but before we can all realize that the answer is to throw out all the unnecessary crap that was added on top, some genius will come along out of nowhere with hot new technology which will add even more crap on top and which gives the illusion of solving the problems that people were complaining about but it will in fact cause new, even worse problems... and the cycle of bloat and disappointment will continue. But at least we will all have more jobs... For a while. I swear if this industry gets any more retarded, they'll be able to replace us with monkeys. Some genius with an MBA will figure out that same productivity with lower costs = higher profits.