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

Yes its neat - I wish more bundlers adopt it!

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

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.

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.

Totally. I was about to post the same.

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.

smapiot | SW Architects and SW Engineers | ONSITE | Full-time | Munich, Germany

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.

ASML is a great company. What should be stressed is that the lenses are coming from Zeiss SMT, which is a strategic partner of ASML since 1997. In fact, they are so important that ASML bought a significant part of the Carl Zeiss subsidiary some years ago. You can't get a pretty good video about the relationship and EUV at: https://www.zeiss.com/semiconductor-manufacturing-technology...

But the <noscript> tag itself vanishes during document parsing.

This is wrong. In case the browser does not have JS (enabled) its a normal element.

smapiot | SW Architects and SW Engineers | ONSITE | Full-time | Munich, Germany

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

I would love to switch to esbuild, but unfortunately some basics are still not in there. I read some people switched, but I wonder how they have projects requiring 30+ seconds when not utilizing bundle splitting. Maybe I am missing something... Are you outputting esm files or what?

Would be great to get some insights how people are mitigating the lack of bundle splitting in non-esm output right now. Thanks!

This is so great! Still using my one plus 6T and not up for a change yet. Battery life is still good and the performance is more then sufficient. Now, the afterlife seems to be predestined, too.

Thanks for sharing! How is it different to DAPR (https://dapr.io) (besides using a side car to enable all kinds of frameworks instead of just go)? Are the goals similar or actually quite different?

How difficult is it to run it completely independent and on premise (i.e., define custom storage provider etc)? Any examples available? Thanks!

Houdini is one of the potential game changers out there. I'm watching the spec progressing and the implementations getting ready for years. Its amazing, but its another step of turning every website into an application, i.e., requiring JS.

This is over simplified. Using TypeScript you should specify all the types required to have your code base fully qualified - not more. In the example above having a fully typed `otherFunc` would directly specify the type on `func`. If you (automatically) refactor `otherFunc` the type naturally flows and you don't end up with (unnecessary) modifications on other spots. Use type inference when possible, but don't over do it.

smapiot | SW Architects and SW Engineers | ONSITE | Full-time | Munich, Germany

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/416625/frontend-architect-sen....