Those in the weeds are generally going to have a more nuanced view of the benefits and challenges--i.e. that it's incredibly useful but also very fallible and requires careful hand-holding to get production-ready results.
I say all that as an AI optimist. The value is real and the most impressive demos are glimpses of where we're heading. But it's going to take some time before the median result catches up to the hype.
The way has been shown with the web. Now many people who would have been paying a designer are using things similar to Wix. A lot of people don’t need top of the line custom work, and most custom work isn’t top of the line. I’ve seen AI frequently, but a bit unpredictably, hit the high notes. https://www.joelonsoftware.com/2005/07/25/hitting-the-high-n...
Case in point I'm in the middle of, let's just call it what it is, an argument, because a new page in a new section of our app has a different design for form elements, specifically single check boxes (think TOS, affirmations, etc). Well we have shared components obviously, so we're reusing the component. No sense taking half a day or more to reskin this one checkbox on one page.
The amount of grief and manhours wasted discussing this checkbox would astound you. Thousands of dollars in payroll over multiple meetings so far with no end in sight because this particular check box just has to be slightly different. The ticket which has been feature-complete for over a week has no chance of being merged in November.
There is the old story about Steve Jobs and the Mac calculator app, where they made a calculator toolbox to build one in order to prevent him demanding seemingly arbitrary changes all the time.
https://www.folklore.org/StoryView.py?story=Calculator_Const...
That's because they don't know what they are. They suffer the consequences of not having them though.
This is 100% incorrect. Users do care about software being built for them, in a language they can understand and use, and they very much want it to be usable and accessible to them. You'll have to provide me with some citation showing otherwise for me to take that argument seriously.
> I would argue that i18n and l10n belong outside your language's framework (and obviously outside CSS).
Obviously Frameworks and CSS disagree with this assertion. Considering you've presented no argument though, I don't see why you would think that, for example, it wouldn't be important to style your site differently for different languages. Are Americans routinely reading rtl?
Edit: It just occurred to me you think this way because most everything you create is specifically created for you and those like you. You care, you just don't realize you care until it's taken away.
We know this, you don't need to tell us (and it makes your argument weaker that you did...).
The problem is, for every user it's a different 10%.
"stop" "STOP" “Stop” "STAHP"
These all mean different things even though it's just one language. To suggest that the way symbols are presented doesn't carry its own symbolic communication is willful ignorance at best, and at worst a kind of arrogant imposing that "my way of seeing things is the only correct way."
In a thread about the "bits of information transfer successfully encoded by AI on a UI implementation," I would expect an experienced engineer to notice the bandwidth of communication (or lack thereof) being demonstrated.
This low-entropy, repetitive coding is not limited to the user interfaces. We do tend to describe the same structures and logic over and over again in front-ends, backends, and databases.
I am currently building an open-source project that tries to make the definition of applications from database structure to business logic to user interfaces, much more declarative and compact. If you are interested, you can try it on https://sql.ophir.dev
I usually see this in places/cultures that value code-beautification projects rather than delivering value to the customer. Sometimes, they even want to do the latter, but actually do the former.
If you work somewhere that focuses on delivering value, the devs constantly complain about technical debt that will never, ever get fixed. That's the only sucky part.
The problem is, of course, that simplicity follows complexity, not the other way around. Because of that, it's mostly "trivial" and "repetitive" tasks that receive polished tools for easy and compact expression. Anything new and non-trivial usually grows ugly and uncouth for quite some time.
Usually simple, lean, and logical is also beautiful; beauty is not a random quality. But sometimes too simple and too lean is not flexible enough; then that's a case of a wrong abstraction, or of premature optimization.
Stanley worked for a company in a big building where he was Employee #427.
Employee #427's job was simple: he sat at his desk in Room 427 and he pushed buttons on a keyboard.
Orders came to him through a monitor on his desk telling him what buttons to push, how long to push them, and in what order.
This is what Employee #427 did every day of every month of every year, and although others may have considered it soul rending,
Stanley relished every moment that the orders came in, as though he had been made exactly for this job.
https://thestanleyparable.fandom.com/wiki/Dialogue#Introduct...
Even just the free demo! The demo is incredible as a standalone experience, and does not have identical dialogue / experience as the full game. It is in fact a meta-experience of the game.
Value, or short-term value? When the codebase gets hard to manage, the value is there.
Cheers and good luck!!!
Which browser/device are you using, and from where ?
The worst I'm able to get when manually disabling the cache and simulating a slow 3G connection is this: a blank page first, then text in the browser's font, then the text re-renders with the right font, then the icons load. The user should never see completely unstyled content.
The site uses "font-display: fallback" so this happens only on slow network connections. If the font loads fast enough, then the fallback never appears.
You can probably just use the system font for the title, and nobody would ever notice the issue.
The strange thing is that on HN, the limits of these approaches re: extensibility and maintenance are easily recognized when talking about traditional no-code platforms. But somehow with AI, these problems are now fixed, and we wont have to worry about unspooling spaghetti spat out from a black box.
In the best of all possible worlds, you'd have to deal with the C++ or JavaScript code about as often you have to dig into the x86 or ARM assembly code now.
In your scenario, AI will likely produce code that _it_ determines to be maintainable, or if it’s rebuilt each time as you suggest, then it doesn’t need to be maintainable or readable at all.
Good code is written for teams, not individuals. It’s written for future you and future people who you will never meet.
The most popular programming language in 2030 -- 2035 at the latest -- will be English. Few people will GAF whether the underlying generated code is readable or styled for human understanding, any more than they care about the compiler's machine language today. Some will, of course, but it'll be a rarefied, specialized career practiced only by gurus on mountaintops, as assembly programming is now.
The only tool I can say I'm reliably using is Copilot context aware completions work very nicely and it's easy to get used to when it will be usefull and when it wont so it improves productivity.
Copilot chat interface is terrible - I gues it tries to be stingy about the context tokens it's always so much hassle to get it to do anything useful - takes more explaining than doing a google search and read.
ChatGPT is hallucinating so much, mostly in times you want it to hallucinate the least.
I've tried using Midjurney and DALLE to generate placeholder art and memes - it's worse than ChatGPT.
I've built stuff on top of the API and it's very inconsistent and falls apart at totally random unexpected places (not to mention undeterministic).
I want these tools to work, but they are just so inconsistent and introduce so strange failure cases I'm not used to that it's just more trouble than worth over existing workflows.
But there are some times, where something is behaving very strangely, and ChatGPT helps me work through it. Examples are complex SQL queries, quickly combining existing queries, oddities in CSS, etc..
It may not give super-accurate answers, but at least it gives something that I can work with or work on.
I think this makes it a valuable tool, but it's not going to replace developers. Well, sure. Some people will just use ChatGPT rather than hire a programmer - I've worked with business owners who learned to code rather than hire programmers. I don't expect different results in either of these cases, the code will be very flawed, have huge security issues, and not be maintainable.
https://news.ycombinator.com/item?id=22399357
GPT 3.5 should be able to handle this functionality easily on the basis of these demos yet a full-fledged product that does this has yet to make an appearance. Squarespace, Wordpress page builders should be all over this, yet they're not. Neither are any "disruptors" like Webflow. Maybe they know something that Hello World prototyper does not?
If those old goalposts actually helped solve engineering and product needs then there would be huge praise for the achievements.
This extends far beyond just developers. This is a majority of all office work, from data entry to accounting to creative work. Most office work is just doing the same thing over and over again, often times with different people repeating what are essentially the same tasks, just at different companies.
Perhaps to start with, one way to have vastly more creativity/diversity of things people do is to have vastly fewer humans on earth.
I know this isn’t quite a widget, but when something as simple as input type=“number” was introduced, I was excited because it could be used to call up the mobile keyboard for numeric input. (Say for a zip code, which is a common use case). But unfortunately, it can also be changed via your mouse’s scroll wheel, accidentally, so I’m stuck using input type=“tel” for everything. (Do you want to scroll to your zip code?)
The problem with these things is you can’t just push out improvements and fixes. Everything has to be backwards-compatible and I feel like they’re never nearly good enough at the beginning.
This doesn't seem to be the case with UI toolkits. Is that because we still don't understand things well enough to design a decent foundation?
But it also doesn't help that input/output formfactors keep changing. We just about understood what did and didn't work with terminals when desktop GUIs sprung up, by the time those started maturing, we had to figure out how to adapt to PDAs and pen inputs, then came smartphones and tablets, then 3D for a while, then VR, and in parallel to that increasingly exotic "classic" form factors like folding devices with fluid screen sizes, ...
Nope. Don't let the conmen fool you that the incremental changes in HCI justify all the new coats of paint. Form and function changes are happening in parallel.
Fashion has to change, that's just the nature of fashion. Fashion will also spin yarn to justify itself. That's also just the nature of fashion. Don't get me wrong, I want all my software to be palatable to modern tastes. But entropy always increases with time.
The parts of the UI toolkits that change are the least consequential. Round or square corners, buttons, skeumorphism, etc...
Ideally it should be faster. Ideally it should be slower to draw and render it than it is to create the final result.
My controversial hot take on UI is that I don't think graphical tools like Figma encourage good UX habits. Unless you're doing something really creative, (opinion me) you will get better results if your UI starts in a text editor. You want a slider? What you want is:
<input type="range" id="volume" name="volume" min="0" max="11" />
<!-- And then you get more boilerplate double-binding the input and wiring it up to whatever component it controls -->
Volume (0-11 slider) => Music Volume
And we say that this kind of boilerplate should be eliminated rather than plugged into an AI, what we're talking about is trying to get rid of the stuff that makes people feel like "well, I just need to draw my interface, it's too much work writing it out or programming it." Because web authorship isn't actually there yet, it isn't efficient and easy to do this boilerplate from scratch.
But in a way, visual representations of high-level behavior are themselves an inefficient way to describe behavior. It's lossy, it doesn't always represent multiple states well, people forget to handle other setups or states. You need to draw boxes and move them around and if you want to reposition anything you have to move everything else around it? Nah, it's a slider from 0-11, it should be double-bound to some kind of variable. And I don't want to think about boxes, I want to think about what the control is and what it does. When I start building UIs, the first thing I do is I make a markdown list that just lists the controls. I don't start by drawing.
This is viewed as a kind of programmer-centric way of thinking about design, but I don't think it is, I think it results in better designs across the board. Drawing shapes should be a step that comes much later in the design process. It should happen, you want to do these kinds of visual tweaks to make sure things line up well and to think about presentation, the same way you want to do a visual pass when typesetting a book. It's not that it's not important, butthe visual position of every element is not the part of the design that's most difficult, figuring out what to show the user and when and how to represent it is the difficult part. And in the same way that you wouldn't write a book and start out thinking about the page breaks, it doesn't make sense to think about the positioning of every control before you've figured out what your controls even are.
It's kind of a failure of modern UI/UX toolkits that people are so hungry for visual design. It's backwards, we treat the behavior of controls as an implementation detail and the positioning of controls as the primary design step. It's the opposite, how a control behaves is important, and how it looks is an implementation detail that we may need to change or polish in the future depending on whether our current app-wide default styles work well for the control or not. But that's because people are so used to feeling disconnected from the implementation and are so used to the implementation being a repetitive chore.
This is even more automation of drudgery and easy repetitive work.