Just recently (like 2 months ago) I had the task to evaluate proper OSS replacements for the main charting of a client. So far, they've used a paid solution - but there have been a couple of reasons why the wanted to migrate.
Needless to write that eCharts was the clear winner. Not only is it greatly customizable, fully feature complete - it also had similar performance data as their paid solution. And performance matters as their largest chart has around 300k data (we discussed and could maybe be satisfied with 80-100k as well - but for most OSS charting libs even that would be pretty much impossible to render quickly).
For everyone who is looking for something super easy and quick it might not be the best solution (personally I like Chart.js in this area the most), but if you want a charting solution that out of the box is fast and comes with everything you might ever need then eCharts is for you.
Yes indeed - it can be optimized further, but it will also loose some perf. when things such as sourcemaps or tree shaking are introduced. Right now I am positive that in total it should be around the same as of now due to the potential optimizations (e.g., streaming in the JS AST generation).
Personally, I think that C#/.NET is much less complicated than Rust and more powerful than Go. It comes with some drawbacks as well - not gonna lie.
The main reason why C#/.NET can be viable in that space is AoT. Without AoT the startup performance (as well as runtime requirements) is killing the whole idea.
AoT, on the other hand, comes with some challenges. Some libraries cannot be used or require some work to be integrated. Hence, some of the flexibility of .NET cannot be used.
This is actually one of the few conferences where I really like pretty much every talk. These are not mainstream, yet all of them convey so much knowledge and information. End of the year is always reserved for watching CCC talks...
Because JSX is essentially just JavaScript. However, this also opens the door to the question: What will then render / use the JSX element? After all, a JSX element is just a function call. What function is called how is the outcome of this function then rendered?
You cannot compare Vue/Angular (frameworks) to JSX (syntax extension for JavaScript). As a fact you could write your templates in Vue or Angular using JSX.
Personally, I wouldn't call it a "last resort", but I definitely agree that keeping a functioning monolith is preferred.
Nevertheless, one thing to keep in mind (and I do consulting on MF for the last 5 years) is that most projects / teams are not well prepared and actually not at all suited for MF. MF solutions are usually just done from a technology POV, which is already a problem. Next thing is that the used technologies are often also not well suited. People tend to use strongly coupled things that just create hidden monoliths. In the end projects fail often because either the organization is not ready to have truly independent teams or / and because the software has just become too complex and unmaintainable.
To end with something positive: We also know many success stories in that area where people spent the right amount of research on what technologies to use and where everyone in the organization was prepared to accept the new teams setup.
> JSX is a DSL that looks almost like normal HTML, but differs in small uncanny-valley ways.
My point was not that its a common misconception that JSX has something to do with HTML - therefore comparing it to HTML and then being surprised that it isn't, shouldn't come as a surprise.
Also it does not differ in small uncanny-valley ways. Just one example on the syntax level: HTML has real self-closing elements (e.g., `<img>`) while JSX requires you to explicitly self-close (e.g., `<img />`). In HTML you also cannot explicitly self-close any element (e.g., `<div />` will just be parsed like `<div>`), while in JSX you can. I don't even want to start about whitespace etc. - those things are actually found / listed in any decent JSX tutorial.
That is just wrong on many levels. JSX brings an XML-like notation to JS. It has nothing to do with HTML. react-dom couples your React DOM to the real DOM - thus allowing you to use special JSX elements that create DOM elements. But then you / React interacts with them using the DOM API - not HTML source code.
Things like `htmlFor` or `className` should not be confusing - these are the official DOM properties. `style` in its DOM API also has an object-oriented API and not a string. If you are confused by these things (className vs class, ...) then potentially you started learning JSX from a completely misleading / wrong point.
I know most articles on React / JSX get that wrong, but this non-sense has to stop. After all, you do not write React in the browser because you want to generate HTML - you do write it to manipulate the DOM. On the server, you may want to generate HTML and then this can be misleading (true), but this has not been the main objective.
I shared the excitement, but as so often it was only executed half-way. In essence, instead of recreating processes from the ground up to fit the new reality, they tried to make everything as beforehand. Unsurprisingly, that was a huge uphill battle - in the end they spend more money than beforehand and had a lot of trouble in maintenance etc.
(Regarding the 2020 public announcement; nothing has happened since then IIRC so I would not count that in - just talk no actions)
I fully agree. Played around with Bun quite a bit, but any benchmark is meaningless until it has all the features and stability to have it production ready. Until then it's just a promising (and very respectful) start - but nothing more.
If all the other warning signs here in the comments are not enough - this one should be.
I only booked via AirBnB once, but I am quite convinced now that this will be the only time. I don't want to rely on a system that can just do what they want without transparency.
Reality is that a platform like AirBnB should care about both sides - sellers and buyers. Sure, sellers generate the revenue, but without buyers nothing is sold and the platform is not interesting.
I did run windows 95 with 2MB. It was my main reason to get 2 more bars with overall 4MBs going up to 6 in total. Boot process with 2MB took about 20 to 25 minutes.
Yes you can. Code splitting will potentially not land in near future, but of already there if you output esm - which you can then (if wanted) convert with a simpler tooling (e.g. Babel or swc) to another format of you want. We switched to es build a year ago and never looked back.
I'm not getting your comment. The payload is not encrypted. I think you refer to the signature. The payload can always be decoded. It's just JSON into base64.
Just looking at it was "fine" (not terrible, not great), but once I went back to HN I felt a flash like a sudden relief on my eyes. The pain was physical...
What about TypeScript here? I think it does not yet understand such imports. However, especially for types (i.e., evaluation at compile-time) imports from a remote source would be good.
Instead of keeping up-to-date via npm I could just write `import type { FooType } from 'https://remote-types-registry.com/foopackage@2'` and wouldn't have to worry about typing updates. (surely this scenario is only valid when types are not shipped with the dependency)
Not sure I get that comment. I think the API first design is good. It let's you decouple the translations from your application.
It's then up to you too either do that on the server, on the client, or at build time. All three are easily possible. If you'd start with a static file then the decoupling and automation tasks will be much more difficult to achieve.
Needless to write that eCharts was the clear winner. Not only is it greatly customizable, fully feature complete - it also had similar performance data as their paid solution. And performance matters as their largest chart has around 300k data (we discussed and could maybe be satisfied with 80-100k as well - but for most OSS charting libs even that would be pretty much impossible to render quickly).
For everyone who is looking for something super easy and quick it might not be the best solution (personally I like Chart.js in this area the most), but if you want a charting solution that out of the box is fast and comes with everything you might ever need then eCharts is for you.