A lot of words to say "LLMs are good for this, trust me bro!"
You're bashing the old way, but you do not provide any concrete evidence for any of your points.
> The unit of work is no longer “branches” or “commits,” it’s intent.
Insert <astronaut meme "always has been">.
Branching is always about "I want to try to implement this thing, but I also want to quickly go back to the main task/canonical version". Committing is about I want to store this version in time with a description of the changes I made since the last commit. So both are an expression and a record of intent.
> Parallel workstreams used to require careful coordination: rebasing, merging, conflict resolution, mental bookkeeping of state.
Your choice of words is making me believe that you have a poor understanding of version control and only see it as storage of code.
Commits are notes that annotates changes, when you want to share your work, you share the changes since the last version everyone knows about alongside the notes that (should) explain those changes. But just like you take time to organize and edit your working notes for a final piece, rebasing is how you edit commits to have a cleaner history. Merging is when you want to keep the history of two branches.
Conflict resolution is a nice signal that the intent of a section of code may differ (eg. one wants blue, the other wants red). Having no conflict is not a guarantee that the code works (one reduces the size of the container, while the other increase the flow of the pipe, both wanted to speed up filling the container). So you have to inspect the code and run test afterwards.
Discard the above if you just don't care about the code that you're writing.
> where "native apps" means platform lock-in by monopolies, less sandboxing and user-control than on the web, much more gatekeeping and control over published binaries, and these days the web app is usually a more private/secure alternative to the native app
Please add “mobile and/or proprietary” before “native apps”. Linux and BSD on PC are still very much free. The web as a platform is just a NIH effort.
I do not agree with Google on preventing apk installation. But unknown apk is a different risk profile than letting unknown entities to access local usb devices.
The main issue in the former case is that google is posing itself as a gatekeeper instead of following a repo model like Debian or FreeBSD. That’s wanting control over people’s device.
Allowing USB access is just asking to break the browser sandbox, by equating the browser with the operating system.
I'm not familiar with the Windows platform but although you can have userspace USB drivers on linux, you still need to be able to run code that can talk to the sysfs interface.
It's minimally viable, which means it does what people needs now without costing too much in resources. I'm not Joe (I wasn't even born at that time), but
> a text file (with an undefined character encoding)
Most team kinda have the same system to work from, so character encodings doesn't matter much (and people who deviates from the norm know how to handle such things).
> an undefined structure for the header of the file
That's pretty much YAGNI. By the time you get to this point, you could probably switch to a DBMS and import the old data.
> a rule that status must be 'open' or 'closed' in every human head
A lot of rules, even today, are encoded in human head. In the ticketing systems at $WORK, each team has a different set of fields with different semantics for the status field. And there's a global repo. You can easily enforce that new addition don't have any other value.
> a revision control system which dates changes
No need to wonder how to enforce proper date control. And less code
> an out of band way to request and obtain permission to change the owner, possibly a high-trust environment with no arguing "you agreed" "no I didn't"
The owner of the ticket? Why can't it be a new update to the file? It's version controlled. And the import to the global repo (which I think is the source of truth) can be monitored and constraints enforced.
> a programmer/scripter who can develop the management reports on-demand
It was 1986. If you have a computer on site, you also have a programmer available.
---
So you got a working solution without investing too much resources solving subproblems, some of which are not even important.
Even with bootstrap, design was a solved problem. What you bring with a UI designer is appeal (aka make thing pretty and enjoyable). If you want utilitarian, even the old x11 toolkit like Athena, Win 98 era widgets would do the part.
I wouldn’t, but you’re not much of a product designer if you can’t get your ideas across using simple tools like a sketch on a whiteboard (there was|is an app the let you take photos and link them using active areas).
So you can take bootstrap (or even raw html) and create something useful. Then you make it nice, not the other way around.
You would have to be a big outlier to feel the need to create a custom widget. Most widgets have been defined since decades.
I agree that design is about primitives. wireframes and IA should come across clearly at any fidelity.
But i don't think that's what tailwind and bootstrap are doing. But people very much use these tools to "solve design".
The layouts, widgets, and primitives in these tools are not primitives. I can't deny they get tons of people very far very fast. But my main disagreement is that all of this isn't design and it's not what designers do. You touched on what i agree with: UX flows, diagrams, stories, journeys, personas, etc, these all need to be designed and connected in reality using various primitives for the medium.
Then you slap a cohesive paint job on it, interaction elements, tone and terminology and yes, there is that element of design too.
UX designers I encountered have mostly been tasked on ensuring consistency across the various product (A lot of devs are very cavalier about spacing and font sizes). Sometimes they proposed new flows and layouts, especially when the product needs a coat of paint.
So tools like Figma is nice in that regards as it's simpler to iterate on (From simple to hardest: Sketch on whiteboard|paper, Wireframe tools like Balsimiq, Figma|Sketch, css code) because it's pure fiddling with various properties. Figma has direct feedback while the code may require a compilation phase.
hmm, actually, you got a point there. emacs could be the like that graphical terminal, except for now it is still stuck inside a traditional terminal itself. even the GUI version of it is mostly just looking like a terminal, not really taking advantage of the potential of graphical elements. we would need a real GUI and support for exchanging structured data with external commands. for now emacs is still kind of its own world.
> even the GUI version of it is mostly just looking like a terminal, not really taking advantage of the potential of graphical elements.
Emacs is text based (mostly), but customization happens through the the concept of Faces, not ansi escape codes. You can then embed properties in the text objects and have them react to click events. The only element missing is a 2D context that could be animated (if it's static, you can use SVG as Emacs can render it).
You're bashing the old way, but you do not provide any concrete evidence for any of your points.
> The unit of work is no longer “branches” or “commits,” it’s intent.
Insert <astronaut meme "always has been">.
Branching is always about "I want to try to implement this thing, but I also want to quickly go back to the main task/canonical version". Committing is about I want to store this version in time with a description of the changes I made since the last commit. So both are an expression and a record of intent.
> Parallel workstreams used to require careful coordination: rebasing, merging, conflict resolution, mental bookkeeping of state.
Your choice of words is making me believe that you have a poor understanding of version control and only see it as storage of code.
Commits are notes that annotates changes, when you want to share your work, you share the changes since the last version everyone knows about alongside the notes that (should) explain those changes. But just like you take time to organize and edit your working notes for a final piece, rebasing is how you edit commits to have a cleaner history. Merging is when you want to keep the history of two branches.
Conflict resolution is a nice signal that the intent of a section of code may differ (eg. one wants blue, the other wants red). Having no conflict is not a guarantee that the code works (one reduces the size of the container, while the other increase the flow of the pipe, both wanted to speed up filling the container). So you have to inspect the code and run test afterwards.
Discard the above if you just don't care about the code that you're writing.
reply