My experience with Vite 3 has been great so far (during the alpha/beta). Any issues I had that came up during the beta were fixed or responded to in less than 12 hours. The momentum behind getting this released was pretty impressive. Patak's coordination and contributions have really pushed things along!
> Has Webpack really been dethroned as the go-to bundler?
At this point yes. I'm sure there are still some things that you will need Webpack for, but in my experience I have yet to find one of those instances. Vite is not just way way way faster than Webpack, it's also way simpler.
Configuring a React project from scratch with Webpack is an undertaking, especially if you're not seasoned with Webpack configurations. Vite on the other hand is super simple to setup, I typically don't even reach for the starters that vite offers because it's just as easy to do an `npm init -y` and then install it manually.
I work for a web dev agency and we have migrated all of our existing projects to Vite, and advised any new projects to not use Webpack unless there is a very specific reason and other solutions have been exhausted.
> Configuring a React project from scratch with Webpack
Why do people do this? I've always used the official way (CRA), and never had any issues with it. If you need to adjust webpack configuration, there are third-party packages that work very well in practice (like craco). Yet reinventing the wheel over and over again seems to be popular.
You're answering a question I didn't ask (see the first quoted line). I'm interested in why would anyone waste their time on what's already been done (namely, re-implementing create-react-app from scratch).
I'm not a huge fan of these "managed" frameworks, especially for a larger app. The reason I set things up from scratch is there is alway a fear that in the future a migration away from <MANAGED_FRAMEWORK> will be required for some reason and the effort will be much greater than if we had set it up custom from the getgo.
Nice! Each time I tried out a new bundler (Parcel comes to mind), we hit issues where their configuration hasn't been sufficient for some niche stuff I learned to expect Webpack to handle. I can't think of any specific examples, but I'm sure you've seen something similar.
Vite has been great in the vanilla and Vue projects I've used it for. I didn't think the speed bump would be as noticeable as it was. I'm really happy to hear it is getting more usage in frameworks like Laravel.
Webpack really messed up IMO -- v5 took a really, really long time to drop because they were making huge changes ostensibly for performance... and then when it came out it actually made performance worse for many projects. I think they've fixed that now, but the damage is done.
I think building js in js is just not fast enough anymore, everyone is moving towards compiled languages for building their apps. The next winner in the space will be something like vite that uses a compiled language under the hood (vite uses esbuild, which is written in Go).
For me using Webpacker with rails was a nightmare in the last two years.
The move to 3->4 was painful as 25% of my projects started to move to 4 and no longer worked with 3. So I was stuck with some legacy packages during a time I was upgrading from Vue 2 -> 3. AFAIK they Rails didn't even get to Webpack 5 in practice by the time I left.
I don't think just building JS is slow, I think the issue is that most of the ecosystem is ready to move on to more "no build" scenarios now that ES modules are supported everywhere that matters [0] [1] (Node 12+). Webpack still doesn't seem to have much of an ESM "native" approach/roadmap. Snowpack had a relatively good ESM "native" approach, but appears finished and points to Vite now. Vite isn't entirely ESM "native" yet, but there's more work there mentioned in these release notes and it definitely appears to be in their roadmap/planning horizon. I'm curiously following Vite, but so far it smells to me more of a webpack too much of the kitchen sink "fork" than not still for the "no build"/"targeted build" world.
I've been experimenting with some stuff using esbuild directly in a "targeted" way that builds only a few things with most stuff just Typescript transpilation only (again). I've almost got a feeling the next winner may just be Typescript+esbuild, but not at all because esbuild is fast or written in Go. It may still be Typescript+rollup, given the hints of what's coming in the next Rollup major. (Typescript is still in JS and getting faster every release, with incremental build support for large projects getting better all the time. Rollup is still in JS and still a decent esbuild competitor.) In a "no build"/"targeted build" world it's not really speed that matters but a minimal, targeted API that's easy to automate as you choose targets to build and it may be the case that the time of the "kitchen sink plus a million plugins" builder is over.
A dev server with hot reloading is the big thing vite adds IMHO, at least for your day to day use. It also adds rollup and a more uniform plugin system for your production builds but really the dev server experience is where vite excels.
No tools like vite will detect changes, rebuild/bundle/transform, and then inject the changed HTML, JS, and CSS into the page you're viewing automatically. They work by injecting a script into the HTML they serve which connects over a websocket or SSE to monitor changes and slurp them up when notified by the dev server.
It's really a magical experience to have your code open in one window, your browser open next to it, and as soon as you hit ctrl-s instantly see the page change. I won't tweak CSS any other way, changing sizes, colors, etc is amazing with hot reload.
> While esbuild is blazing fast and is already a very capable bundler for libraries, some of the important features needed for bundling applications are still work in progress - in particular code-splitting and CSS handling. For the time being, Rollup is more mature and flexible in these regards. That said, we won't rule out the possibility of using esbuild for production build when it stabilizes these features in the future.
Code splitting is supported just fine for ESM bundles[1] (and there is little reason to use other formats nowadays), CSS handling works ok as well. I have been using ESBuild since forever and the only instability that I experienced was around sourcemap generation early on.
Using the same tool for prod building is really a value-add. I'd love to seem them get there. I realize though that there's a fundamental difference in dev mode vs prod bundles. In dev, Vite is emitting 25-50 or so JS scripts. In prod, those will all be built into bundles. I just worry about small inconsistencies between esbuild and Rollup when it comes to things like CSS bundling or TS to JS transpilation.
In my experience, Vite offers a better onboarding process and has a more straightforward configuration format compared to ESBuild. You also get most of rollup's plugin ecosystem and a large amount of community tools made specifically for Vite (Vitest, ViteBook, vite-plugin-pwa, etc...). Also, I might be wrong about this but I don't think ESBuild has HMR, which really speeds up development.
Overall, ESBuild feels like a much lower-level tool than Vite. It's great for smaller projects or projects that require absolute and complete control over their builds, but it takes more time to setup in most cases and often requires writing your own build scripts.
> but it takes more time to setup in most cases and often requires writing your own build scripts.
If I don't write my own build scripts how else am I going to show my coworkers how big brained I am? I need to assert my intellectual superiority somehow...
Vite would make it more automatic. ESBuild is a great tool but it requires manual configuration and a lot of plugins and other tools for stuff Vite does out of the box.
I think of Vite as a bundle of esbuild and other tools glued together nicely into one thing which can manage your entire project.
It would give you the inability to use the same bundler for server-side only code, I believe. I'd say if there's nothing that you really need your set-up is pretty much perfect already. You may want to stick a dedicated filesystem watcher in front of esbuild though, which uses polling.
The landing page of Vite claims "Next Generation Frontend Tooling" but then go on to describe features that already have been existing for a good while (multiple years).
What exactly is the "next generation" part here? The composition? That's also not new, so I think I'm either missing something very obvious, or they need to do a better job explaining how Vite is actually different.
Vite is way faster and takes way less config. We been using it in prod for almost a year now and it's just way better. One of the few new js tools thats actually better and doesn't just exist to get stars on github and pad a resume.
That's a fair assessment. You could argue esbuild which it's built on is 'next generation' in terms of JS tooling, with how it integrates with ESM and HTTP2. But in practice this is basically Webpack 2.0 (not v2, but the evolution of it).
It's the performance. It's basically Webpack but fast (sub-second rather than multi-second compiles). There's a number of projects competing in this area, and it might be a bit early to call a winner, ut it's looking like it's most likely going to be Vite.
While all previous ones, bundled for both dev and prod. This is what makes vite a different generation. And results in massive performance boost for dev "build" And HMR
For dev, vite _doesn't_ bundle, it sends your site basically unmodified (as individual files) to the browser since most browsers are already capable of running anything you're using anyway... so if you change one file, that one file is patched, not the whole bundle that depended on it..
since there's no bundling, the initial start time is nearly instant...
webpack hot reload is NOTHING like this hot reload
What I think they are referring to is the bundler is built with Go/Rust rather than JS (like Webpack). The difference in speed between Webpack and any bundler built in Rust/Go (SWC, Vite, Parcel, etc) is that the latter are like 10X faster, not "this is building faster" but "how the hell did it build this quick". That difference in speed is what I think of when they refer to "next generation".
"Native" support for modules and TypeScript, so during development there is no bundle process needed, which is usually the most time-consuming process.
Vite is a fast, efficient “bundler” for npm modules. You can run a dev environment and package code for complex, modern frameworks like svelte, vue 3, etc. It is not in itself a “framework” like React.
Even Java has two major releases per year these days... they are "mostly" backwards-compatible, but not always as stuff can and is getting removed almost every release.
I just started using Vite earlier this week so I was a bit dismayed to see a major version release right after I got my project configured, but my experience was the same as yours. Bumped the version in package.json and I'm good to go. My experience converting a project from CRA to Vite was really smooth too, it only took about 20 minutes.
Because major dependecy change can break downstream users. Major does not signify that you are delivering big features, it signifies you can break existing apps.
For eg: Consider CRA dependency upgrade from webpack v4 to v5. That change broke a lot of apps due to node not being polyfilled.
If CRA did the change in minor version, then it would have result in breaking changes for many apps and would completely undermine semantic versioning
I agree. It's up to the publisher to decide the significance of version numbers. Just because Node does it one way doesn't mean everyone else has to follow suit.
Because that's the meaning of major version number. Additionally JS/npm modules are supposed to follow semver, and you increment the major version when you break compatibility.
I get it, Linux does its own thing with versions, and so do browsers, so it's hip to just increment major whenever you feel like it apparently.
EDIT: LOL at people downvoting GP because they dared to wonder if the frontend world needs another bundler shipping a non-compatible major version at least once a year. Stockholm Syndrome I guess, who doesn't want to update their configuration and see their plugins break every year?
That's one meaning of major version number. The original meaning is simply a release that is significantly different from the previous one. It's also possible to maintain more than one version number: a marketing version and an internal version (Windows did this famously where Windows 7 is actually version 6.1, Windows 8 is 6.2). Then there's a convention where the major version is the year number and it simply increases on Jan 1st, etc.
I have no knowledge of which convention Vite uses.
In addition to this, I believe it's also kosher to increment a semver major version even without breaking changes. Semver forbids breaking changes without a major version increment, but I don't think it forbids the reverse.
It's not a "marketing thing". The whole version requirement syntax in package.json (i.e. "^1.2.3") and other non-JS package managers really only works if a package follows semver, so that's the reason 99% of JS packages do.
This is why when you npm add a dependency it defaults to the "^1.2.3" syntax, which means the dependency is upgradeable to the next minor version, which, as SemVer states, should be guaranteed to be backwards compatible.
Of course you can just disregard that, make breaking changes whenever you want and annoy your users enormously.
AFAIK Go doesn't follow any kind of versioning scheme (since they don't use a versioned module manager), but the project itself is semver-compliant. No breaking changes are introduced since Go 1.0 was released. The proposals for breaking language changes will be planned for Go 2.0. Generics aren't breaking old code.
There is no reason, unless your name is Linus Torvalds or you're marketing driven such as your browser, not to follow Semver. It's a good and simple idea.
npm itself assumes projects use semver, so it's generally a useful assumption in the JS ecosystem at this point now that npm is the primary package manager for all things JS that JS packages follow semver.
React Context HMR still has problem. Due to this problem, I think nextjs still the better choice for react dev. Maybe vite supports too many frameworks, do not have enough time to handle the react problems.
Vite is framework agnostic. Framework specific work is spearheaded by framework specific community or core authors in some cases (solid, astro)
React falters because there are not many community contributing towards react integration.
Note: Vite team has done their job for react, but react itself has many concerns particularly due to commonjs that a dedicated person (or team) is needed for react
Framework-agnosticism is not an afterthought in Vite, but has been there from the beginning. Svelte has gone all-in with Vite. Go to svelte.dev and the homepage instructs you to create a new project using Vite. We've never run into any problems with things being built for a specific framework in Vite.
It's a JavaScript bundler. If a framework is doing weird stuff with imports, or using legacy module builds, that's on the framework to fix...or not.
Angular is the same way, it has its own compiler and relies on custom build-time code to work. That's also why it isn't picked up by a lot of newer build tools that generally just work with normal JS.
This analogy is plain wrong. The blog post lists multiple non-Vue frameworks/tools using Vite as their default build tool. Compare that to the number of non-JS languages (excluding ones that compile to JS) using NPM as their default package manager (0).
At this point we know that Webpack is dead. Unless there is a new release that rewrites it in Rust or Go and makes it comparable in speed to Vite/SWC which will never happen. The two different approaches seem to be either going with SWC or Vite. I'm honestly not sure which one will prevail, or if they will both co-exist, splitting the previous market share taken up by Webpack.
But, vite is working on to become the next nextjs, like ssr, isg etc. Nextjs only support react, so it's easier to leverage the react's ability to do these.
When there is ssr, there is runtime, more than just a dev/build tool.
It sounds like you might have some misunderstanding. You can write SSR applications with Vite, but each framework or application is responsible for the rendering. There isn't really such a thing as an SSR runtime in Vite. It will run code on the development server in SSR mode, but all it does is make sure it's picking up code updates and passes it through to Node.js.
That issue is disappointing. It's an important issue for making React work, it's been open for over a year, and there isn't any comment from someone who works on vite or the plug-in.
I know that this is all about Vite but if you like Vite, I want to give a shout-out to Parcel[0] as well. Its a very similar philosophy, built on top of SWC[1] and has its own set of great optimizations. I've regularly gotten smaller overall bundle sizes with parcel than with Vite (though that gap is very narrow now) in my experience. I wish Parcel got more mention, especially in the React community (where it shines the most). It really is very very fast and I think has really cool integrations (like file system resolution) out of the box.
Parcel has been praised on here many times when it originally came out. I was an avid user but the nail in the coffin was the horrid and long release of v2 which took forever, the docs were in disarray, and overall just left a bad taste in my mouth. I also think there was some common issue where v1 didn’t support some version of postcss for quite some time and I and many others jumped ship to vite.
One other thing is that is was "zero config". While everyone likes the idea of "zero config", in reality there are some things you will want to configure. It drove me up a wall with Parcel where I wanted to do X but couldn't and had to do Y instead because there was no way to configure parcel to make X work, not that X wouldn't work with Parcel, there's just no way to configure anything and you're at the mercy of "good defaults"
Ironically, Parcel is the only build tool that ever forced me to change my IDE configuration to [get file watchers to work](https://parceljs.org/features/development/#known-issues-with...). If other non-zero-config tools don't require this to be changed, I'd expect a tool focused on zero-config to support this.
Vite on the other hand hasn't had any such suprises so far.
Agree with this strongly. Also, it's great to have a zero-config tool like Parcel, but it needs to have a path from zero-config to "some config" as your project grows. I found this very difficult and jumped to Vite.
This has bitten me so many times. Parcel works flawlessly until it suddenly doesn't and then it's very difficult to do custom things. As someone who reaches for Webpack on most projects, this lack of customizability when you needed it was painful.
I really liked Parcel v1, but v2 completely broke watch for me, which is kind of a dealbreaker these days. I'm currently pretty happy with webpack v5, but definitely have vite on my list to check out.
I really like the defaults Parcel comes with, it is very quick to get started with Parcel.
However, the promise of zero config is made possible in part by "magic" (strange conventions), and by having configuration spread across multiple files (package.json, . parcelrc, custom plugins which for some grave reason you can't use until you publish them to npm)
I really wish Parcel had sane configuration — I want to like it so much, but alas, it falls pray to the pendulum effect.
Not to be unnecessarily dismissive, but installing Parcel makes me a 201MB node_modules folder. That's more dependencies/code than I'm comfortable relying upon.
Vite's really gaining traction, from the chatter I'm seeing. Seems pretty good in my initial trial of it - I'm hoping it spurs other tools to improve performance and dev experience.
Question: Is Vite really a serious tool built for production apps? The design decisions don't give me confidence.
As your app starts to grow, you'd definitely not want 1000s of modules loading in your browser.
Seems like something that gets you from 0-60 quickly, and becomes a pain after.
Similarly, the different choice of bundlers in development and production would well lead to difference in behaviour / hard to catch bugs.
Shopify is using it with React. Lavarel now adopted it. It's the default for Vue projects going forward (given it's made by the person who made Vue).
Plenty of serious support behind it.
Not sure how you'd end up with "1000s of modules in your browser", unless you have some mega-project with an unwieldy package.json. I have a pretty complex Vue project app and it loads <100 .js files async and the vast majority are 100b and 95% will cache on the first load and never change. It's really not that big of a deal for modern browsers to load lots of tiny js files from your local machine in development.
I've found it to be way faster than Webpack for dev build times which is all that really matters to me.
Yes. Currently using it in production and couldn't be happier.
The individual modules are only served during development, but even then startup/load is faster than our previous webpack setup by an order of magnitude. When you build for production, you still end up with a bundle like you had previously.
It serves unbundled for development and bundled in production. In practice this works pretty well as long as you do decent code splitting (and you should be doing code splitting!)
Edit: lol I should have read your post more closely. Yes, the different strategies can cause bugs; there's much more shared between the two pipelines than there used to be so this situation is improving. We actually had really bad compatibility with problems six months ago and it was still easily worth the trouble for the performance improvement.
I am currently using WebPack to package a multi-page web app. Build times are relatively quick, and when developing I am using a feature that does an incremental rebuild when files are changed and that's quite fast at this point.
This being the case, I am not sure I'd really have a reason to migrate over to Vite on this project.
if build times are quick and you’re not getting tooling issues there is no reason to switch.
the only reason i switched to Vite was that in my experience with Webpack build times were not quick and i got annoying JS bundling issues like syntax errors (!). That’s really the main difference I saw between the 2. But it was a while ago and maybe webpack has gotten better again, in which case they’re both very similar.
Don't switch if its pleasent to work with already. Vite is very nice, but it lets your browser load each module individually in dev mode (not like webpack, that creates chunks that combine lots of modules), so if you have a big project, you may end up with pages where your browser has to resolve and load 100 modules, which may be slower then webpack serving you 3 chunks.
I'm in that same situation in an MPA Fastify + Svelte project. Honestly, it takes more time for the app to reconnect to the DB than for Webpack to do an incremental rebuild.
I've been considering switching to Vite because it should make the SSR + hydration config much simpler and I would get HMR (hot module reloading) which will probably speed my iteration times if it works as expected.
The funny thing is that I hate changing tech at the backend, but still love many of the innovations at the frontend.
I know, it still seems crazy what's happening at the frontend ... but Vite brings substantial advantages compared to the old standard. Same thing with the next-gen frameworks like Svelte, SolidJS or Vue 3 (composition API) that are substantially better than the old ones (mainly regarding DX). Another welcoming example are the quite new E2E testing frameworks like Cypress or Playwright.
Yep agreed. For me it's welcome because this latest generation of churn feels like it has leveled up DX considerably. The churn in between Backbone up until ~ Angular 1 brought a lot less value in my experience at least.
Thanks, that solved it, but now I have other errors like needing to install sass etc. V2 seemed much better now, it just worked, now I have to go installing everything and the kitchen sink.
> Vite is powering a renewed innovation race in Web frameworks.
Wait what, again? 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...
The description is maybe a little misleading. Vite is a development experience improvement for existing frontend frameworks; most people using it are on React or Vue (which is the other of the "big 3" along with React and Angular). It's about making projects build and start faster.
For clarification, isn't it true that you can only use Vite with Vue and React, and not Angular. Angular is too tied to WebPack (At least not today) I am not entirely sure, so I wanted to ask.
Vite is framework agnostic. But angular being too big and too monolith requires large change to move from webpack to vite.
Some folks have attempted it, but not completed vite support.
This is nothing new in angular land. There are multiple third party libraries and framework which support react, vue, svelte and even solid, but not angular.
>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.
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.
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."
>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.
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.
HMR is nice, but the added complexity seems to make basic stuff like sourcemaps support difficult. Would be nice to have something that adds HMR with the flexibility of a custom build stack(esbuild + a better livereload)
I feel all these snarky comments about complexity in front-end development is really misplaced in a thread about Vite, a tool that actually tries to fix that.
It just hit me. The web produces bad UI. I saw a demo of Alan Kay showing a smalltalk environment from the 70s. Wow, we haven't even caught up to that yet.
Yep, web UI work is generally worse (more effort for worse results) than other application UI work. Styling is nicer than on most other platforms but with any decent UI toolkit you shouldn't be doing much styling anyway.
The Web's main problem is that to the extent that it has a UI toolkit, it's god-awful. We should have spent all this time since it became clear "web apps" aren't going away strengthening HTML, and especially the various form elements (better tables and some kind of list view like other platforms have would be great, too).
Instead it's largely stuck in place, and we hack in poor-performing custom half-broken elements that are different on every site, wasting absolutely incredible amounts of both developer and user time. Truly, the time-cost to humanity of web UI's inadequacy is huge.
I can't keep up with this stuff anymore. As a former "full stack" dev, I just quit the frontend part altogether and I'm now just focusing on the backend. It's just too much and changing too fast.
Our frontend is mostly class-based react components compiled with webpack 4 and babel 6 (for context: those are old versions). and guess what? it all just works. new 3rd party components also just work. adding modern hooks-based functional components just works. and everything that worked 5 years ago still just works. I think the JS our tooling emits is backward compatible with IE9 and up, which is ridiculous and wasteful and also no problem at all.
just don't upgrade random tooling all the time and you're good. most widely used JS stuff has an excellent backward compat story. (react itself is amazing in this regard IMO)
a corollary to this is that if you feel fatigued by having to constantly learn and upgrade your tooling, maybe you're just having regular old analysis paralysis and you're blaming the tooling for no good reason. just use the tools you already know and get going! you can build fantastic, modern-feeling software using only tools and knowledge from a decade ago.
That's fine, but what do you do when your applicants back out of the hiring process when you tell them you use React 15? I guess all we can do is upgrade, specifically for this reason.
We tell them that they're free to do something about it. It's not uncommon for our newest hires to find some itch that was better in a previous job and make our setup better accordingly. They'll soon find that there's much more exciting stuff to work on but it's a good first or second task.
Note that we're on React 17 now - 15 to 16 was hard but 17 was largely backward compatible. I expect 18 will be worth it too, the breakage is tiny. Like I said, React's backward compat story is real nice IMO :-) (and so is the tooling to help you address breaking changes)
Note, it was different ~5 years ago. When we wanted to upgrade from react 15 to 16 for better runtime speed, we had to upgrade babel first and that required a webpack upgrade iirc. It was a mess. But the ecosystem has matured a lot since then and we haven't done major setup changes since. It just works.
If you care a little bit about those critical / major security vulnerability alerts, and are working with NPM professionally, I shouldn't need to answer the question. If you are not, it's because NPM moves very fast, you can lock in your dependencies but soon enough they'll start signaling vulnerabilities.
We check out all these reports but in 99% of the cases it's something like "if you pipe user data into to this command line tool, then it's hackable!!" and said tool only gets used by our build toolchain and not by runtime code, so no user code ever gets piped there. We've not yet run into a must-upgrade dependabot vuln that was also non-trivial to upgrade to because of the infamous (but, to our experience, untrue) NPM dependency hell story.
Can't keep up with what? There's a few Javascript frameworks, and React is the lion's share of job postings. There's a few build tools but most everyone uses Webpack. The unit testing tools work on frontend and backend, and mostly seem to center around Mocha or Jest.
There was a short lived explosion of frontend frameworks that grognards drag up like it's a relevant problem, but serving up HTML from a server side route has always been an option.
I agree that frontend stuff moves too fast in general, but Vite specifically is a good change. Frontend build systems are a mess (and often slow) so I welcome tools that improve the situation
Hear, hear. I'd been away from the scene and recently returned, backend historically was the greater challenge for me since I thought I had an eye for design and could whip up basic things using the more fundamental building blocks. I come back, and I can't tell one thing from the other. SPA, or server-side rendering? Will SPA get me dinged because crawlers can't deal with them? I don't know, I get a different answer from every next person!
Angular and Vue were the thing last I was paying attention. Now React is the thing. But not so fast, there's Next.js.
I think I've had enough, I will supplement my Django backend templates with handwritten CSS.
You can check out htmxhtmx and alpinejs, those complement django quite nicely and you dont have to go down the javascript rabithole to get some dynamicism.
I went with Nextjs with all its bells and whistles and expressjs (99% of cases is enough). Now I'm currently moving to MLE projects at work.
I only pay attention to new tech only if here's a huge demand (ie. Plenty of Jobs and good $$$). Only then I start learning it.
Nextjs/React won the frontend battle (atm). It's almost impossible to keep up + being specialist. Heck, it's equally difficult to be a generalist with new things coming up every 3/6 months.
I was just telling my friend yesterday that after a decade of full stack I just don't feel that I can do it anymore. Serverless, bundlers, frameworks, CI / CDs, virtual doms, non-virtual doms, semi-virtual doms, JSON responses, HTML responses, SSR, UI / UX... on and on and on. I have to go through documentation for at least 3 of these things and mush my brain until product decides that that feature is not worthwhile because it can't be done in 2 weeks.
I really do believe this is getting better -- though not at a rate where it's obvious yet if you aren't plugged in.
A few years ago there were tons of frameworks and they all worked a bit differently. New shit every week. IMO that's because no one had really figured out the right paradigm yet. Now we have (it's components) and the framework race has slowed way down (it's pretty much React, Vue, and Angular now). Even big changes in React like Hooks didn't break backwards compatibility. You can move pretty slow and steady on that front, if you want to.
Tooling is the next frontier. It's become obvious that compiling js in js itself is just not performant enough for large applications. We need a faster solution. There are a few contenders right now (esbuild, swc, bun; vite wraps esbuild) but I suspect within two years we'll have a pretty clear winner.
In general I think things move faster when we haven't found the right ideas yet, and that's why backend is more stable -- it's just older. There has been more time to iterate and figure out what works and what doesn't. Frontend will probably always be more chaotic than backend, but I think it'll be much less so as we start to agree on the web want it to look like.
It's too much of the same stuff. Similar frameworks, similar tooling. And they all suck.
I think it has to do with frontend means designers/ux, and those people tend to like being in the spotlight and grab fame. Therefore it's logical that they just create / fork something instead of contributing to an existing project.
This results in buggy projects because they try to do everything, and unmaintained after a while.
Usually they're also less thought out than with backend projects.
Well, I'm employed as a software architect and we're currently using Spring and Symfony. Very different languages and very similar frameworks. In my free time I play around with Go and some NextJS stuff.
1) If it didn't break backwards compat why did it bump the major version?
2) Constantly pushing major versions in order to ignore backwards compatibility and pass that problem on to consumers might not break semver but you're still wasting my time by expecting me to clean up your mess if I choose to depend on your library. (Which I won't)
Or are you suggesting vite will backport security patches indefinitely?
Re 2.: unless they plan to simultaneously support multiple major versions, they kind of do. Maybe not right away, but once the main branch of development is based on the new major version, that's the highest priority moving forward. All older versions might get backported bug fixes, but that's it.
I'm not bad mouthing anyone. I wasn't even specifically targeting vite. I just simply don't care for the people in the industry that think they have ownership over my time. If they want me to use their shit, they need to make it worth while.
The speed at which you release breaking change is the speed in which I run in the opposite direction.
Look at all the arguments in this thread "you don't have to" "its optional" "its just a small change" "it hardly even needed fixing".
Do they not realise that me even having to look at this cost me time and money? Do they not realise that when you multiply that out to all your devs at their day jobs and then multiply it across the entire stack of software all pulling these stupid stunts that it adds up to a huge waste of time for everyone involved except the snowflake that thought their breaking change was worth it?
Breaking changes (https://vitejs.dev/guide/migration.html) are minimal and unlikely to affect most applications, and when they do the issues should be trivial to fix.
It doesn't mean that anything will break. You deprecate old ways long before you remove them from your tool so that by the time you do the breaking change only a tiny slither of people are affected by it.
because maintaining backwards compatibillity is an antipattern, its producing so much needless global complexity in our tools for everyone forever, just to save some effort when upgrading ...
Could you please stop posting unsubstantive/flamebait comments and breaking the site guidelines? I don't want to ban you again, but if you keep doing these things, we'll end up having to.
