You act like the explanation improved it in any way, but that just made it 10x worse. Tax homemade cakes sold on the open market, leave school cake fairs be and definitely don't open them to commercial entities. You say this doesn't affect individuals - my children competing with some business at their school cake fair and having to fill taxes after it definitely affects me and them.
It's obvious to see how simple competition between countries (economic and military) makes this impossible. Country that tries to do it will be blown up from inside, made powerless, and very quickly defeated and split up by neighbours.
Seriously, how do you even imagine that? How do you decide who can vote, for example?
"free to go anywhere else" is doing a lot of heavy lifting in a state/province with 2 "cities". Google isn't being hit as hard by the DMA, but they didn't get off scot-free either.
That still doesn't give you any right to just take what Apple built for free. Maybe there's no right option for you - I know there isn't for me, I'd prefer to have Windows Mobile (not Phone) again.
That's sadly how deeds work, 2008 taught that lesson.
Still, I don't understand people defending a trillion dollar company for doing things much worse than what wad torn apart in us courts 30 years prior. Sad that the EU needs to pick up that torch, but it is what it is.
Indeed, and they saw that software of sufficient quality can't be funded merely by sales of these devices, and decided to create a platform where the software publishers share the cost with the end users.
I yearn for Windows Mobile but it has suffered from this problem greatly. Same with early Nokia and Sony Ericsson phones with smarter features like J2ME.
>and they saw that software of sufficient quality can't be funded merely by sales of these device
I don't think Microsoft of the 90's, pre-"I take 30% as a gatekeeper" crashed and burned because it didn't leech enough funds from developers. Quite the contrary, It encouraged and empowered future entrepreneurs and customers alike, thinikg in the long term. .
>i yearn for Windows Mobile but it has suffered from this problem greatly.
Pricing wasn't the issue. Remember that this was the days where phone carriers subsidized phones with contracts, so no one was paying 600-1000 outright like today. It was a mix of lacking tech and UX needed. And a gargantuan marketing campaign.
Until Android 12 or 13 alternative stores couldn't update apps automatically in the background. And you still need to click "install" for new apps, which isn't the case with Google Play.
Try it without having Google services on that phone. Most apps and especially the essential ones are dependent on unmodified phones with Google services.
> Most apps and especially the essential ones are dependent on unmodified phones with Google services.
There are no "essential" apps that prevent you from running Android without Google services. There are certainly some nice features that require it, but you have been capable of using de-Googled Android for close to a decade at this point.
At least they replied, lol. I still have dozens of Chinese saleswomen wishing me good morning on WhatsApp more than two months after I sent my RFQ, the EU companies didn't even reply.
Holy shit. Did you end up going with China after all? Can you share anything else from your experience? I'm in disbelief about what's going on, having emailed at least a dozen labs around Europe and receiving only one reply.
There's not much more to it yet, it's a large project and my first time trying something like this. I have selected few candidates and so far the cooperation with each of them was excellent, they are very skilled, proactive and keen businesspeople with good products for reasonable prices. I really wish the market here in EU was like that.
Dead code elimination is related to but distinct from tree shaking - it also means that unused code branches get removed, for example constants like NODE_ENV get replaced with a static value, and if you have a static condition that always results to true, the else branch is removed.
In my book that's all covered by the term 'dead code elimination', e.g. removing (or not including in the first place) any code that can be statically proven to be unreachable at runtime. Some JS minifiers (like Google's Closure) can do the same thing in Javascript on the AST level (AFAIK Closure essentially breaks the input code down into an AST, then does static control flow analysis on the AST, removes any unreachable parts, and finally compiles the AST back into minified Javascript). Tree-shaking without this static control flow analysis doesn't make much sense IMHO since it wouldn't be able to remove things like a dynamic import inside an if that always resolves to true or false.
Yep, that's how it works - you first perform dead code elimination and then tree shaking exactly because it wouldn't remove everything otherwise. Agreed that you need both done one after another in most cases; however you can usually disable either one in bundler configuration and it's a separate step.
In my two cents, the tree shaking is more focus on removing unused exports in ES module at top level.
it's a mixing with Dead code elimination and link time optimization.
SWC doesn't bundle at all. Esbuild is a pretty good bundler but works well only if your code and dependencies use ESM, it's not as good as other options with CommonJS.
That’s not the biggest problem of esbuild. Esbuild has poor support for code splitting (it’s the first priority on their roadmap[1]) and limited plugin interface which makes it a poor choice for complex projects. These are the reasons that Vite for instance can’t use esbuild for production builds.
While I haven’t tried Mako, it seems to have support for advanced code splitting[2]. No idea how powerful its plugin system is.
Also, the vite team in collab with a few others is building https://rolldown.rs/, to replace esbuild and rollup in vite. It's goal is to be faster than esbuild, with extended chunking options and so on.
It's an issue because CommonJS allows stuff that's forbidden in static ESM imports/exports, and it was normal to use. Newer code is usually fine, but there are many older backend libraries that can cause issues with Esbuild. Webpack had to learn how to deal with it because it existed at the time CommonJS was most popular, Esbuild didn't.
