>The people who pushed for this have a list of the next sites they are going to get taken down. In particular any place TERFs have discussions.
At this point, expect everything that doesn't agree with their ideology to be taken down or thwarted through their theatrical pressure campaigns on the blue bird app.
You're being downvoted but it's wild how frontend frameworks pop up, take hold, and then quietly disappear with the next iteration of the same thing with different syntactic sugar.
I downvoted it. I did so because, IMO, the comment is superfluous noise seen on every js thread. A tool exists to solve a problem, if you don't understand why it was built or don't like it, that's ok, but the hackneyed complaining about open source software merely existing deserves to be at the bottom of the thread.
I'm not the grandparent poster but I'll ask the question in a non-superflous way:
Is this actually better than Webpack and esbuild/Parcel/Rollup/whatever that came before it? Or is it just another opinionated way of packaging stuff up that's faster because it doesn't support 10% of the feature set the other tools do yet?
Looking at the "Why Vite" page, most of the blurbs are basically saying "Existing tools are slow". Well, I bet those existing tools are probably capable of doing 10x of what Vite can do currently. And how much faster IS Vite when bundling a large project? Nothing on that, only some charts with lines saying that they do it differently. They say 10-100x speedup on "prebundling", but if that part of the build is only a small portion of the overall build it might be negligible. Also, they say it's faster because Go. Well I kind of like the dogfooding of all the build tools for JS being written in JS - why introduce a whole new ecosystem here?
Not trying to be a naysayer here, I'm just asking why mindshare should be devoted to yet another project that looks like reinvention of the wheel and starting the cycle anew again when we could instead contribute mindshare to existing mature projects - the reasoning given on the site doesn't seem to be very compelling.
The reason frontend dev moves "So quickly" is because of new browser developments & capabilities. Esbuild & vite are currently popular because they are one of the first build tools to fully utilize browser ES Modules. This is fundamentally different than what webpack does. Webpack was solving a Pre-ESM problem, "how do we modularize frontend code?" and as such as taken on a lot of bloat to solve this problem which has largely been solved by browser ESM.
> Well I kind of like the dogfooding of all the build tools for JS being written in JS - why introduce a whole new ecosystem here?
You might find this answer helpful, about Rome which is like Vite but in Rust rather than Go [0], crucially:
> This justification -- Rome should be written in JS otherwise Rome users are less likely to contribute -- irresponsibly focuses on a secondary goal of the project, at the cost of the primary goal, which is to be a end-to-end toolchain for one of the most popular languages in the world.
Speed matters. It is not a sideline consideration, it should be one of the main considerations, over and above a tool being in the same language. In fact, many say that rewriting JS tools in non-JS faster languages will be the future [1].
I think it's a fair argument but I guess time will play it out to see if it succeeds. It's a bit of a chicken and egg thing, like with most newer open source projects intended to replace older ones. To take off, you need contributors. If you can't get contributors, it won't take off. The value add needs to be strong enough to attract enough developers to overcome the Rust/Go hurdle. I'd wager more on Go in this regard, for your average developer not having to worry about garbage collection is probably going to be a significant plus.
It is better. Why are so many people determined to dismiss it on the basis that "things are so bad that we shouldn't try anything new"? That's totally backwards. In a situation of many bad alternatives, searching for new alternatives is the solution, not the problem.
Complaining about bad frontend tooling would be more appropriate to do in a thread that's not about a tool that practically solves it.
Instead of complaining about other tools, these people who don't know what Vite is should be curious and asking what it is, or what it has that's new. That is easy to find out.
> Well, I bet those existing tools are probably capable of doing 10x of what Vite can do currently.
I'm not against new tools, we should absolutely embrace innovation. But show me how it's better, don't just make some claims with no evidence and expect me to buy into it.
Js is an ever changing mass of stuff. I feel bad for frontend guys for this reason. Always writing for a language that does not even exist... always changing how you shove it all together.
Even worse as soon as you put a foot down and pick something you are behind.
It is exhausting even to watch much less to be in it.
Yeah it's just wild. I don't ever remember seeing this level of.... sideways.... churn before. Feels like it's been absolute mayhem for close to ten years now.
I thought that for sure, by 2017 or so, we'd have seen a relatively long lived consensus winner like we saw during jQuery's reign.
Instead, it's just been constant roiling.
The roiling is hard to understand because it's not like the other parts of the stack are really mutating that quickly. Backend dev practices/technologies and browser capabilities are not evolving or roiling at anywhere close to this rate. This sort of churn would have made sense during say 1997-2002 when the entire stack was being invented and reinvented and the basic idea of browsers themselves were changing rapidly.
I think it's an obvious truth that too little innovation/choice is bad. I don't think you'll find any arguments there!
Is there a point where too much of it becomes harmful? For close to ten years now, I feel that experienced and inexperienced devs alike have been confused and repulsed by the utter state of constant wheel-reinvention in the frontend space.
(Perhaps to my own detriment, I've focused on backend work because I'm waiting for the front-end situation to stabilize. Which of course may never happen. Maybe "full-stack dev" is something that will wind up in the history bin next to "webmaster")
It’s easier for some to just be prescribed a specific SDK.
This is a little bit insulting. Nobody wants to "be prescribed a specific SDK" - there's a large middle ground between that, and the current situation which has been chaotic for nearly a whole generation.
I think the situation with backend frameworks is sort of what many would like to see. Django, Rails, Express, etc. No shortage of choice and there is innovation. Yet I don't think anybody would call it chaotic. For me that is a happy middle ground.
Javascript UI frameworks last longer the Microsoft UI frameworks. It's not like a newer framework is just replacing an old one because of hype. React/Vue are massive improvements over Angular 1.
To be completely fair, changes occur way too often even when the name doesn't change. I tried to find a nice component library for starting out with Vue after not doing any frontend or JavaScript in years (I kind of quit when JSPM, the package manager, was hot).
It took me about an hour to figure out nothing I tried to set up worked because I had installed Vue 3 and mostly everything else was still on Vue 2.
Reminds me of Angular 2 rewriting their router every 6 weeks - to the point that they just moved on to calling it Angular 3 at release to rid themselves of the information on StackOverflow that was in a constant state of deprecation.
Which web framework has been the frontrunner for 7 years? jQuery?
According to the latest Stack Overflow survey[0], the most popular is React, which hasn't been the top for the last 7 years. And I wouldn't call jQuery the obvious choice before that, as it's been consistently fading in popularity.
NPM download stats paint a more accurate picture. I didn't include jQuery because it's not a framework. (React calls itself a view library, but it's definitely a framework.)
>But in Florida there is a law now saying teachers can’t talk about gay people in school.
If only you weren't misrepresenting the Parental Rights in Education bill[1] you'd have a point. There's no reason why a teacher needs to discuss sex, sexual orientation, gender identity, etc. with kindergartens, be that heterosexual or homosexual. That's a private matter that has no place in a classroom, less so in primary grade levels.
Hi, you’re just incorrect here. Sexual orientation and gender are perfectly appropriate subjects for young children, and have been part of elementary curricula across the nation for decades.
This is one reason why the Florida bill was opposed by pediatricians, child psychologists, and teachers. The professionals whose job it is know how children develop are aligned against the bill because it goes against quite a lot of research about to help children develop emotionally.
Orientation and gender are attributes that children naturally observe in others and in themselves, even at a young age, and ask their teachers about. Denying them answers helps them not at all, but is useful for stigmatizing the subjects (which is of course the point of the bill).
I noticed you also mentioned “sex” as well, but that is a red herring because no school system in Florida, or anywhere in the U.S. actually, starts sex education before middle school.
> There's no reason why a teacher needs to discuss sex, sexual orientation, gender identity, etc. with kindergartens, be that heterosexual or homosexual.
How do you explain the use of English personal pronouns without referencing sex or gender identity? I mean, I know the that the right is perfomatively “anti-pronoun”, but unless they've decided to exclude them entirely from education...
The same issue exists with traditional honorifics (Mr./Mrs./Miss/etc.); with those you can probably get away with “it was what it is” for specific individuals as a baseline, but are teachers really expect to defer questions about them till later grades?
(It's also very hard to to discuss anything about families, actual or fictional, without, in fact, talking about sexual orientation, and while the bill is superficially written neutrally, it's very clear that the intent is to resolve all these issues of perfectly common childhood things that would become impossible to discuss if it were enforced as written by simply by ignoring then as long as the orientations and identities at issue are heterosexual and cisgender.)
> That's a private matter that has no place in a classroom
While I agree that kindergartners may be too young to receive sexual education, I disagree that sex, sexual orientation , gender identities have no a place in the classroom. At least starting in Middle School it’s important to educate children on the realities of the world they are going to see that will include all of these things. I can at least point to Health and History as two subjects that these topics will be relevant in.
I wonder if there are actually any classrooms in America where gender identity or sexual orientation aren't discussed. Particularly in grade school. Particularly in a place like Florida.
Edit: actually if you’re up for a serious discussion, you mention gender identity shouldn’t be a topic in primary school. Sometimes I wonder if we have a shared meaning on the terms “gender identity” because I would love to send my kid to a primary school where gender identity isn’t discussed, but the idea is ludicrous, not because of its immorality, but it’s impossibility. gender is one of the most discriminating social institutions we have. Everything about the way our society is organized is designed to socialize Kids into a traditional gender identity, hell months before being born parents throw gender reveal parties to determine if a kid should like pink or blue, so what would this even look like? Same thing with sexual orientation by the way given the prevalence of prince winning over princess stories in childrens media.
I mean let’s be clear here, we are taking about a symbol that’s for the backing of the rights of a group of people. There would be large problems for society as a whole if the pendulum swings the other way.
This pendulum refers to virtue signal-ing. Presumably the rights of these groups does not depend on the current fashion or zeitgeist of signaling support via trite visual updates.
That's why they're down-voting you. That's why they're posturing about not being able to say what they think, because they know what they think won't fly here, yet. Meanwhile, of course, out in the real world, we have right-wing preachers talking about how gay people should be shot, we have half of the political mainstream suddenly accusing LGBT activists of being pedophiles...but we're supposed to believe these guys here that it's just them suddenly being weird and territorial about the icons on their screens
Is there anything more pathetic than pretending that not being able to argue against something and escaping with "this just further proves my point" is an own? Probably not.
You might own the app's code but if the user paid for the app, they're entitled to not wanting their screen to become some billboard to The Current Thing™. Buy a few billboards and airtime if you feel you should shove your political beliefs and opinions down everyone's throat. With this behavior, you're the representation of everything wrong with corporate political activism and the tech industry at large: You're the app's developer, and for some reason you think you know more than the user.
This is beyond comical.