Either way, I've been watching that s6 project for a couple years now and am looking forward to when that happens. Is there any progress on that front? I hadn't heard that the replacement might not actually be s6.
Tinc can work on L2, which means works like switch, means it can works like an cable between any nodes.It doesn't need an ip, you can make a bridge. There is no known good replacement for this.
The down side is
- single thread (perf has limits in 10gbe)
- userspace (wg can works in kernel)
- 1.1 is stable enough, but still may crash, be careful
I love using this to solve problems between bespoke network appliances. "Oh they need to be on the same layer 2, no prob *spins up tinc VMs." How can something so wrong feel so right!
There have been musl builds of Bun before but there were a couple subtle bugs regarding thread spawning. I’m also not sure about posix_spawn implementation - would need to read up on that
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.
