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.
I am aware it's possible to use jsx with vue. It's trivial and can come in handy. It's just js until templating. To me, these differences barely matter because I can do all that stuff on my own without any frameworks in the first place.
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.
We’re about to embark on the MFE journey and I’m concerned about pulling it off in a way that will have justified the effort. Our motivations are pure, we have many feature teams, we’re driving toward team independence, already breaking up the monolith into Microservices, etc. But on the FE we have the standard requirement to maintain eventual (definition tbd) UI consistency and so intend to continue to maintain a large number of build-time dependencies between MFEs and shared libraries. So I’m not sure exactly how to pull this off.
Are any of these “many success stories” talked about online? Case studies we can get pumped on?
This gets you most of the advantages of a microfrontend:
1) Monorepo with multiple workspaces
2) With several separate independently deployed applications, each maintained by a separate team
3) That share a set of common packages for common stuff (auth, etc) with full typescript definitions
4) Add CI to typecheck if any shared package changes types you get errors
5) Preferably with the packages being able to be independently run for development (something like storybook, although I don't recommend it)
6) Preferably with the packages being kept small, lean, with limited number of external dependencies (ie, settle on the cross-team deps to use, so framework, routing, data-fetching, etc)
7) Some kind of pre-commit git hook or CI script to validate a set of core shared dependencies used by packages are kept in sync (ie, everyone is running the EXACT SAME React version). I use this one:
https://gist.github.com/DanielHoffmann/a456aadb2f27880d59241...
8) Shared build configuration and tools, all apps are validated, built and bundled by the same code.
9) NO PACKAGE PUBLISHING/VERSIONING, all dependencies are workspace:*
For example:
folder-structure:
/apps/{team1-app-name}/
/apps/{team2-app-name}/
/packages/auth/
/packages/some-util-lib/
/package.json
"scripts": (test, lint, format, typecheck all done at the top level package.json)
"workspaces": [
"apps/*",
"packages/*",
],
/packages/auth/package.json
"scripts": (dev to run in development mode)
"devDependencies": { "some-util-lib": "workspace:*", "react": "^18.0.0" }
"peerDependencies": { "some-util-lib": "*", "react": "*" }
/apps/{team1-app-name}/package.json
"scripts": (dev to run in development mode, build for production builds)
"dependencies": {
"auth": "workspace:*"
"some-util-lib": "workspace:*"
}
This doesn't give you 100% of the independence of microfrontends, but it does give you quite a lot of bang for your buck. Depending how much independence or reuse you want you might want more or less shared external dependencies (for example your shared packages could be framework agnostic and just use raw JS)
The build/bundling configuration can set up separate chunks for the core set of shared dependencies (react, router, etc) to improve build times, load speeds and caching*
First off, I appreciate the thoughtful write-up, under different circumstances this is the direction I’d probably be heading. However our web Frontend code is all currently in a large-ish (500 packages, 100 apps) monorepo and we’re actively pursuing breaking that up into a hybrid repo model, largely in the interest of true team autonomy. We want our code organization to better reflect our Eng org structure and to establish much stronger lines of ownership and responsibility. Obviously we see other compelling reasons to take this big step, but there’s also a lot of risk involved, particularly around dependency management and figuring out how to accomplish eventual UI consistency across our web apps, all of which will use a large number of shared libraries/components that will be broadly organized into a handful of repos (likely monorepos) representing domains and owned by different teams. The intent is for this evolution to culminate in a microfrontends architecture as a way to support collaboration across autonomous teams without the need for built-time coupling.
Fair enough, probably far bigger scale than I am used to. But I wonder why move away from a monorepo? Publishing and versioning common packages is a huge pain in the ass, especially for JS projects where you need transpiling, sourcemaps, etc.
Some smart branch management so teams can work independently seems better for me. For example each project gets their own production branch and development branches to trigger deployments and can pull changes from master as they see fit.
If you are planning on these shared components and dependencies be versioned I highly advise against that, the permutation of versions of underlying common libraries (like React) can make an incompatible versioning hell where component X works on React ^16.0.0 but in practice was tested in React ^18.0.0 only. In my own project I explicitly force all shared dependencies (which I try to keep to a minimum) to be on the same version.
> without the need for built-time coupling
There are two ways of having build-time coupling:
1) Shared build/bundling code, configuration and tools
2) Single build/bundling for all the code
You can most definitely have independent projects sharing the same build/bundling code, configuration and tools while every project is built separately and independently. This can make it hard to integrate with solutions that rely on taking over your bundling though.
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.
Telling someone they learned something wrong maybe isn't the best approach when trying to explain why something should not be confusing. Especially when it's a widely held view, maybe the learners are not the problem.
Most people learn JSX when they learn React. It was created by Facebook for React, after all. What does the React docs teach about className?
Here in the intro it doesn't even explain that you need to use className instead of class. It uses it with no explanation. Then it throws in a line about camelCasing and assumes that you understand why it changed.
Finally! In a page that seemingly has nothing to do with JSX we get told to change how we write HTML, but we're not even told why. (The htmlFor section tells us.) No wonder people are confused.
Yes, className is a property of the Element interface but it is not the attribute used when writing HTML. You're still changing how you write HTML. It is no longer standard. That is the point people are making here - JSX introduces enough edge cases that you must learn that it adds equally as much mental overhead as the template DSL for Alpine or Vue. Even if people understand the reasoning and it is not confusing, it's still a shift.
> Here in the intro it doesn't even explain that you need to use className instead of class.
Again, because `className` is not React specific, it's JS DOM API specific. Sounds like the real problem is that people start learning React without fully learning the JS DOM API itself, then they get confused when things like `className` or `htmlFor` show up.
> Yes, className is a property of the Element interface but it is not the attribute used when writing HTML. You're still changing how you write HTML.
You're not writing HTML. That's the entire gist of the parent comment. It looks like HTML only insofar as HTML is a type of XML. But what you're really doing underneath is something like:
JSX is simply syntactic sugar on top of DOM operations like that (albeit within the context of a renderer like React; Svelte eschews a renderer entirely and truly is creating DOM operations like above). In React, JSX would be direct syntactic sugar for:
It is standard, it is in the Element API, I don't know how it can get more standard than that. Again, it sounds like the problem is that people really should learn JS and DOM separately before ever touching React. Sadly, too many beginners in web dev and programming in general gravitate towards a React/Node stack, which are good production tools, but they really ought to know how we got there.
Now why I don't use DSLs is because they don't use the standard of the JS DOM API, they use their entirely new creation, like v-for or #if :else. That is why I consider Vue or Svelte templates to be DSLs while not JSX, because the latter is fully compliant with the Element spec, and it uses plain JS/TS, unless you define a DSL to be so broad as to be literally any transformation of code, which, well, I can't practically agree with.
> 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.
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.
Reality is these middlemen tech companies want to do away with quality control, and pocket the savings as profit.
As a customer and hotel guest, it never made sense for me to not pay for quality control. So I will continue to pay Hilton/IHG/Hyatt/Marriott/Choice/etc. Not that all those brands have amazing quality control at all times, but at least there is some effort to use human labor to do something.
Similar experience with VRBO, booked an apartment in Munich, on arrival, turns out it was completely different than advertised (even the photos were different). We only stayed a single night, because the room situation just wasn't suitable for two adults. VRBO and the owner refused to refund us. After pointing out the discrepancies, and providing proof that the owners were using the same listing for different properties, VRBO only refunded their fee to us, claiming the transaction was really between us and the owner...
Yet there's plenty of stories of buyers getting banned for trivial TOS infractions. But when a host is essentially scamming people, nothing happens.
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).