FlorianRappl

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.

This is why I love HN. Not sure if I would have gotten the memo... Impressive tech, useful lib, super awesome landing page. Just blown away!

Thanks!

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.

Depends on how much you read it

> 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.

It was Munich - and it only happened once.

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.

The comment reads like you used JavaScript 10 years ago. For instance, just use arrow functions and this remains untouched.