2 ms·

>I thought we all silently agreed to use the mature/legacy frameworks React and Angular until the proper WASM arrives so that we could burn all of JS/CSS/HTML..

>I thought we all silently agreed to use the mature/legacy frameworks React and Angular until the proper WASM arrives so that we could burn all of JS/CSS/HTML... We did. But people without real problems to solve will continue reinventing the wheel, while we silently churn away on actual products with stable tooling.

SahAssar 4y ago
As someone who has worked in a lot of frontend (Vue, react, various microframeworks) I would heavily disagree that the tooling is "stable". It's incredibly fickle and breaks in ways that are hard to debug. Microframeworks are slightly better, especially if they support no-build setups since then a "build step" for prod is only bundling and minification.
- deleted 4y ago
  [deleted]
cercatrova 4y ago
This comment and the parent's tells me that neither of you know what vite does or have used it before, if you're implying that it's not fixing "real problems." Webpack is slow due to being written in JS, so when a bundler comes along written in Go and makes builds 10x faster, that is solving a "real problem."
- francisofascii 4y ago
  > Webpack is slow So it sounds like Webpack was never really mature, or too late in getting ported to Go before Vite took over?
  - cercatrova 4y ago
    The latter mainly. The biggest reason is that JS is too slow compared to other languages, especially compiled ones like Go or Rust. So writing developer tools in JS already made them slow.
- ramesh31 4y ago
  >Webpack is slow due to being written in JS, so when a bundler comes along written in Go and makes builds 10x faster, that is solving a "real problem." I've worked on projects with hundreds of thousands of LOC compiling with Webpack. Build time has literally never been a concern for me. The entire point of tooling like Webpack is that it's written in JS because dealing with interop between native binaries is an absolute nightmare. It's a feature, not a bug. The same reason we moved to JS based SASS/PostCSS compilers.

SahAssar 4y ago

As someone who has worked in a lot of frontend (Vue, react, various microframeworks) I would heavily disagree that the tooling is "stable". It's incredibly fickle and breaks in ways that are hard to debug. Microframeworks are slightly better, especially if they support no-build setups since then a "build step" for prod is only bundling and minification.

deleted 4y ago
[deleted]

cercatrova 4y ago

This comment and the parent's tells me that neither of you know what vite does or have used it before, if you're implying that it's not fixing "real problems." Webpack is slow due to being written in JS, so when a bundler comes along written in Go and makes builds 10x faster, that is solving a "real problem."

francisofascii 4y ago
> Webpack is slow So it sounds like Webpack was never really mature, or too late in getting ported to Go before Vite took over?
- cercatrova 4y ago
  The latter mainly. The biggest reason is that JS is too slow compared to other languages, especially compiled ones like Go or Rust. So writing developer tools in JS already made them slow.
ramesh31 4y ago
>Webpack is slow due to being written in JS, so when a bundler comes along written in Go and makes builds 10x faster, that is solving a "real problem." I've worked on projects with hundreds of thousands of LOC compiling with Webpack. Build time has literally never been a concern for me. The entire point of tooling like Webpack is that it's written in JS because dealing with interop between native binaries is an absolute nightmare. It's a feature, not a bug. The same reason we moved to JS based SASS/PostCSS compilers.