I share the impression. My initial reaction to the changes in the control flow syntax was rather reserved, but I understand the motivation and the Angular team has released 14 major versions from 2016 where the migration went smooth like silk (at least in my experience), so I'm hoping on the qualities of the CLI for this as well.

Microfrontends are a technical solution to an organizational problem, if you can get away with not doing them, you might do yourself, your coworkers and your company a big favor.

Having said that, do you deploy this app, that you want to split into microfrontends, as a SaaS or is it more enterprisy and installed on-prem and access mainly via Desktop? If the latter, the venerable iframe might be your friend.

Also, if you really cannot help it, you should consider building an abstraction where you consider iframes, web-components, or lazily-loaded scripts as an implementation detail.

Source: I'm maintaining something that you'd in microfrontend term would describe as an application shell in Angular 2 since 2017. It hosts > 1000 different screens provided by > 60 dev teams ( > 450 devs) into a single user facing view. And I justified at least one years' salary by talking my boss in 2019 out of using the approach again on a second product line (where the scope was narrower).

Well, I haven't really got around to use Mastodon so much, but I can recommend Manfred Steyer, who might be a well-known name from quite a few major Angular conferences, who is @[email protected]

PMs and UXers are the Tom Sayers of the software world, whitewashing aunt Polly's fence and making the other kids do the work and pay for the privilege.

Google Web Toolkit was a thing at some point in time. ;y current company still maintains some apps which are written in it.

I see, didn't think of the case of somebody with visa requirements. I don't really know how to compare US salaries to my German salary, since taxes and social security and cost of living are different, but for 162k Euro I'd probably also would rather not resignate, but do "Dienst nach Vorschrift" (= doing exactly what your asked for, but not showing extra initiative)

Wow. Since I presume that you didn't stay there: how curt was your letter of resignation?

The crucial point to me, which I could not read out of your first post, nor will I implicitly assume it as a given, is that there still is a feedback loop from product development to the staff/principal level.

I've been burned by a code base that was created by a principal engineer, who tossed it over for maintenance and moved on to greener pastures (still in the company though). It is more to blame on the organization, than on the engineer, but still such an experience leaves a slightly bitter taste.

Others have already mentioned the official documentation, which is a solid starting point. If you are jumping into a existing project, chances are that the steepness of the initial learning curve will be determined more by the choice of libraries beyond core Angular.

You'll certainly have to also get familiar with the API of some ready-made component library (Material and the likes), as well as probably some sort of state management (NgRx). The latter in my experience is what needs the most time.

My recommendation: invest dedicated time into learning RxJS, for it is deeply entrenched into core Angular, and it is the basis of all more sophisticated state management libs. Don't get overwhelmed, because in practice it will boil down to 6-10 operators you'll use a lot (map, tap, filter, mergeMap, debouce, distincUntilChanged, take, combineLatest from the top of my mind) and the tail end of little operators you'll look up when needed. https://rxmarbles.com is good for visual learners.

So, you don't actually do real work and have to live with the technologies that are chosen on your recommendation? Sound like a sweet deal. The senior engineers that have to actually make software that is sold and clean up the mess will hate your guts though.

More likely that I am the naive one - I know that there is no place without politics (we're all humans after all), but I strive to minimize politics, because it drains me.

What I meant specifically were those two points:

How to indulge a senior manager who wants to talk about technical stuff that they don’t really understand, without rolling your eyes or making them feel stupid

and

How to get other engineers to listen to your ideas without making them feel threatened

Beyond basic human courtesy, I don't agree that the fragility of other peoples ego should be the leitmotif of communication in a professional setting. I'd think a senior engineer should be able to speak up without beating around the bush, both to peers and higher-ups. I would assume for the higher-ups it should be more valuable to get candid responses from those in the trenches than smile-and-nod-yes-men responses.

And I think the counterpart of the second "listen to other engineers’ ideas without feeling threatened" is really good advice, because unlike the other one it is under your control and also a good thing in itself.

Then I also find "How to get another engineer to do something for you by asking for help in a way that makes them feel appreciated" has a bit of a manipulative touch.

Javascript can be written both in a functional and an oo style, it doesn't prescribe one over the other. The way inheritance works (prototype based) might be a source of confusion, because even though there is a class based syntax since 2015, it still has a prototype chain under the hood. Also the binding of the this pointer can work in unexpected ways. And things like scope and hoisting of variables are a bit different. Also there is no overloading of methods. It pays off quickly to read about the basic mechanics of the language if you want to do something with it.

I'm working in a company where many developers have a strong Java background, the company adopted Typescript/Angular a few years ago for new projects and it got adopted by colleagues with long tenures quickly, the syntax similarities are so close that in my eyes it is more problematic when some expectations are translated over that just don't hold, than that the colleagues struggeling with language itself, more difficult might be that standard library does not translate over in the same way the language primitives do.

Most of the points are good advise, a few of them rub me the wrong way. Considering that the author is somebody in higher management, a few of them sound like "how to collect brownie points" and "how I'd like my butt to be kissed by my underlings", utterly self-serving - OTOH maybe those indeed are the rules of the game, and those who think that particular game is worth playing might want to pay attention.

Well, if you factor in tuition fees, cost of living and opportunity costs (reduced income because you'll likely wont work fulltime anymore), do you expect to get a job afterwards - that you could not get with your current qualifications - that will pay off those costs? You've got a degree in mathematics, so you'll do the calculation...

Do you know that scene from Good Will Hunting where Ben Afflecks' character says to the snobby student who tries to waive with the prestige of his school: "you dropped 150 grand on a fuckin' education you could have got for a dollar fifty in late charges at the public library"?

If you want to grow your skills you can do it three orders of magnitude cheaper than with a degree program by studying from books or taking dedicated courses and seminars. Consider if you want to go down a path where the credentials are really a requirement or just a nice entry in your resume.

Assuming that your company has a profitable business, and you are working on the part brings in the revenue that pays the bills, you'll keep that as long as your company is interested in keeping that business. Your CTO is burning money (and fast!), maybe they've picked that habit up in a zero-interest environment, but well interest rates aren't zero anymore, so I'd be more worried if I were part of the secret internal startup.

Java is not very much older than Javascript and at the time it was far from the world's first programming language. It probably was measured by hype in developer circles the Rust of the mid-nineties.

I'd suggest the MDN tutorials on Web Development: https://developer.mozilla.org/en-US/docs/Learn as a starting point. They also cover several frameworks (React, Ember, Svelte, Vue, Angular) - but I'd only recommend a framework after you have a good grasp on JS as a language. For deepening your JS knowledge I can very much recommend the "You don't know JS" books, they are free to read only: https://github.com/getify/You-Dont-Know-JS.

Also: pick one framework, not all of them. The safest bet is probably react, I personally work with Angular. Anyway, for the framework of your choice you probably want to walk through their official tutorials.

Not sure if it counts as not widely used, but I think the Collections.unmodifiable(Collection|Set|List...) methods are very useful.

Thanks, I'd be delighted to moderate the community.

Seconded. Really, anything but the oracle JDK.