6 ms·
> Because of limited time, and low confidence in UX design decisions, I would often follow the path of least resistance and the end product would be heavily inf
by Frotag 4y ago
> Because of limited time, and low confidence in UX design decisions, I would often follow the path of least resistance and the end product would be heavily influenced by the tools I used to build it.
Angular with the Angular Material components library would be very "batteries-included". You don't have to decide how you store state, what testing framework to use, etc. Angular provides sane defaults for most things. And it also ticks your TypeScript requirement.
> Relatedly, I expect to get the UX design horribly horribly wrong and start from scratch at least once. I also suck at making things look pretty and also don't find this problem very rewardinging to think or read about.
With angular material, you'll get pre-built and pre-styled navigation menus, form inputs, etc. Wiring them up to your TypeScript code will be a breeze but it'll be tough to customize them if you're going for somewhat unique / unusual behavior or styling.
And occasionally you'll need something commonplace like a time picker and the library won't have that.
> I don't think I'll want a native desktop app but an iOS/Android version could make sense.
The simplest route to putting your app in the app store / play store is called a Progressive Web App (PWA).
For which you basically need a config json and some icons. The gotcha is that PWAs have virtually zero access to native features.
> I don't really have the discipline for manual testing. Luckily I also find it satisfying to over-invest in test automation. I don't really know how this is done in frontend land but good tooling would be a big plus.
Angular uses Jasmine by default for unit tests. You can test both the business logic and UI interactions this way, but in my experience mocking out components is annoying and a fuckton of maintenance. I usually stick with testing the logic or clumps of un-mocked components.
There's also support for end-to-end tests using Protractor, but I'm not super familiar with it.
> I'm happy to sacrifice one or more of the other requirements in favour of tools that are likely to be maintained 10 years from now.
Angular will probably be around 10 years from now, but I doubt keeping the version / other dependency versions up-to-date will be painless. Some things are just kinda deprecated / replaced for lame reasons (but you'll have notice of these changes waaay in advance).
- mattlondon 4y ago+1 to angular being "batteries included". If you need to ask what framework to use, pick angular as all of the hard choices have already been made. You don't have to make any more choices after picking angular - you are all set and everything not only works together perfectly complete with extensive documentation for the whole thing, but you also get a professionally maintained UI framework designed to work with it. Compare with react which is just the first of many subsequent and continual choices you will need to keep on making as sub-frameworks come and go and need to be replaced as you maintain your app e.g. major security issue in foo 1.1 but you can't upgrade as it has a dependency on boo 1.2 that has not been updated so you need to switch to quux 0.9a but that changes how forms are handled so you need to refactor your apps routing, and that breaks your test framework etc, then someone deletes the leftpad repo and none of your dependencies work anymore anyway etc (oh and by the way your NPM install is out of date too so upgrade that first). Then factor in fighting with NPM & node, dealing with separate documentation for different sub-frameworks, your effort and sanity from trying to integrate them etc. I am perplexed as to why anyone would pick react for anything apart from the most trivial of UIs - it is a nightmare. Angular will be around for a long time - it is used extensively in enterprise environments and Google.are throwing SWEs at it even if the vocal cool kids are using react or Vue or whatever.
- ricardobayes 4y agoI agree. I chose React only for the simple reason there are more React jobs than Angular out there.
- zkirill 4y agoAngular markets itself as a tricycle but comes with a manual in which the first chapter after the introduction instructs you to swap out your wheels for jet engines. The learning curve and hidden complexity is absolutely insane and I would only recommend choosing Angular in extreme cases where you actually need to break the sound barrier. Source: I maintain a complex Angular SPA since AngularJS/2.
- r0b05 4y agoCan you elaborate on some of your challenges please? I find it quite straight forward to use once you overcome the somewhat steep learning curve.
- zkirill 4y agoSure, the following challenges come to mind: * Must maintain a deep understanding of RxJS, which is its own beast. Angular team sometimes uses it in "creative" ways that change between versions in creative ways. * Must not go off reservation (or do) where the Angular code is committed but not covered by documentation (because reasons). Template variables (hack an ngIf into an ngVar) come to mind, as well as how not subclass an abstract component (e.g. abstract component can technically have its own template and interesting things happen when children also have their own templates). * Must understand how Angular i18n works by inspecting various Angular code repositories (and sometimes having to build the Angular project yourself, inadvertently discovering the "wonders" of Bazel). For example, the list of Angular supported locales is generated from CLDR dumps. CLDR likes to release new dumps and so the list of Angular supported locales changes (sometimes). You can think of interview Angular questions from hell such as what is the default build locale and what happens if you change it to "en-US-POSIX"? Or, my current favorite, how to ask Angular put dir="rtl" into the generated index.html for locales that are RTL? These are just off the top of my head. I didn't even go into various performance optimization techniques which may or may not be made redundant by the next version of Angular because of their own compiler optimizations. Also, having to make the decision of the E2E testing solution (or sticking with Protractor).
- 4y ago
- aaaaaaaaata 4y ago> The gotcha is that PWAs have virtually zero access to native features. Huh? Lots been done in this space — what are you still missing?