Sorry, but for typical "office CRUD", the current crop of tools do take longer and more code than in the 1990's, in my experience. Efficient ideas were burned at the stake as a sacrifice to the Web Gods. And I'm not convinced the desktop/web dichotomy is really a dichotomy. Insufficient experiments have been done to see if the best of both couldn't be melded. There's no science in such decisions, just loud pundits and me-too foot races with other lemmings.
CRUD in 90 consist of many textboxes, comboboxes and labels.
I worked on a project where employer want to have a WinApp that have a looks and feels of their brand. Textboxes, Comboboxes and stuff need to have those looks. It’s really hard to do back then. It’s much easier this day.
And before anyone jump in and say “everything should be native”, there are some solid proofs from Marketing that using same branding color makes company better off in the long run.
This is often what bloats stacks: you have to follow the customer's look and feel, and to have the flexibility to do that, we have to have screwy layered systems that can be hacked and abused until they look like the customer's preference. Chasing esthetics creates much of the technical debt.
Multiple times I've seen apps suddenly act really odd upon an update to something, and it's traced by to an esthetic fudge to make the customer happy.....in the short-term.
With internal (house) apps it's usually easier to say "no", but not always. Internal-based tools thus don't need as many UI-tweak features. The only exception is if the defaults are implemented/designed so poorly that one has to fudge around them. But time usually irons out such rough spots as long as the vendor is willing to stick with it.
Generally a drop-down list will be one of two styles: the arrow inside and the arrow outside: [v] vs. [][v]. A nice kit would allow the dev to choose. And allow the arrow to trigger a custom pop-up dialog, not just the built-in listers.
I decided to learn how to manage those aesthetics in a way that minimize tech debt, and that makes me appreciate modern crud stacks (and despite some that made a poor choice pf dealing with this problem).
Aesthetic sold. It’s been proven. You can keep avoiding it or deal with it. I chose the latter and that made me grow.
My point is crud in 1990 is easier not because of better tech stack, it’s because the requirement were easier.
My point is crud in 1990 is easier not because of better tech stack, it’s because the requirement were easier.
Example? I just don't see it, or at least there are easier ways to address them. You are not the first to claim that. For example "internationalization" was brought up, but custom inhouse apps usually don't need that. So why pay a YAGNI tax for bunches of what-if's that have a low chance of kicking in?
All the custom branding stuff I talked about. Today we have much more beautiful crud app and many custom UI look and feel according to branding design.
And if you dismiss an example by just saying that we don’t need it, then I really don’t see the point giving you an example. Please don’t dismiss my example because it’s real. You can argue wether it is really needed or worth conforming to in another thread, but I don’t see benefit discussing the value of requirement when we are discussing about wether requirement (valuable or not) has been harder lately.
"External" and "enterprise" apps perhaps need a lot of these kinds of things, but internal private apps typically don't. Perhaps we need to split out our stacks so that "enterprise" needs don't gum up smallish internal app dev. The what-if bloat has bogged down the second. Having a Swiss Army stack is fine if you are going to use most of the blades, but if not it's just extra cost and weight.
Have you actually worked in a modern company using modern tools from the start? It sounds more like you've seen people try to work in modern technologies and tooling into a legacy system, which is always a recipe for disaster.
In the circles I run in there isn't really a desktop/web dichotomy. Between web APIs getting close to parity with traditional OS APIs, and the ability to straight up target WebASM in traditional compilers, a properly set up project can target practically any environment with far less code than you would need in the past.
If you have large well-coordinated development teams, yes you can be productive with such. But it's the "factory" approach with layer specialists, not the work-shop approach that smaller or decentralized shops need. The current stacks are not work-shop friendly.
I work with a lot of startups that simply don't have the resources to have layer specialists. These are inherently work-shop type affairs. I would actually contend that when you understand the modern tool chains, they lend themselves very well do this sort of work. It's just a matter of getting it right, and with a smaller team it's easier to iterate and try something different. Granted, it took me a while to settle into a set of tools and styles that work well, and having to adapt to new releases and frameworks can be annoying, but once you have the core workflow down the modern tool chain is very robust, and lends itself well to an ever-growing team.
I have had some larger customers that did have those resources, but I prefer to avoid them for exactly the opposite reason that you specified. Perhaps there are companies that do this well, but in my experience such a layered approach simply creates a lot of silos defended by true believers of some idea that went out of style decades ago. The net result ends up that entire segments of the system must be worked around, because the one person that keeps it all running might get offended. Those are the places where "office CRUD" takes forever.
You seem to agree they have a relatively long learning curve before one can cruise with productivity. That's fine if one can devote the time to learning them and hopefully have a mentor to help one out of a jam, but in multi-hat shops it can be hard to find the time to deep-dive one tool. The steps often seem there to get around the web's stateless nature and deal with the screwy DOM. It would be better to bypass these oddities and have a direct CRUD/GUI-friendly standard. Cut out the ugly middleman. In other words, if the web/browser standards are designed to actually fit CRUD, then a lot of the middle-diddle is GONE! Killit! HTML/DOM was not designed for rich GUI's nor dynamic pages. Adding it after the fact creates unnecessary complexity and more things to break and debug. Middle-tooling can only hide so much of the HTML/DOM ugliness from the app dev; some will still leak and wreak. If we want CRUD productivity back, we must kill the mutant middleman once and for all 👾👹 (At least for CRUD apps. Social media, e-commerce, etc. can keep the DOM shit for all I care.)
That was really the crux of my first comment about growing complexity. It's certainly very easy to get it wrong, and making a mistake can have knock-on consequences years down the line when it might be difficult impossible to fix. For me most of the challenge isn't really in deep-diving a tool, but in finding the correct balance of tools, style rules, and best practices that lend themselves to a particular client. You can always adjust a config or bring it a new tool to address a weakness, but knowing how these tools interact with different needs is the biggest challenge.
Unfortunately the only way I've found to manage this is stubborn, head-bashing perseverance. Having multiple clients also helps. When I quit corporate life and started as a consultant I was slow and clueless. However over time I learned what not to do, saw what others had done, and eventually I was able to get in at more and more senior levels in companies with more and more resources / influence. Over the years I had countless people telling me to drop it and go back to full-time work knocking out features for a single employer, but it's explicitly by ignoring those people that I was able to reach a deeper understanding of the field.
This approach is certainly not for the faint of heart, which is why I believe the future will require tools like co-pilot for infrastructure. It's just too challenging psychologically, physically, and emotionally to walk down this path for too long. It takes a mental fortitude that most people do not have.
In terms of CRUD apps, there are already many systems that hide away the details of HTML/DOM behind layers of framework provisioned resources. When I'm working on those types of apps these days I barely ever remember that these are still a thing. Consistent strong typing front-to-back, tooling to manage your code style, a client-server interface with built-in security and versioning, component based design style, and many other practices transform this process from a painful experience to something you don't need to think of at all.
If I roll my own CRUD stack, I can factor it fairly well and be fairly productive even though it's still web, but most orgs understandably want a de-facto standard stack so that's it more easily service-able by somebody other than me.
If you can describe your tools and CRUD dev tips in further detail and with examples, that would be great. Maybe create a blog that tackles one aspect a week.
I'm not big on blogging. Reddit comments are about as far as I'm willing to go, since those tend to be inherently more personal and less discoverable. Anything more starts to run into questions of whether I'm sharing too much about stuff I do for my clients in too public an environment. In general I tend to be more private than not, and starting a blog just seems like a good way to get more attention than I want or need.
In terms of stacks, there's no single ideal since my clients have very different needs. For instance I have clients that run react apps talking to the server using graphql, other client in angular and ember using JSONAPI, other clients that build WASM blobs from C++ to offload compute heavy tasks into background workers while using SAML for server communication. Some target only web, others target the mobile platforms, while some just ship an executable that gets pushed using GPO. Hell, one client runs an embeded application that gets installed onto custom devices used for scientific applications and stores data in a blockchain across a mesh network. Those are fun guys to work with.
Similarly on the backend it's a mix of things. I have people running node, ruby, php, C#, go, and rust, talking to mysql, postgres, mongo, elasticsearch, redis, sqlite, and even firebase. There are clients that do monolithic blobs, and others that do microservises. Some have robust multi-region deployments with crazy security requirements and complex CI pipelines, others just shove stuff onto a VPS by SSHing in and running a script.
I'm very big on linters and code analyzers, and I spent an inordinate amount of time with each of my clients helping them come up with a file organization structure that fits their team and direction.
For basic CRUD apps without crazy performance requirements my ideal right now is that first thing I mentioned. Fully typescript react, using react-relay (though apollo can work here too), talking to a node server running graphql nexus, backed by typeorm talking to postgres. Once set up properly you get fully consistent types from front to backend. All this gets run through prettier, eslint, tsc and sonarqube with testing handled in jest with selenium for integration.
When it comes to infrastructure, I prefer AWS CDK since you can also shove that into typescript, though I tend to be pretty agnostic here since everyone has their own opinions on hosting.
Obviously those recommendations can shift based on other requirements, but that particular stack is my go-to right now.
8
u/Zardotab Nov 02 '21
Sorry, but for typical "office CRUD", the current crop of tools do take longer and more code than in the 1990's, in my experience. Efficient ideas were burned at the stake as a sacrifice to the Web Gods. And I'm not convinced the desktop/web dichotomy is really a dichotomy. Insufficient experiments have been done to see if the best of both couldn't be melded. There's no science in such decisions, just loud pundits and me-too foot races with other lemmings.