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).
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.
https://github.com/FlorianRappl/netpack
This is a small experiment I've worked on during my winter vacation. I wanted to see if instead of using Rust / Go / Zig / whatever for development of web tools C#/.NET might be a viable alternative (esp. in terms of performance).The answer is yes. Right now it's still feature incomplete (so generally I would not make this a too strong statement), but as of today it's faster than the tested...
In the past I've written a little plugin that is available for almost all bundlers allowing you to do that: https://dev.to/florianrappl/getting-bundling-superpowers-usi...
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.
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.
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 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.
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...
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)
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.
smapiot (https://smapiot.com) is a young startup focusing on premium IT consulting and on engineering software services in the IoT and development tooling space. For smapiot the bread and butter business is the development of cloud native applications featuring reliability, scalability, and security. Our consulting projects touch a broad functional spectrum including identity management systems and smart home platforms.
Our technology stack includes C#/.NET, TypeScript/React, Azure, K8s and many more interesting and leading-edge technologies. Essential to us is a friendly and collaborative working environment which fosters a constructive and open discussion culture, while working in an agile and flexible way tailored to our needs. Within smapiot everyone has a tech background and we are proud of our experienced architecture team. Regularly we meet up in joint retreats, general tech discussion sessions, or other team activities.
We are looking for skilled web frontend and backend developers who are keen on building amazing tools and state-of-the-art solutions. If you have some work experience in Europe and are attracted by the vision of contributing to the growth of a young, innovative company, then don't hesitate to apply at https://smapiot.com/jobs/frontend-developer.
This is wrong. In case the browser does not have JS (enabled) its a normal element.
smapiot (https://smapiot.com) is a young startup focusing on premium IT consulting and on engineering software services in the IoT and development tooling space. For smapiot the bread and butter business is the development of cloud native applications featuring reliability, scalability, and security. Our consulting projects touch a broad functional spectrum including identity management systems and smart home platforms.
Our technology stack includes C#/.NET, TypeScript/React, Azure, K8s and many more interesting and leading-edge technologies. Essential to us is a friendly and collaborative working environment which fosters a constructive and open discussion culture, while working in an agile and flexible way tailored to our needs. Within smapiot everyone has a tech background and we are proud of our experienced architecture team. Regularly we meet up in joint retreats, general tech discussion sessions, or other team activities.
We are looking for skilled full stack web and backend developers who are keen on building amazing tools and state-of-the-art solutions. If you have some work experience in Europe and are attracted by the vision of contributing to the growth of a young, innovative company, then don't hesitate to apply via StackOverflow at https://stackoverflow.com/jobs/484653/typescript-ninja-for-m... (Microfrontends / TypeScript / React) / https://stackoverflow.com/jobs/487296/senior-backend-develop... (Azure / C# / .NET).
Would be great to get some insights how people are mitigating the lack of bundle splitting in non-esm output right now. Thanks!
How difficult is it to run it completely independent and on premise (i.e., define custom storage provider etc)? Any examples available? Thanks!