It's popular to apply AI to healthcare, transportation and legal work. However, these fields are heavily regulated, require domain expertise and data is hard to get. The nature of front-end dev and other digital skills make them more ripe for automation. I'm surprised there is so little progress in this area.
I agree, researchers tend to focus on more academic problems and industry goes where the money is, leaving some areas without innovation. I’ve come across few papers that cover frond-end development.
In the short-term, this approach will struggle to compete against WYSIWYG editors. But as soon as they can match them in output, they’ll improve exponentially faster. WYSIWYG editors has a ton of code to maintain, while a model is simple to improve.
I am not a huge fan of front-end dev, so I am really excited about the great opportunities behind this work/research. It will be another major step in the democratization of UI and less work at maintaining the web views.
My biggest concern is the model capacity. My question is: in your opinion, will it be able to handle very long HTML page? not to mention when it will be added a lot of CSS or JS. Even with more layers, will the model be able to generate corrected syntax(for really long pages)? will it need some additional modules(not only layers) to handle this? maybe a different problem formulation?
The model uses 48 tokens at a time to make the next prediction. As long as it can keep track of where it is on the design image, it’s not a problem. In the final version, it has roughly the same accuracy (~97%) on short and long websites.
The tougher part is integrating JS or adding hover effects in CSS. In theory, this can be done with an attention layer, but I haven’t seen any papers on it.
If the goal is to recreate the layout of a site then the context text isn't really important. You could represent each letter with a filler character e.g. . Then, you only need as many tokens as you have words with distinct numbers of characters. This approach (similar to how we use lorem ipsum for prototyping) would dramatically reduce the complexity of the model.
Why wouldn't you be able to train it to recognize expected behavior from a mockup? You could easily create a nomenclature of symbols to define standard behavior (⇑ could mean draggable upload for example). Even if you can get it to take you 80%, that would be huge.
Many years ago, I was neck deep in frontend coding. I got so good that when given a mockup, I could code the skeleton of the page "blind" without viewing it in the browser. I would load the page at the end and grade myself on how accurate I was. I've always wanted to do a contest with other frontend coders to see who could get closest to a complex layout—like the NYTimes—in one go.
One day, this type of skill will become a curiosity—a relic of the past similar to horseback riding. I would be happy to see the automation of pure translation of boxes into code.
Sorry if this is OT, but these types of contests exist! I went to one of these[1] maybe two years ago in Stockholm and I had a blast. I think the format was 32 people competing, 8 on stage at a time being shown a design which they had 15 minutes to mimic without previewing, then the crowd voted for winners using their smartphones. Two winners from each group of 8 went on to the finals. The competitors screens were mirrored on screens facing the crowd, so everyone could see how people tackled the problem in real-time. One guy did an ASCII representation of the design, which the crowd enjoyed enough to send him to the finals.
A large audience, smoke machine and lots of lasers, hard techno, and free beer. They did an amazing job setting the mood. They even have their own IDE[2] that everyone competing is required to use (with combo-counter and cool rave-y visual effects).
Definitely not deriding horseback riding (no pun intended). Humans will always do things for pleasure that they used to do purely for practical reasons. Just look at the mere act of jogging.
But, one thing I know that I'll never do for fun is debugging IE6 browser compatibility issues. I'll never get that part of my brain back again.
Many people still enjoy horses without using them as primary transport. I reckon it will be the same with ICE cars - various people with the money and inclination will still enjoy classic cars even when their daily driver is electric.
I can't find it, but there is a contest where people are challenged to re-create a mockup in front of a live audience, without seeing a browser until they are finished. I'd also like to do that :)
From reading the comments, it looks like a lot of people are bored of mundane web design. I'm right there with you. Give me something interesting to do!
You didn't turn anything into "code", you converted an image to markup; you've just "described" the image. This doesn't work for any sort of web app. A flat image from a designer does not convey enough information to build a proper interface. What of responsiveness? Or hooking it up to an API? Or accessibility? Or animations?
I would agree. However, most websites start out as such a design image. Getting the markup for the design, and adding onto the generated html/css template could speed things up.
-edit
Also who is to say that it will not be able to do more in the future. More features could be added.
Markup is more than how it looks like. Some times a <p> tag should actually be a <span> or a <div>. Sometimes a button should be an <a> tag, sometimes it should be a <button>. I wouldn't use the <article> tag if the content wasn't standalone (a blog post, newspaper article, etc.).
You need to understand what has been designed and the goals of the project to know which tags to use. I need to actually read the content to know if I should use <article> or <section>. There's not much time saved if I have to go back and readjust everything, I may as well have written it the way I wanted it in the first place.
It won't be able to do more in the future, computers can't understand things.
Do humans understand things, or does our inner voice merely tell us we do? Without more concrete answers to some very vague/often infuriating questions, it's a very bold and unsupported position to suggest that computers cannot understand something.
To me, it's still up in the air whether we understand things, or if we're just applying a lot of simple, low level, information processing networks. Recognizing objects in vision, for example, turns out to be a serious of clever organizational and optimization tricks around simple mathematics.
That's a fair point! Part of understanding something is being able to explain it in different terms. We tend to create metaphors to display our understanding of things. Merely rearranging the words in a sentence does not mean you understand it, my grade school teacher would dock me marks for that.
So in order for a computer to understand something, it has to also understand something else, otherwise it can only regurgitate back what you've given it. If I tell a computer "there is snow covering a hill" and it responds "a hill is covered in snow" I am not sure it really understand what I said. But if it responds "snow blankets the hill"... Ohh! Now it understands!
This begs the question, what was the first thing we understood? I don't know! Maybe we're born with a certain level of understanding? Maybe our biology imparts a baseline understanding-of-things? If that's the case, then computers can never understand something; they have nothing to build off of, only what we tell it to regurgitate.
Assuming we can't structure a computer with your hypothetical required base-line. Then it may be impossible, but if our understanding is a physical process that means we should be able construct an other physical entity with your required base-line. I don't see any reason to think we have some unreplicable physical process. Perhaps complicated, but that's anything but unreplicable.
So, if I understand you correctly, being able to generate context-aware comparisons from similar knowledge is understanding? (I promise I'm not trying to trap you -- I think this is interesting and would like to explore more.)
What do you think about the classic example from computational linguistics[0]? Is that approaching understanding?
That seems like a neat trick, not actual comprehension, but I don't know why.
What's the benefit to all these different tag types that have identical appearance and behavior? I remember the selling point was that they would be "semantic" and somehow used by software to add richness (I guess this would mostly be for search engines?). Is this actually happening? If the web had gone differently and styling was done completely by browsers, maybe these tag types would be more useful, but that's not the way things are.
As it concerns my role, accessibility is the main benefit. They do not have identical behaviour.
A <p> tag will be read out by a screen reader as "paragraph", but a div tag will not read out anything but the text inside. I only use a <p> tag if I want my accessible users to know that this is a paragraph (of a larger body of text).
I suppose you could make similar arguments for the other semantic tags. You use them when the content explicitly matches the intent of the tag so that other software can pick up and read it with a bit of... ahem understanding.
It's just the loud title. Generated templates are consist from ready components in examples. It's quite simple to do with minimum knowledge about code and usually useless, because people need more from interface
While cool I am not sure if this is genuinely useful. I can now take my design and convert it to HTML- now what?
I still have to integrate my api, handle responsiveness, add JavaScript and other animations/actions etc. So I’ll probably end up rewriting most of it anyway.
What I actually get out of this is not much better than emebedding the original image in an img tag, in fact it might be worse, because it creates technical debt that I now have to maintain.
I agree, and honestly, I think trying to solve this via deep learning is not the optimal approach. Too many details to handle besides a static layout, which are the hardest part.
I believe it would be a lot more effective if designers used tools that generated clean code directly, instead of Photoshop. If it's a SPA, then something with the actual, integrated React/Vue components for consistency and reuse.
While I'm not familiar with any such tool that's actually good enough for professional use (most WYSIWYG designers for the web I tried were terrible), I wonder why we haven't seen much success in this area yet, as we have with desktop app design since VB6.
I think the potential is in converting images (sketches) into ux source files that you can edit immediately and then convert those to HTML, PDF, DOCS, etc.
I can see that the HTML would more likely used for a clickable prototype than the real thing, but it could still be a neat way to save some time.
I'm working on a (text-command) ux tool and have been thinking about such a machine learned import feature, but lack those skills and time at the moment to build it.
Cool work! I'm very interested in this topic. Just wondering, how good does it generalize your training data other than just remembering strict input-output mapping?
The bootstrap version generalizes with 97% accuracy on a new image. Because the vocabulary is limited, you can train the model overnight. To make the model generalize with all the HTML/CSS markup you need significantly more compute.
This is a cool idea. I think this technology could potentially assist front-end developers and the designers who work with them even though there's still a fair amount of craft involved. Browser compatibility has gotten better on the desktop in recent years but the mobile appearance of websites is as diverse as ever. It might be interesting to explore "mobile-first" or "progressive enhancement" applications of this technology.
Did you see any of the output source? I wonder if it's clean enough to be understood by humans, or if it's one of those situations where it's been optimized to work but not be understood.
Then again, if you used some additional inputs like "readable code", it theoretically could optimize both the resulting application and the source code.
Yeah I believe it's about 2/3rds down the page under the heading "Links to generated websites." It's a far cry from the old Dreamweaver days. I could see running into some complexity with CSS. Things like which units to use (em, vh/vw, %, px, rem, etc), building a readable selector hierarchy, or using newer CSS technologies like CSS grid or animations.
Another step closer to my dream: a cross-compiler that takes as input a Powerpoint presentation, and outputs the enclosed-described mobile app, cloud-hosted website/backend, and Delaware C Corporation.
Well, this seems like it could be useful for the times you just want a quick prototype mocked up and can't be bothered to code it, or when you're dealing with sites that don't need much in the way of dynamic functionality.
However, it also makes me think that:
A: Maybe developers (and software engineers in general) should stop thinking their own jobs are necessarily safe from automation, since something like this could be the first step to the field going the same way as lorry or taxi driving will in future.
B: That agencies might start seeing their basic web development work start drying up in the not too distant future.
A. No. Good developers can run up the abstraction chain to keep providing value at a higher level. Most good devs fundamental value prop isn’t “I can make something in HTML”.
If anything, this will mean that more people can do the redundant stuff faster.
As a frontend guy, I can’t wait for the day that a tool can generate presentational stuff.
I agree with your response to A in the short term. In the long term, however, much like a mountain in a flood people can only scramble so high before they run out of oxygen, or run out of room.
To take your metaphor a bit too far, it’s fortunate that we have more than one mountain. ;)
Sure, the days in which the web guy was viewed as a special guru won’t last forever. But even with auto-generated mockups, we’re still a long way from computers taking over everything.
As the baseline of tooling gets raised, the baseline of expectation gets raised.
Programmers will use these tools the way we always have: To automate the simple work on the way to building a finished product that's more complex, and done more quickly, than would have been possible previously.
Some markets die, yes. It's no longer possible to make a business out of selling Unix clones for commodity hardware, like you still could in the 1980s. It's no longer possible to make a living just making static HTML websites, like you could in the 1990s.
Ultimately, what programmers trade in is a specific kind of problem-solving design sense. Not just solving this single problem as fast as we can, but creating a more general solution, which composes well and can be understood and changed later on. Once programs can do that... well, we'd better be willing to offer them citizenship and recognize their civil rights as thinking beings.
The top of this metaphorical mountain involves learning new APIs, frameworks, languages and programming paradigms. An AI that can do that will be a threat to everyone.
> As a frontend guy, I can’t wait for the day that a tool can generate presentational stuff.
Qualified agreement from this sometimes front-end guy, but that's assuming the generated presentational stuff is of equal or higher quality as that of the other front-end devs.
Being the front-end guy who has to debug the auto-generated code that doesn't quite work in a corner case or two sounds potentially worse than the status quo.
I'd argue in part you're both right about A. Good devs (those can keep running up the abstraction chain) will always be useful. But the bar for what a "good dev" is keeps getting higher as we introduce more and more abstraction. The sheer amount of knowledge and understanding that the average dev needs in order to be productive AND understand what's going on enough under the hood (to the point where they're not doing stupid things constantly) keeps getting larger.
Think back to CS in the 70s - AFAIK, the majority of the field that was understood is now covered before an undergraduate gets to their upper division classes. We're now expected to understand things at a much higher level of abstraction, but we ALSO need to know how logic gates and machine code works in order to fully understand what we're doing.
The 'incubation period' to produce a good dev is going to keep growing. The ones that make it to full dev maturity are going to be more productive than ever before, but fewer people will make it there.
Sure, there is a divergence of skill sets...We're going to have "doctor" developers – people who carry an incredible breadth of knowledge and are paid accordingly.
Beside them will be "nurse" developers – people who are just as professional, but less learned in the full range of computer science ideas.
Whatever the "doctor" developers write to abstract away the nurses, it's still not going to be able to communicate with nontechnical managers. Or at least, once it can do that, the "doctor" developers will be obsolete soon anyway.
Though the abstract nature of the field often benefits from analogical representations, I think this one detracts. I don't see how our current hodgepodge list of role titles we've already borrowed from other fields (architect, developer, designer, scientist, ops, product manager, evangelist(?!), quality assurance, security specialist, chief information officer (not to mention wizards, code monkeys, Java baristas (aka the bespeckled missionaries (they don't C# for whatever reason) who walk through your neighborhood every once in a while to knock on doors with warm smiles hoping to share their beliefs on the one true Oracle and some bizarre philosophy of enterprise scale spiritual development involving complex and brittle structures and subservience to feudal and [frankly] regressive class structures that most favor a nepotistic inheritance procedure designed to chiefly empower their children and a small circle of similarly interested functionaries that seem hellbent on oppressing the rest of the system), unicorn jockeys, tech debt lawyers, and whatever you call that long-gone contractor who years ago thrust a bizarre moonscript backend into the core of your team's architecture like Excalibur waiting for an Arthur everyone hopes won't happen along because rock that asshole stuck the sword in happened to be the kingdom's cornerstone and even the slightest nudge will cause the whole system to precariously sway ...)) can be summarized with a doctor / nurse dichotomy.
Even if writing, practicing and administering software legally required a degree and license, I think this still detracts. Maybe useful once software powers organic, higher-order life forms, at which point I imagine our doctors and nurses will be entirely software driven anyway[0].
Agreed, but also feels like the very common mockup->developer handoff is inefficient, and in many cases should just start from a working prototype vs a drawing.
Wouldn't the agencies most affected by this type to image-to-website tech already be affected by WYSIWYG operations, (squarespace, wix, wordpress, etc.)? I am curious how many agencies are developing simple html/css enough that this type of thing would dry up work.
As far as point A: I don't know if there will ever be a "final state" of web development. For every automation fix that is introduced to the web dev space, 10 new technologies are developed that provided an added layer of complexity.
I think the web is bit different from traditional jobs being taken over by automation in that (as far as we know) there isn't a hard limit on how far we can push web technology and use. If anything, the people who would be replaced by these automation services are (presumably) the ones who would be developing the automation systems and integration to begin with.
Some of the very first programs written for computers (assemblers and compilers) were so that programmers could automate their own jobs. Nearly every advance in system software since then - recursive functions, software libraries, virtual memory, high-level languages, garbage collection, lexical closures, object-oriented programming, constructors & destructors, smart pointers, version control, package managers - has involved automating progressively higher-level tasks so that programmers can focus on new stuff.
Dreamweaver and FrontPage have existed for over 20 years. The use-case listed here isn't all that useful - if you just want a quick prototype website built from a WYSIWYG graphical editor, there are already very good tools for that, starting with the above two and going through web services like SquareSpace, Wix, and Weebly. I found the discussion of his approach fascinating, though, because it could be applied to lots of other, unsolved problems. Imagine being able to publish a website by taking a photo of a poster using your smartphone.
Probably true, but it's because their market (small businesses who just want a basic HTML-only site) has been taken over by website builders like Wix, Weebly, Wordpress, and Squarespace. Agencies & professional web developers moved up-market to the customers who require dynamic app-like behavior, which Dreamweaver and Frontpage sucked at, while the bottom end of the market moved to the aforementioned hosted services that could also run the site for them, handle maintenance, and easily integrate add-ons like email/blogs/commenting/RSS/analytics/etc.
With the advent of standardized web component libraries, design frameworks, css grids, and website builders; the task of building a simple website feels more like assembling the pieces of a puzzle. It's hard to know how long innovations in web development will outpace automation / deep learning, but it's an interesting space to follow.
Personally, I think bespoke web application development will be a strong area of innovation for many years to come as browsers and devices continue to increase in power. I'm more worried about keeping up with the fast pace of change than the entire industry drying up.
With regard to B, at least in the DC area it is all dried up and agencies are climbing the value chain in one or both directions:
- As a communications/marketing/PR agency who provides the website as a component of a larger campaign. Many of these folks are already using platforms like Wix, Squarespace, etc., or Wordpress with purchased templates.
- Doing more complex site development that requires a lot of IA work and institutional change management. For example: migrating ancient federal HTML websites (yes some still exist) to Drupal.
Damn, it's almost like developers are going to need to learn to focus on using code to solve business problems, rather than just focusing on being able to write code and calling it a day. XD
Drawing a website can be much harder than just coding it up, especially if lots of repetition is involved. This is a nice trick, but, given the fixed vocabulary, isn't really that useful to non coders (who could accomplish faster results with drag and drop under similar restrictions).
> A: Maybe developers (and software engineers in general) should stop thinking their own jobs are necessarily safe from automation, since something like this could be the first step to the field going the same way as lorry or taxi driving will in future.
I've seen hundreds of products to automate this kind of tasks and all of them failed one by one. The simple answer is that if you would have a software which could replace code, it would have a learning curve as complex as learning to code ans so being then worthless to learn.
This is, approximately speaking, useless. Which is not to say it shouldn't have been done; you have to make a lot of useless prototypes with any new technology before you can actually make something useful. So long as one considers it in this light, it's cool. Just don't get too excited about not having to do this work yourself (if you need it done) for at least the next several years (perhaps decades).
118 comments
[ 103 ms ] story [ 2736 ms ] threadIt's popular to apply AI to healthcare, transportation and legal work. However, these fields are heavily regulated, require domain expertise and data is hard to get. The nature of front-end dev and other digital skills make them more ripe for automation. I'm surprised there is so little progress in this area.
I am not a huge fan of front-end dev, so I am really excited about the great opportunities behind this work/research. It will be another major step in the democratization of UI and less work at maintaining the web views.
My biggest concern is the model capacity. My question is: in your opinion, will it be able to handle very long HTML page? not to mention when it will be added a lot of CSS or JS. Even with more layers, will the model be able to generate corrected syntax(for really long pages)? will it need some additional modules(not only layers) to handle this? maybe a different problem formulation?
The tougher part is integrating JS or adding hover effects in CSS. In theory, this can be done with an attention layer, but I haven’t seen any papers on it.
Super awesome!
Many years ago, I was neck deep in frontend coding. I got so good that when given a mockup, I could code the skeleton of the page "blind" without viewing it in the browser. I would load the page at the end and grade myself on how accurate I was. I've always wanted to do a contest with other frontend coders to see who could get closest to a complex layout—like the NYTimes—in one go.
One day, this type of skill will become a curiosity—a relic of the past similar to horseback riding. I would be happy to see the automation of pure translation of boxes into code.
A large audience, smoke machine and lots of lasers, hard techno, and free beer. They did an amazing job setting the mood. They even have their own IDE[2] that everyone competing is required to use (with combo-counter and cool rave-y visual effects).
[1] http://codeinthedark.com/
[2] https://github.com/codeinthedark/editor
But, one thing I know that I'll never do for fun is debugging IE6 browser compatibility issues. I'll never get that part of my brain back again.
edit: someone else found it!
-edit Also who is to say that it will not be able to do more in the future. More features could be added.
You need to understand what has been designed and the goals of the project to know which tags to use. I need to actually read the content to know if I should use <article> or <section>. There's not much time saved if I have to go back and readjust everything, I may as well have written it the way I wanted it in the first place.
It won't be able to do more in the future, computers can't understand things.
To me, it's still up in the air whether we understand things, or if we're just applying a lot of simple, low level, information processing networks. Recognizing objects in vision, for example, turns out to be a serious of clever organizational and optimization tricks around simple mathematics.
So in order for a computer to understand something, it has to also understand something else, otherwise it can only regurgitate back what you've given it. If I tell a computer "there is snow covering a hill" and it responds "a hill is covered in snow" I am not sure it really understand what I said. But if it responds "snow blankets the hill"... Ohh! Now it understands!
This begs the question, what was the first thing we understood? I don't know! Maybe we're born with a certain level of understanding? Maybe our biology imparts a baseline understanding-of-things? If that's the case, then computers can never understand something; they have nothing to build off of, only what we tell it to regurgitate.
What do you think about the classic example from computational linguistics[0]? Is that approaching understanding?
That seems like a neat trick, not actual comprehension, but I don't know why.
[0] King + Women = Queen, see https://cacm.acm.org/news/192212-king-man-woman-queen-the-ma...
A <p> tag will be read out by a screen reader as "paragraph", but a div tag will not read out anything but the text inside. I only use a <p> tag if I want my accessible users to know that this is a paragraph (of a larger body of text).
I suppose you could make similar arguments for the other semantic tags. You use them when the content explicitly matches the intent of the tag so that other software can pick up and read it with a bit of... ahem understanding.
However, it's an interesting technical problem to adjust the code. Does anyone have a rough idea how to implement it?
I still have to integrate my api, handle responsiveness, add JavaScript and other animations/actions etc. So I’ll probably end up rewriting most of it anyway.
What I actually get out of this is not much better than emebedding the original image in an img tag, in fact it might be worse, because it creates technical debt that I now have to maintain.
I believe it would be a lot more effective if designers used tools that generated clean code directly, instead of Photoshop. If it's a SPA, then something with the actual, integrated React/Vue components for consistency and reuse.
While I'm not familiar with any such tool that's actually good enough for professional use (most WYSIWYG designers for the web I tried were terrible), I wonder why we haven't seen much success in this area yet, as we have with desktop app design since VB6.
Then again, if you used some additional inputs like "readable code", it theoretically could optimize both the resulting application and the source code.
However, it also makes me think that:
A: Maybe developers (and software engineers in general) should stop thinking their own jobs are necessarily safe from automation, since something like this could be the first step to the field going the same way as lorry or taxi driving will in future.
B: That agencies might start seeing their basic web development work start drying up in the not too distant future.
A. No. Good developers can run up the abstraction chain to keep providing value at a higher level. Most good devs fundamental value prop isn’t “I can make something in HTML”.
If anything, this will mean that more people can do the redundant stuff faster.
As a frontend guy, I can’t wait for the day that a tool can generate presentational stuff.
Sure, the days in which the web guy was viewed as a special guru won’t last forever. But even with auto-generated mockups, we’re still a long way from computers taking over everything.
Programmers will use these tools the way we always have: To automate the simple work on the way to building a finished product that's more complex, and done more quickly, than would have been possible previously.
Some markets die, yes. It's no longer possible to make a business out of selling Unix clones for commodity hardware, like you still could in the 1980s. It's no longer possible to make a living just making static HTML websites, like you could in the 1990s.
Ultimately, what programmers trade in is a specific kind of problem-solving design sense. Not just solving this single problem as fast as we can, but creating a more general solution, which composes well and can be understood and changed later on. Once programs can do that... well, we'd better be willing to offer them citizenship and recognize their civil rights as thinking beings.
Qualified agreement from this sometimes front-end guy, but that's assuming the generated presentational stuff is of equal or higher quality as that of the other front-end devs.
Being the front-end guy who has to debug the auto-generated code that doesn't quite work in a corner case or two sounds potentially worse than the status quo.
Squarespace is simultaneously worse than what _any-decent-designer_ would put together AND better than an average marketing website.
Think back to CS in the 70s - AFAIK, the majority of the field that was understood is now covered before an undergraduate gets to their upper division classes. We're now expected to understand things at a much higher level of abstraction, but we ALSO need to know how logic gates and machine code works in order to fully understand what we're doing.
The 'incubation period' to produce a good dev is going to keep growing. The ones that make it to full dev maturity are going to be more productive than ever before, but fewer people will make it there.
Beside them will be "nurse" developers – people who are just as professional, but less learned in the full range of computer science ideas.
Doctor is a long-running process that requires a callback from nurse.
Even if writing, practicing and administering software legally required a degree and license, I think this still detracts. Maybe useful once software powers organic, higher-order life forms, at which point I imagine our doctors and nurses will be entirely software driven anyway[0].
[0] http://memory-alpha.wikia.com/wiki/Emergency_Medical_Hologra...
Hopefully the sword will be more Excalibur and less Sword of Damocles.
^^ I have no idea what that means, but it seemed relevant. :)
Wouldn't the agencies most affected by this type to image-to-website tech already be affected by WYSIWYG operations, (squarespace, wix, wordpress, etc.)? I am curious how many agencies are developing simple html/css enough that this type of thing would dry up work.
As far as point A: I don't know if there will ever be a "final state" of web development. For every automation fix that is introduced to the web dev space, 10 new technologies are developed that provided an added layer of complexity.
I think the web is bit different from traditional jobs being taken over by automation in that (as far as we know) there isn't a hard limit on how far we can push web technology and use. If anything, the people who would be replaced by these automation services are (presumably) the ones who would be developing the automation systems and integration to begin with.
Dreamweaver and FrontPage have existed for over 20 years. The use-case listed here isn't all that useful - if you just want a quick prototype website built from a WYSIWYG graphical editor, there are already very good tools for that, starting with the above two and going through web services like SquareSpace, Wix, and Weebly. I found the discussion of his approach fascinating, though, because it could be applied to lots of other, unsolved problems. Imagine being able to publish a website by taking a photo of a poster using your smartphone.
Personally, I think bespoke web application development will be a strong area of innovation for many years to come as browsers and devices continue to increase in power. I'm more worried about keeping up with the fast pace of change than the entire industry drying up.
- As a communications/marketing/PR agency who provides the website as a component of a larger campaign. Many of these folks are already using platforms like Wix, Squarespace, etc., or Wordpress with purchased templates.
- Doing more complex site development that requires a lot of IA work and institutional change management. For example: migrating ancient federal HTML websites (yes some still exist) to Drupal.
I've seen hundreds of products to automate this kind of tasks and all of them failed one by one. The simple answer is that if you would have a software which could replace code, it would have a learning curve as complex as learning to code ans so being then worthless to learn.
Actually, it's poorly though-out web technologies that don't allow for reasonable WYSIWYG editing.