Every time I see a new Bun update it's always because Bun has implemented a feature that violates the spec in some way. While this does rely on syntax from a proposal, said proposal has not made it into the language yet. Another failure I see is the fact that the "type" property is not meant to be used for this type of language augmentation, it's meant to describe the type of the file without inferring from the file extension. I think Bun has a habit of moving too fast and breaking things and if it catches on I worry it will have just as many legacy anti-spec things as Node does.
Import Attributes are a stage3 proposal which means it is very likely to become part of the language. It’s the last stage before becoming part of the language.
> Another failure I see is the fact that the "type" property is not meant to be used for this type of language augmentation, it's meant to describe the type of the file without inferring from the file extension
It sounds like you’re confusing Import Attributes with Import Assertions, which was the previous iteration of Import Attributes.
Interpretation of import attributes is host defined. For Import Assertions, that wasn’t true - they were intended never to impact runtime evaluation. That’s the difference with Import Attributes. Import Attributes do impact runtime evaluation.
What I specifically meant is that the "type" property can impact runtime evaluation as per the spec, however it's implied to be used specifically for impacting runtime evaluation based on a file's type. Say I have a module in a language that transpiles to JavaScript based off of the "type" property. In Bun, I would not be able to use any functions exported by it as a macro because the "type" property is being used for defining the module as a macro. That's the specific issue I have.
I think this is mostly consistent in terms of effect. With any application of import attributes that affect the dependency, the dependent module could behave differently for any affected aspect it accesses.
The only inconsistency is that Bun is front loading some of these effects to the server/bundler runtime and effectively memoizing the equivalent behavior before it reaches a client. But it’s not doing that of its own volition, it’s doing it to address an explicit attribute in the source code.
The only way this would be a meaningful problem is if the explicit value has a chance of colliding with either existing code in the ecosystem (highly unlikely, no one is really using this syntax yet except perhaps in an equally experimental context), or some plausible pending standard (unless one was proposed in the last couple weeks, I’m pretty sure I can rule that out too).
I share other commenters’ lament that this is not a true macro solution (and I think it should actually just be renamed to something like comptime). But I don’t think this deserves the deviation-from-standards challenge it’s getting in this thread. And lest I come off as a Bun fanatic, I think I’m one of the people who more frequently questions potential Bun spec deviations when they come up on Twitter.
Eh. Just treat Bun as a testing ground for (very) experimental new features. It's no secret that the project moves very quickly, and anything that gains enough traction can be folded back into the spec.
I like that there's an engine willing to break the spec. It's good to have variety and see how people experiment with this stuff, at least for the fun of it!
Is bun actively participating in these discussions, or are they just implementing whatever they wish and not participating in the chicken-and-egg process?
I'm well aware, but this is not just import attributes. It's using import attributes syntax to trigger a transform of the importing module, in addition to changing the behavior of the exporting module.
More concise than my previous reply: that’s just moving the same outcome around in time. If a fully runtime-only import attribute would result in inlining a static-at-build-time value where its export is called, this is just inlining it sooner. That seems fine to me unless it doesn’t fit the import attribute use case. In which case… don’t voluntarily use it?
Why do I continue to see people imply that React is the only way of writing frontend web applications with JavaScript? There are plenty of alternatives to React that I would say are far more "idiomatic". I highly recommend taking a look at Vue 3 or Svelte to get a better idea of what frontend JavaScript can be.
React isn't the only way, of course, but it's likely the most popular. Why do you consider Vue or Svelte to be valid alternatives but not HTMX, despite plenty of people endorsing it and openly proclaiming how successful it's been in their projects?
I personally do consider HTMX to be a valid alternative to React, but I also think that a lot of usage / promotion of it comes from people who are misinformed and think that the entirety of the JavaScript ecosystem is React. I consistently see a lot of people use HTMX over React alternatives purely because of a "distaste for JavaScript" or an understanding that everything is or has to be as complex as React unless you're using HTMX.
If people are "misinformed", that's a marketing fail by those other frameworks, despite many years of headstart. How are people even finding HTMX (with a single developer and until very recently, no corporate support) in a marketplace which includes Angular, backed by Google?
Or maybe people are kinda informed, and simply drawn to HTMX because it's easier to learn than Vue, Svelte, Mithril, Cycle, whatever (or they just don't want to try a zillion frameworks) and it works really well and developers seem to love it and recommend it a lot?
It's easy? It works? It feels like HTML? No build steps? No JSON? The primary documentation fits in a single page? Most common patterns (i.e. polling, and then stopping if necessary) are built-in? Because fundamentally, it's just standard HTML forms? The entire dev experience is focused on a single application (backend) as opposed to writing a backend and a seemingly separate frontend project, in a different language (unless you use JS on the backend)? Simply replacing HTML fragments is conceptually simpler than maintaining a shadow DOM? It embraces web standards/APIs (see client validation discussion above)?
Tauri is not inherently faster. On the largest platform (Windows), Tauri scores similar performance numbers to Chromium. Why? Because it's still Blink under the hood, since the system browser is Edge.
The instances in which Tauri is faster are when you write your business logic in Rust and your frontend logic in JS.
Simply switching to Tauri will not instantly speed up your app.
Have you seen the Ms-PL? It appears to be deliberately GPL incompatible while also having a similar list of conditions as the MIT license. I think it should be the default license for public repositories.
Section D is what makes it specifically GPL incompatible. The problem with not having ANY terms is that people can make derivatives of your software under new conditions, due to how copyright law works. You need conditions to impose the lack of conditions.
As far back as I remember (and I played with JavaScript when it was first introduced in beta for Netscape), a “static web page server” always meant that there was no backend server generating pages on the fly.
I don't think it's the mention of rust so much as not providing context on what tauri is. Mentioning that it's an electron alternative would have cleared that up.
I would have assumed it was an Electron alternative or tooling for Electron. Either way, those kind of comments are quite annoying. Commenter didn't even click the link before replying with hostility.
