4 ms·

>>I hope the author is right and the next generation of tools does away with a lot of the current complexity (especially the build step! - please no more need f

>>I hope the author is right and the next generation of tools does away with a lot of the current complexity (especially the build step! - please no more need for cli, node.js, a "toolchain", etc.) If that's what you want, then it's not a function of a new framework to enable the vision you articulated. I think evolutions in the HTTP protocol is needed to allow unbuilt/unbundled code to be effectively delivered over the wire. There is a clear distinction between how developers need to abstract and organize code vs how code is more efficiently processed by programs. The framework that the developer uses will always be designed to cater to what the user needs. If there is the need for a build/bundling step, then so be it. Framework designer should never sacrifice the former for an easier build/bundling step

stefano 9y ago
What about a web server that does the build step automatically, with no configuration required? Something like webpack-dev-server, but usable both in production and development. To deploy, drop your typescript/html/css files under /srv/www/ and your web server will take care of everything.
- krapp 9y ago
  If you already have html/css files, then "dropping them under /src/www" will already just work - that's how servers have worked since time immemorial, no "build step" required. But compiling isn't what a web server does, and it seems like having the server automatically do what a developer is going to do anyway when they push to production, and likely not very often, isn't a significant gain in efficiency. The point of having a separate build chain for these types is that you're emitting what are meant to be static resources anyway.