First of all, you should work on the structure of your article, both mark-up (did you copy paste your blog into dev.to?) and content. There are a lot of ideas are mixed together here.
Second, sounds like your team/company is missing a front-end lead/architect that takes care of the overall architecture and everyone is running in different directions (hence your frustration with micro-frontends).
This may be more difficult to achieve in a larger company with multiple teams. You call it the layout team; Spotify has their cross-team "tribes/guilds/chapters/whatever" model to get like-minded people across teams to talk with each other. The main point is: just put the people who want to take ownership of the front-end architecture together and let someone propose a direction that everyone can agree upon.
This should lead to some consistent ideas that other teams can work with, here's an example of what that could look like, in terms of topics. Mono-repos can help getting everyone on the same page with regard to tools and internally published libraries, but requires some set-up and extra overhead. From there you can create a component library and/or styleguide that you can communicate with designers/management.
But the main point is that you should get people talking to each other about an overarching front-end architecture and code conventions!
Regarding the formatting, I copied from my blog which uses also markdown, but it seems they don't render the same way. Already corrected.
I totally agree that the main point is get people to talk to each other. With this post, I wanted to throw into the pool an idea in case you have this problem.
There's a weekly architecture meeting where developers can discuss anything technical, improvements, interesting architecture concepts, best practises, etc. Most of the time, the topics that are discussed are related to the features that we're building, but not always. Developers can create user stories for technical improvements, every sprint has a budget of X story points for this kind of user stories.
We're gradually moving towards a mono-repo approach to make sharing code across the whole codebase easier to manage and to standardize internal libraries. So far it has proven useful to stay in control of changes to the codebase (with semantic versioning). It also helps with separation of concerns because every package has its own scope, while the code is still co-located in one repo.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
First of all, you should work on the structure of your article, both mark-up (did you copy paste your blog into dev.to?) and content. There are a lot of ideas are mixed together here.
Second, sounds like your team/company is missing a front-end lead/architect that takes care of the overall architecture and everyone is running in different directions (hence your frustration with micro-frontends).
This may be more difficult to achieve in a larger company with multiple teams. You call it the layout team; Spotify has their cross-team "tribes/guilds/chapters/whatever" model to get like-minded people across teams to talk with each other. The main point is: just put the people who want to take ownership of the front-end architecture together and let someone propose a direction that everyone can agree upon.
This should lead to some consistent ideas that other teams can work with, here's an example of what that could look like, in terms of topics. Mono-repos can help getting everyone on the same page with regard to tools and internally published libraries, but requires some set-up and extra overhead. From there you can create a component library and/or styleguide that you can communicate with designers/management.
But the main point is that you should get people talking to each other about an overarching front-end architecture and code conventions!
Thanks for the feedback!
Regarding the formatting, I copied from my blog which uses also markdown, but it seems they don't render the same way. Already corrected.
I totally agree that the main point is get people to talk to each other. With this post, I wanted to throw into the pool an idea in case you have this problem.
How's the situation in your company?
There's a weekly architecture meeting where developers can discuss anything technical, improvements, interesting architecture concepts, best practises, etc. Most of the time, the topics that are discussed are related to the features that we're building, but not always. Developers can create user stories for technical improvements, every sprint has a budget of X story points for this kind of user stories.
We're gradually moving towards a mono-repo approach to make sharing code across the whole codebase easier to manage and to standardize internal libraries. So far it has proven useful to stay in control of changes to the codebase (with semantic versioning). It also helps with separation of concerns because every package has its own scope, while the code is still co-located in one repo.