But most web apps are actually web sites and they do fit the document model. If we consider the web as a UI layer, it's capabilities are more than just sufficient. The issue is when you want to bring business logic into it, or fighting the document model to bring in your own abstractions.
> They want engineers to be more like a technical entrepreneur, thinking about how to add value to the business, and this comes at the expense of building things properly and correctly.
The reason is that most business are marketing driven, where the focus is let's try this to see if it sticks. Everything from the product to the technical implementation is a prototype where no ones can articulate a specification for anything. The same has infected Windows and macOS where no focus is given to the whole, but it's just adding beta features on top of other beta features.
> You can change frontends any time you want, or you can run multiple frontends simultaneously. Everything important, including validation, is handled by the database.
Or you can properly architecture your application and move the logic layer to a language with better tooling.
More often you inherit a stack and rarely you move away from it. And even if you jump on the latest infrastructure trends, there will probably be enough enterprise customers that they will support it for a while.
If you're not building something like Gmail, Docs, or Figma (AKA an app that should be on the desktop instead of the web). Rendered HTML should be the way to go, even if it's just a gateway to a more complex infrastructure.
> This leads to a tension between devs wanting to abstract and everything constantly breaking the abstraction rules.
This exists everywhere. But the churn only exists in the NPM section of the JavaScript world. QT, SDL, GTK, Cocoa have very stable paradigms to do UI. Even the DOM api is stable. But in the NPM world, nobody wants to actually stick to an API, instead they insists on supporting edge cases that should actually be an extension or another library.
> a common antipattern when trying to figure out what to do is to jump straight to proposing solutions, without forcing everyone to clearly articulate what all the requirements are.
This is a quick way to determine if you're in the wrong team. When you're trying to determine the requirements and the manager/client is evading you. As if you're supposed to magically have all the answers.
> When you’re learning to use a new framework or library, simple uses of the software can be done just by copy pasting code from tutorials and tweaking them as necessary.
I tried to use the guides and code examples instead (if they exists). One thing that helps a lot when the library is complex, is to have a prototype that you can poke at to learn the domain. Very ugly code, but will help to learn where all the pieces are.
I got on the apple train on Mojave. Before that I was enticed by iOS 6. It was a good platform. But now it just have too much restrictions and other weirdness like not being able to delete apple’s apps, writing files on network shares, not able to adjust system fonts (like the menu bar).
While I still keep the Mac for professional purpose, I move over to fedora.
reply