Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why we switched from Webpack to Vite

blog.replit.com

Post reply on HN
Print view View original

211–220 of 229 posts

Re: Why we switched from Webpack to Vite

#211

Post by root_axis »

Daishiman wrote: post #167
root_axis wrote: post #95

Earlier quoted context omitted.

> A counter point would be to look at the Python ecosystem. They have many fewer libraries but the ones they have are very well maintained and widely adopted. So what? It is what it is - the python ecosystem faces completely different challenges than the JS ecosystem, if the browsers exclusively ran Python instead of JS it would be the exact same situation for Python. > JS/Node is full of unmaintained projects that p…

It isn't contrariarism. The end result is that most JS libraries are immature, have complex edge cases that can only be fulfilled by one package but not from another similar package, and that old packages don't evolve to adapt to new paradigms. Knowing that pretty much every Python dev knows how to use requests, Django, and NumPy means saving a huge amount of effort in retraining and fighting to pick and choose on ch…

It is contrarianism, there are many mature JS libraries, the fact that less mature packages also exist isn't a problem, just don't use them.

> Knowing that pretty much every Python dev knows how to use requests, Django, and NumPy

This isn't true, but even if I grant this to be true, you could just as accurately say pretty much every js dev knows node, axios and react.

Re: Why we switched from Webpack to Vite

#212

Post by Daishiman »

root_axis wrote: post #211
Daishiman wrote: post #167

Earlier quoted context omitted.

It isn't contrariarism. The end result is that most JS libraries are immature, have complex edge cases that can only be fulfilled by one package but not from another similar package, and that old packages don't evolve to adapt to new paradigms. Knowing that pretty much every Python dev knows how to use requests, Django, and NumPy means saving a huge amount of effort in retraining and fighting to pick and choose on ch…

It is contrarianism, there are many mature JS libraries, the fact that less mature packages also exist isn't a problem, just don't use them. > Knowing that pretty much every Python dev knows how to use requests, Django, and NumPy This isn't true, but even if I grant this to be true, you could just as accurately say pretty much every js dev knows node, axios and react.

AFAIK Axios isn't even universally used for requests, and in the SPA framework space it seems to be a split between Angular and React in popularity. None of these things seem to be occurring in the Python space.

Re: Why we switched from Webpack to Vite

#213

Post by ibejoeb »

Vite is really fantastic, but I've had trouble migrating projects with vendored libraries that use JSX inside .js files. There's kind of a hard requirement that JSX lives inside a .jsx, .tsx, or .ts file.

If anyone has come up with a workaround, I'd love to here about it.

Re: Why we switched from Webpack to Vite

#214

Post by rk06 »

AbuAssar wrote: post #150

I wish Angular could benefit from this new breed of tooling

Vite is frameowrk agnostic, so theoretically, angular can also benefit from it.

The roadblock lies in angular cli. angular cli is webapck based, and angular team will have to dedicate resources for the migration to vite.

Given the situation, i would say, using esbuild with webapck would be more cost effective

Re: Why we switched from Webpack to Vite

#215

Post by panzerklein »

viklove wrote: post #179
jeswin wrote: post #176

Earlier quoted context omitted.

This is excellent advice. There's something I really dislike about import "./style.css" into JS files - it just seems meaningless especially if you've worked with other languages/ecosystems. A great many tutorials default to this style, so it'll likely live on for a while. As yet another tiny UI framework creator (forgojs.org), the switch to esbuild-loader was our best developer experience decision. create-forgo-app…

One great problem it solves is namespacing all of your styles. I don't have to worry about classname collisions because the bundle handles it all for me. Instead of having one massive global stylesheet, I have a bunch of small, modular stylesheets that fit entirely on my display without scrolling, and I can reason about the output much easier than before.

You're talking about css modules. It's a different feature.

Re: Why we switched from Webpack to Vite

#216

Post by rk06 »

edem wrote: post #196

Why do we need yet another tool? Why can't we just improve the ones we already have?

because

1. ES modules support has increased to all major evergreen browsers.

2. Esbuild has come out which shows faster results than tools (babel, typescript)

3. Improving current ones means supporting hacks and incorrect code patterns, which is not wanted.

The above factors has resulted in multiple build tools with vite being one of them

Re: Why we switched from Webpack to Vite

#217

Post by root_axis »

Daishiman wrote: post #212
root_axis wrote: post #211

Earlier quoted context omitted.

It is contrarianism, there are many mature JS libraries, the fact that less mature packages also exist isn't a problem, just don't use them. > Knowing that pretty much every Python dev knows how to use requests, Django, and NumPy This isn't true, but even if I grant this to be true, you could just as accurately say pretty much every js dev knows node, axios and react.

AFAIK Axios isn't even universally used for requests, and in the SPA framework space it seems to be a split between Angular and React in popularity. None of these things seem to be occurring in the Python space.

Nothing is universal, you're seeing what you want to see. I could say the same thing about django, flask, and web2py or numpy and panda, or trio and asyncio.

Re: Why we switched from Webpack to Vite

#218

Post by Daishiman »

root_axis wrote: post #217
Daishiman wrote: post #212

Earlier quoted context omitted.

AFAIK Axios isn't even universally used for requests, and in the SPA framework space it seems to be a split between Angular and React in popularity. None of these things seem to be occurring in the Python space.

Nothing is universal, you're seeing what you want to see. I could say the same thing about django, flask, and web2py or numpy and panda, or trio and asyncio.

Django doesn't occupy the same space as flask; not in the same way React and Vue seem to. Web2py is nonexistent. Numpy is a basic linear algebra library and Pandas is a high-level tabular data analysis library.

None of these things compete with each other in any meaningful way.

Re: Why we switched from Webpack to Vite

#219

Post by IggleSniggle »

lhorie wrote: post #208
IggleSniggle wrote: post #185

Earlier quoted context omitted.

The 2-bit part applies, if not the rest, and it’s not really “on disk” but rather “memory for data type,” right? Given the nature of the questions, I presumed they were interested in knowing “how does JavaScript load strings into memory, anyway?” And to answer that question, your rough heuristic should be “2 bytes per character” not 1, even for ascii range. That just leads to additional questions, though, because of…

The thread was originally about CRA vs Vite size on disk (or implicitly, if we're applying it to real world applications, network cost in CI job startup times). And like I said, surrogate pairs don't apply to ASCII. See this[0] for reference. Note how the first byte must fall within a certain range in order to signal being a surrogate pair. This range quite deliberately falls outside the ASCII range. This fact is tak…

All great points. Not trying to nitpick, just trying to satisfy curiosity.

Re: Why we switched from Webpack to Vite

#220

Post by Shorel »

jupp0r wrote: post #200
Shorel wrote: post #178

Earlier quoted context omitted.

I have used CMake. I added the dependency by writing about three CMake lines. And after that, it just works, for years. I may have to add from 2, to 5 dependencies for a project, instead of the myriad of dependencies in JS. And they don't become obsolete and need an update each week. It's a difference of some orders of magnitude, both in number and in upgrade frequency. This is a huge part of dependency management fo…

CMake only finds the dependencies, how do they get to your computer? Do you link statically or dynamically? What compiler toolchains are these libraries built with, do they use the same standard library as your code or different ones? When you want to cross compile, how do you find libraries for your target architecture? Conan makes much of this easier, but is not really suited for large software projects with the pr…

Well, I don't cross compile. If I need to test a new OS, then I get the VM and compile it there.

About dependencies, if they can be found in the package manager then it goes that way. Else, they are a git submodule.

The most problematic has indeed been the C++ MySQL connector, because it has changed a bit over the last five years, so I had to edit the #include lines in the source code files.

Post reply on HN