I feel old now. I'm fairly sure that we could do this almost as fast with VB or Delphi a couple of decades ago, but a little more deterministic results instead of having the tool inferring it from the label names. We had this and then we shoved everything in the browser and forgot that we could do this without using huge amount of compute of some generative AI model.
I have kind of the same opinion. Maybe more provocative. When people show me figma to HTML with AI I tell them “have you ever heard of Dreamweaver?”
Ok, dreamweaver code was ugly and unusable when AI generated code is not too bad (sometimes). But still, I also feel we kinda were already close to where we’re at today.
Not sure about Dreamweaver, but the fact that no Frontpage equivalent exists this day and age, and armies of developers are grappling with HTML, React and GraphQL (e.g. Gatsby) to generate what are essentially websites, is very surprising.
I used to look down on it but when I heard it handles payment it blew my mind and I decided I'd rather use it myself if I ever make a shop instead of building it myself. To quote a random guy "I trust their code more than what I wrote at 2am."
I am a SWE. When I needed a website for a small business I was running, I used squarespace too. If you just need a static public facing site it's absolutely great.
Same here. I used to scoff at their prices “I could do that for way cheaper”, and I could/can… if my time is worthless which it’s not.
Now for things that aren’t my core business (day job or side project) I’m much more likely to reach for a paid off-the-shelf solution.
After months of putting off building a marketing website for my side project I just paid for a tool to build/host it so all I had to do was plug in my info. Yes I could have hosted it for pennies on S3 with CloudFront in front of it but instead I setup a cname, paid like $20 for the year, and let this other company handle the responsive design (template) for me.
For some weird reason, "Squarespace" keeps reminding me of a ___location-based social network from the early 2000's. Did I imagine that? Or did the ___domain and trademark get bought?
There are countless of no-code tools to build landing pages, static site content.
For web apps the level of custom
logic makes it unavoible to just code. Since web developers tend to be coders they would code static sites too. And use what they are most comfortable with, usually React.
My friend works on a low code system marketed to small governments. (Basically just CRUD builder optimized for bureaucracy.) There's definitely a niche for it, it just hasn't caught on much for some reason.
Of course it exists, it’s just not produced by Microsoft and therefore relatively few people use it.
Webflow has been around for a while and I’m sure they implemented AI already (I didn’t even check). Other React-based tools surely also exist, but have an even smaller user base.
I used Dreamweaver significantly back in the day, and use Figma professionally today. I see what you're saying, but there's no question about them being equivalent in functionality, except insofar as I do not consider generated code from either of them particularly useful. In that respect they are the same, but in every other way Figma is 100 times better.
Completely agree. Was trying to find the current parallel of the design to code process. But there is no doubt dreamweaver is almost not comparable to Figma (at least the version I knew).
As others mentioned the closest descendant of dreamweaver today is most likely Webflow.
I hadn't seen that comparison, but Webflow is really cool! I had to make a company website using it a few years ago, because it needed to be maintained by people with no coding skill at all. I found it really awesome. Also, their Youtube tutorials were about the most impressive tutorials I've ever seen, so well produced and fun that I would recommend just watching them as entertainment.
Are you sure? I remember one of Dreamweaver competitive advantages was that it produced much cleaner HTML than it's competitors. FrontPage was the big offender with awful code.
To be honest I can’t remember when was the last time I used dreamweaver but it sure wasn’t towards the end of its life. So, it could very well be that it got better after my last experience. What I remember was way too many tags and almost unreadable classes or repeated styles. It was not possible to directly take over without quite some re-writing.
Toward the end of its life, Dreamweaver's code was quite readable. Webflow today is kind of an equivalent, and also puts out relatively readable HTML. I think most of the reputation comes from people looking at its early output.
I once spent a week as an intern building a really clean and well done java swing UI options panel for a portion of our team's app. I was so proud of myself and thought it was so clear and concise and great. I told my manager it was all finished.
Well, no one else on the team was that familiar with java swing so they couldn't work with it, so one of my coworkers had to spend an hour rebuilding the panel in the UI builder that the rest of the app worked in. It produced a perfectly functional UI that had all the features requested and could be maintained by anyone on the team. Sure, the raw java file was twice as long, but who cares? It gets compiled.
I was enlightened on that day. "Elegant" is worthless in most cases. Five years later that entire app was rebuilt as a web app and nobody gave a shit whether one of it's option panels was artisanally hand crafted with care and love or spit out by an actually really good and regularized UI builder.
We are data plumbers. Nobody cares if the pipes you laid out are arranged to look like the mona lisa, and it's probably worse for the customer and maintenance that way anyway.
It has nothing to do with the browser, it has to do with how opinionated your framework is.
VB was highly opinionated; it made native windows-style UIs and nothing else. Nobody was taking arbitrary mockups from designers, with a wildly custom look-and-feel, and replicating them down to the pixel in VB.
Today, most product GUIs are part of the brand. For better or worse, every company wants a distinctive look and feel and set of UI behaviors. This requires the tools used to build them to be much more complicated.
You could replicate VB in a browser. Many people have done roughly that. But nobody uses them to build products, because their company doesn't want boring/generic UIs.
I get your point, but it only applies to the most simple of these examples. This can do all kinds of stuff, for example look further into that thread and you’ll see it implementing tic tac toe. The tool works by basically sending a screenshot of your diagram to GPT4 and saying “implement this”.
Which in turn only works for simple stuff that GPT-4 can implement from a single screenshot, and is, as OP pointed out, non-deterministic. The code OP is referring to would have been written to integrate with the rest of the project, to connect to data stores and services that the screenshot has no way of knowing about. People built huge applications in VB and similar tools.
Don't get me wrong, these new tools are cool, and I imagine they'll be great for prototyping small things quickly!
Human beings build stuff non deterministically too. The key is just to give the tool more information along with the screenshot, for example showing it your current codebase so it writes code using the same conventions.
... and our opinions about how badly this is going to pan out are based on decades of experience with how badly that panned out.
Nobody that has ever had to maintain software is going to look at this and be impressed. Without a reproducible and predictable set of transforms from the source artifact to the product artifact(s), maintenance of software generated in this fashion will be impossible. The concept of a "localized" change doesn't exist; you have to assume that any and every change risks breaking the entire product.
This is, of course, just another version of folks looking at something that mimics a (structured, evolved) human activity and assuming that it is in fact reproducing that activity, rather than just copying some subset of the visible consequences of that activtiy.
I don’t know why you’d assume the AI behind this wouldn’t end up with access to both the source and product artifacts, implementing changes in the most constrained/localized way possible.
Recall that this is an LLM; it doesn't "think", it's just cutting and pasting "likely" scraps of things from its training set. At this point, the vast majority of those scraps were human-generated, so a) many of them work, and b) copying them in this fashion is plagiarism ("the offense of taking passages from another's compositions, and publishing them, either word for word or in substance, as one's own")
Once upon a time, there was a fresh new operating system, the next step, being demo'ed in the Graphics pavillion of Comdex. Some huge nerd stood there, dragging things around with a mouse, 'proving' that you didn't have to be a programmer to build applications.
A decade after that, something floated around for a year or two called Visix Vibe, which gave the same thing, but for this relatively new language (at the time), Java.
Every few years, maybe 4-5 or a decade or so, someone gets the itch to make all the complexity fade away. Eventually though, they build an OS.
You still see this using just about any major native UI toolkit. They may not be RAD-fast, but all kinds of elements and interactions that require custom and usually-janky JavaScript to implement on the Web are available “for free”. And actually work correctly, interact with the rest of the toolkit the way you’d expect, and i18n and a11y and all that work correctly and consistently.
There’s no reason HTML can’t do a lot more than it does out-of-the-box, saving crazy numbers of developer-hours and piles of user frustration every year. It just doesn’t.
I think we'd all be gladly sitting atop high abstractions like that if not for the fact that brands pay the bills, and brands want custom experiences. Website and app design often begins with "what does a button look like," and design tools focus not on prebuilt widgets but on paths and fills, because the last thing a brand wants is to speak with different tones in different media. Their software has to feel like their stores and advertisements in order to create a brand-consistent customer experience. Design systems are a hot topic today because what brands got with this design method is a different voice in each of their sites and apps, because they're all independently custom.
This is what kills Horizon Worlds, which is Facebook's earnest answer to the problem of making VR authoring much easier than "making a video game"
I want to make a 3-d world based on photographs (even stereo) and visual art and to do that I need to import JPG or PNG images. No can do. They have a short list of textures they supply, but you cannot import media assets like images, audio, video, geometry, point clouds, whatever, ...
McDonald's would insist on putting a Coca-Cola logo on the cups and so would every other brand.
> Website and app design often begins with "what does a button look like,"
Yup. Been a long time since I've used an un-customised standard button outside my personal projects, no matter how much R&D has been spent by Apple on working out what it means for a UI to be good.
There was a reason why we moved away from this. Everything is code, the UIs for creating such interfaces are just abstractions. The code generated by those no-code approaches to interface design was horrible and would break down quite fast in larger projects. Maintainability for such interfaces was non-existent.
I think just regretting an old feature long gone without proper context is dangerous. If we are to bring back those approaches we have to keep in mind exactly why they went away in the first place.
> Everything is code, the UIs for creating such interfaces are just abstractions. The code generated by those no-code approaches to interface design...
I'm not sure you're replying to the same thing. I never used VB much, but Delphi was not and is not no-code. In fact it emphasised using libraries a lot ('components' in its terms are classes provided by libraries) and the UI had a text description, which was streamed and created at runtime.
Delphi today could indeed create something doing this just as fast, and you wouldn't draw a trackbar and hope it's recognised in the image by the AI... you'd drop an actual trackbar.
Delphi's visual editor allows you to position, link together and configure visual and non-visual components in design time, automatically serializes all the components into text file and in runtime your program deserializes these components from the resource embedded in the program's binary file. It also allows you to create handlers for events like OnButtonClicked or OnDBConnectionOpened where the usual arbitrarily complex programming happens.
There are still tools to do it. I think the reason they are not more popular with programmers is that it's basically some stupid subconscious thing where we are afraid of being accused of being users or beginners. Not something we realize consciously, but anything that doesn't involve complex colorful text naturally gets kind of peer pressured out because it looks like a "beginner tool".
You are missing a huge caveat of those tools. They tend to have limits in functionality.
It isn't uncommon that you prototype with a tool and it is super fast but before you can launch for real you need to rewrite everything.
At that point it is difficult to know if the prototype was valuable. Certainly quickly visualizing is good but a prototype tool that is non functional is even faster to use.
Having a tool that allows easy drag and drop without any friction on the generated code (including difficulty of using that code) while also having all the powers of HTML would be really cool.
Such a tool wouldn't be a beginner tool but any that fail this and can't really go all the way to final product gets discarded as "I am going to have to rewrite anyway".
Less of a "I am too good for that" more a "not a useful abstractions level" when considered holistically.
That's a good rationalization for doing everything manually, but I don't believe it really holds up. I think it comes down to some social psychological effects that as I said are subconscious. So people don't realize it's effecting their decision making.
When they decide not to use those tools they will use rationales like you said rather than admitting that they felt peer pressure.
Some people want to be good software developers, not just good website builders.
If you want to use low code website builders, feel free. If that suits your work style and the projects you're building, great.
But you will never develop the skills you need to actually build software. A person who spends their life using website builders instead of writing software will never be able to build their own website builder, for example.
Some of us actually like to have the skills to build the tools ourselves.
If you want to call that peer pressure, then sure. It's peer pressure to elevate your own experience and attain mastery, instead of settling for only ever using tools that other people built for you.
You have perfectly illustrated the peer pressure I am talking about.
By the way, I have been programming for 38 years on many platforms and have built my own drag and drop UI editors and frameworks. I don't use these types of tools today because they are not popular and because of psychological factors as I said. But I still think that it would be more logical if programmers used them more often. And the times that I used them in the past they did increase my productivity.
The types of tools I am talking about often require editing code to customize functionality. They are not no-code tools.
If you hire an architect to design a house, then make some adjustments to the blueprint before it gets built, it doesn't make you an architect. In fact if you give your adjusted design to builders and have it made without consulting an architect first, you have a good chance of unknowingly violating some building code somewhere.
Similarly if you use a code generating tool written by a software engineer and then adjust the code output, it doesn't make you a software engineer.
Yes, software engineers can use those tools, but they're limiting their growth as engineers if they rely too heavily on those tools.
If that's peer pressure, then I am unapologetic about it. I'm not hiring people who can't build their own code to work as software engineers.
Sadly I, like all programmers, have been peer pressured or something into avoiding tools like that. But I know they exist. I also made one several years ago. (No one was interested).
But I think if you search for "RAD" or "Rapid Application Development" or graphical component based development may get quite a lot.
I think that there are several plugins for WordPress that have similar functionality, although less code integration.
When we went to the browser we took 30 years of UI development knowledge and UI/UX principle and flushed it down the toilet.
Only very recently have we started to gain composability in browser UIs through things like React, and it's a sad facsimile of the widget composability we had in WYSIWYG UI development on PCs in the late 1980s and early 1990s.
The web is a shit UI platform, but that's because it wasn't designed to be one. UIs were shoehorned into a hypertext system designed for viewing documents.
The web is a much better UI platform than what's available in linux desktop and whatever took 30 years of UX development in Linux wasn't flushed down the toilet (emacs, vi, GNU, ...). MS Windows users miss their Delphi/VB software.
Keep in mind this could equally be a picture of a napkin.
Ignoring that though, I t’s fair to make this point for the current level of capabilities, but look at the trajectory… in a year or two when the training set has lots of examples of people using this, it should be pretty competitive.
I think this is kind of missing the point. The fact that the underlying implementation is not a hand-coded-deterministic one is the interesting thing about this demo. This is clearly going to be useful by making people more efficient and only going to get better with time.
Now, instead of looking in some cryptic symbols which you don't understand, you just mash "regenerate" button until it works. Can anything be more simple? Of course, with newer models you need to hit that button even less, it's progress, isn't it?
My laptop from multiple years ago (6GB VRAM) can run local models with decent performance. It's my understanding that the major energy cost is from training the models, which you do somewhat infrequently, and that generation isn't nearly as costly.
Someone who knows more, please correct me if I'm wrong!
HN has this weird nostalgic thing for VB and Delphi, but I feel that most people who express it either haven't actually used these tools or don't remember it well. There's no way to do responsive interfaces with it. If you want anything but your OSes native controls, you're in the world of hell too. Even localisation is a problem. No unit, no integration tests. WYSIWYG editors mean that form files are changed automatically and it's often not realistic to review the diffs. And the languages itself — while being adequate for their time, they're don't even have support for functions as first-class objects, so compared to modern alternatives they're almost unusable and require enormous amount of boilerplate.
Oh sweet summer child. (if you are going to call us weirdly nostalgic)
There were ton's of methods - from extremely manual code-based detection of window resizing events, then subsequent calculating and scaling contained controls, to a myriad of third-party libraries/components that would provide an automatic resizable host container for other controls.
Localization was not a problem - VB6 supported 'resource files' like every other Win32 app. Unit and integration tests were possible - but uglier with visual forms - typically requiring third-party products, and/or low-level Win32-API integrations. But in reality - you would abstract all of your business logic into classes/modules/units with very little within the UI, so that those would be unit-tested, instead of the UI.
Now - don't get me wrong, VB was limited in many many ways, and I am not nostalgic for it - but, it was more capable than the picture you are painting. Delphi even moreso, as it had easy and direct access to the entire Win32 API and could handle threading and pointers as well.
Look at me I'm old yelling at clouds!