Nice extension, it may be worth in the readme explaining how it’s different to https://github.com/microsoft/vscode-livepreview which has been around for a long time and maintained by Microsoft.
Many of Microsoft's extensions are closed source. This one does not appear to be, but MS has been known to replace open source VS Code extensions with closed source ones in the past.
The terminal is iTerm2, but the basic Mac terminal or common Linux ones can do opacity too. Didn't go out of my way to set up auto-reload, so idk how to do it in general, but the default create-react-app dev setup does it.
I was expecting something more like WYSIWYG editor, that actually edits HTML visually in real-time. Something akin to old times of first webpage editors.
Are we trying to reinvent web development? Last few years have been wild. We abandoned HTML CSS and JS websites that used to work just fine and ran after frontend component frameworks and now the circle is getting completed by building tools and extensions we had 20 yrs ago
Oh I think it is very much "just fine", but people have requirements which make things too complicated. I find it way harder to work in a React app than a few .html and .js files. TypeScript's cool though.
Most people working professionally as web developers have limited ability to reduce the requirements and have to implement what their company ask for. At that point having something to manage the complexity is much better than not.
Bullshit. jQuery as a library didn't inherently cause spaghetti code, it was predominantly just used as a cross-browser selector function and some standard library augmentation/fixes before JS itself caught up. Sprinkles of progressive enhancement jQuery were exactly the problem that caused frameworks to be created. Sprinkles of vanilla JS lead to the exact same outcome, minus a jQuery library load.
No amount of discipline was going to make medium-large websites maintainable back then. Today it's actually possible if the creators know what they're doing. Tooling isn't going to prevent people from doing stupid things.
I agree with HTML+CSS+JS websites being not fine. But to be honest, js callbacks are more of a language thing than a framework thing. You don't need to use frameworks to write promises.
You can't reuse pieces of UI functionality (a bundle of specific html, css and js) unless did copypasta which is obviously awful. Sharing business logic across different areas of an application becomes much harder and you can't non-trivially write and run tests across areas of your application because you are just using html,css and js. And the big monster: state. Sharing state safely across different areas of an application becomes much harder. You end up writing your own micro framework trying to make all the above work. At that point you might as well use as existing battle-tested one
This. A not so great analogy is you can always drop a single php file into your /var/www/ (or even do cgi) and get your "dynamic" website running like decades ago, but people don't do that any more for any website that is not a tiny one with just a few pages (barring famous exceptions like WordPress). People realize there are good reasons to use frameworks, and often, use other languages for website backend.
Let's be honest. Those old HTML+CSS+JS didn't have the interaction levels of modern applications. And jQuery was great until you reached a level of complexity after which it became jquery Bolognese. There are 2 main challenges: state and reusing pieces of html. Both of these are much harder in modern applications due to their complexity. Try reusing a piece of HTML using HTML+CSS+JS alone (no Node or back-end tools allowed). Try keeping state synced across a modern application without using state management libraries.
Most "applications" I visit in my browser have no business being an application. The "clear search history" button in my start menu has no business loading a React environment with three redirects either.
Some web applications need a boatload of frontend stuff to make them usable, but I rarely encounter websites that warrant such overkill. A payslip/email subscription/car rental website with a profile page and maybe three forms I can possibly need to submit doesn't need to be a fully interactive application with loading bars and offline support, leave that stuff for the websites I visit more than once a month.
At this point React/Vue/Svelte devs are probably cheaper to hire than basic JS devs, but technology wise the amount of Javascript my browser needs to load for the most basic interactions is mind-boggling. More than the "this meeting could've been an email" meetings, I run into "this web application could've been a POST request" web pages.
There are complex reasons behind my development of this. To be honest, I don’t think the editing functionality of this tool is particularly useful. I believe the real-time preview and element selection features are the ones that offer broader utility. I am considering making the editing feature disabled by default and allowing it to be enabled through settings in the future.
I don’t think it was meant to criticize your work :)
It’s just fun to see that we (here : you) are reinventing tools that everyone used 20 or 30 years ago.
I remember making my first websites in Dreamweaver. I remember it being hated by "pro" developers but this plus an FTP client (which was integrated IIRC) was enough for teenager me to be live on the internet.
Nah, I went from jquery to Backbone, Angular, and React. I don't miss jquery, and I like the functional/declarative APIs of JSX. It's a lot like just writing HTML, and CSS, and I still write plenty of JS as pure functions or plain objects, and they're lovely to test.
I don't really see the purpose of the OP when I have vite and subsecond rerenders.
I'm not really a frontend dev, but React (w/ JSX, and w/o Redux or whatever) is the only web thing I've ever used that made sense. Everything else like CSS, Angular, and jquery made me go "wtf."
It seems there have been many opinions questioning why a tool for editing pure HTML is being developed now. Here is my current view on this matter:
These days, it's rare to directly handle HTML files on the frontend of web applications, and placing key elements using absolute or relative coordinates is also uncommon, so the use cases for this extension are currently quite limited.
However, it could be somewhat useful in areas where web technologies are not yet widely adopted but need to be implemented simply. When creating individual components, such as with Vue.js, the real-time preview might become valuable. It could also be helpful for building non-application content like simple landing pages.
There are so many websites downloading entire web frameworks, tens of megabytes, to display static web pages. Maybe a contact form, or a twitter embed or something. I absolutely loathe it and if these sorts of tools even slightly move the needle towards bringing back standard HTML sites, I'm so incredibly for them.
Wait till you hear about Typescript, you know adding types to ECMAScript, like Macromedia did some 20 years ago. :)
Being in the industry for 20+ years and starting as a teenager making games in Flash it makes really hard for me to treat webdev seriously with all their revolutionary innovations.
At work I often encounter a resistance to a tech or solution I propose, because "there hasen't been any substational contribution to the repository in a week, seems dead to me". To which I kindly respond with a question - how do you calculate hypotenuse, because it's been a long time since Pythagoras made the last commit.
Meanwhile, some of my friends are still doing side jobs using CakePHP, 20 years later. :)
Careless bastard. If safety wasn't his concern he at least should have written it with style using NextJS with tRPC using React Server Side components hydrated on the fly with edge locations in mind utilizing streaming components backed by Drizzle ORM further cemented by AuthJS. I'm sure there would have been plenty of starter kits had he tried npm create.
Today I value web stuff for one thing and one thing only: they run in the best sandbox we have. I can run untrusted programs from hackernews folks without worrying! I wouldn't do that with native code of course, way too easy to hack me. But they won't waste a browser 0-day on random HN readers... Whatever can be done in the web, I usually like to do it there as no-body has to trust my code then.
> I can run untrusted programs from hackernews folks without worrying
The assumption is that native code has virtually unrestricted access to your system while JS programs don't, which is true. But if the untrusted JS program is wrapped up in web extension, in 2024, it could do almost as much damage than native code especially since most non-techies don't have much of value in their machines. The value exists on walled sites
> Being in the industry for 20+ years and starting as a teenager making games in Flash it makes really hard for me to treat webdev seriously with all their revolutionary innovations.
I think the framing here is unfair.
It's not that the people innovating in JS or HTML think what they're doing is "revolutionary" or has never been done before. Generally they are applying ideas that have been developed elsewhere, but are currently lacking in whatever their specific area is.
I'm glad to have mostly avoided frontend dev, but we've also had some bonkers backend trends like SOAP. It was like closing your eyes and wishing for a full-stack impl to appear if you write enough XML.
Actually, one of the things I miss the most from AS is... E4X.
I work with ton of json, including hundreds of kubernetes definitions per project, and I really miss the ability to parse the data so swiftly and effective with native syntax.
I've never used E4X, but it at least looks like it'd make XML more tolerable.
Most XML experience I had was ejabberd and XMPP. Was thoroughly pissed off by the end of it. We ended up sending JSON over IQ messages instead because we were super done with XML, only to find that Apple's XML parser takes O(N^2) time to parse each element. Had to split the elements to make it work. 0/10 would not recommend.
A few gigs ago I joined a BigCo as a part of contractor group to build a new project. The BigCo had a staff member to bootstrap the project and build a prototype which was internally reviewed and approved. When we put our foots on the ground it was already settled that the app will be build with X, Y and Z as the core components.
Two months later that staff member left the BigCo for another organization, and when we found the actual job posting for his position the X, Y and Z were explicitly stated as nice to have for a candidate.
> how do you calculate hypotenuse, because it's been a long time since Pythagoras made the last commit.
Asinine - everything advances and needs maintenance over time, even geometry. I invite you to try building a game without using quaternions or projective (ie non-euclidean) geometry.
Edit: does hn award points based on contrariness? Or is it just that people on hn think they're super clever with their contrary point?
No one said it invalidated his theorem. They said it has been expanded upon.
Also, comparing web technologies to something as fundamental as the pythagorean theorem is reductionist and overall pretty ridiculous. Web technologies need maintenance. Proven mathematical formulas don’t.
They actually asked if I was aware what year he died.
The eponymous triangle work is just as valid as it ever was in Euclidean geometries - lot of work there. That work is just as wrong as it ever was in non-Euclidean geometries - maths is timeless like that.
> Also, comparing web technologies to something as fundamental as ...
> does hn award points based on contrariness? Or is it just that people on hn think they're super clever with their contrary point?
It’s both, and seems to be a theme here. HN generally despises the mainstream, so anything that goes against that is praised with little additional thought. A great example is the recent article about “founder mode” which is definitely one of the most idiotic contrarian things I’ve ever read, but receives heaps of upvotes every time it gets posted.
Came in to post something similar. Dreamweaver was where my pro web life began. I want the WYSIWYG idea to work, but with the complexity of responsive design with modern css, I don’t see the model working well, at least in my workflow.
I was so excited when I first discovered Dreamweaver and was gonna make so many great websites. ironically my Engineering degree program had other thoughts
Well, Visual Studio 6.0's Visual Interdev (1998) had actual browser rendering (via the Trident engine used in Internet Explorer I assume), including Java applets, which would run in the "Quick view" mode, but also amazingly in the Source [code] mode!
Mozilla Composer also existed and is the root of a lot of WSISWYG editors today because of the legacy it and others left in the HTML spec (content editable).
We still use Dreamweaver just because you can drop well structured Word documents in and get a decent HTML document out of it. Still not found a better process really.
I do! Wow, what a flashback. I think it was formed from Mozilla's built in editor, and later on died quite quickly and was forked under a different name, which, in turn, died quickly.
Would be much more valuable if you can live-preview Sass. It is easy to guess the impact of HTML edits I am making, but guessing impact of style edits is much harder and so live preview would be more valuable.
You may want to check out previewjs.com (disclaimer I'm the author) although it's unfortunately not getting much love or attention lately, my kids are using all of that.
This tool only handles files that can be treated as static HTML. Therefore, it cannot currently be applied to React implemented with JSX. However, it may be applicable to Vue component files.
Thanks for sharing but I don't find big differences with the currently existing "live preview" and other plug-ins. Can you explain what are the features of your Web Visual Editor? Thanks
A notable feature is the ability to synchronize code selection with visual selection in the preview. Since this extension has minimal functionality, the codebase is very small, making future expansions easy. It is designed to reflect changes made in the preview back to the code, so enhancing the editing capabilities within the preview may be beneficial in the future.
It doesn't matter if it's complex. I believe this tool can be applied if it consists of a single HTML file and the resources linked to it. If you're using Web Components, there may be some issues. JavaScript is currently disabled because it's difficult to determine its impact, but enabling it is technically very simple. If there is enough demand in the future, I will add an option to control the functionality of JavaScript.
I'd think maybe in you could do inline JavaScript. Or inline CSS. Or JavaScript urls in the links. Gosh, there are so many possibilities, makes me feel good about the architectural decisions that led to this point.
Nice extension, it may be worth in the readme explaining how it’s different to https://github.com/microsoft/vscode-livepreview which has been around for a long time and maintained by Microsoft.
I have updated the README to address similar comments and issues. https://github.com/urin/vscode-web-visual-editor?tab=readme-...
Thanks, good work on this extension.
I thought of MS Frontpage for a very brief moment as I was clicking the link to Live Preview.
Pinegrow[1] is somewhat similar to MS Frontpage IIRC. I highly recommend it.
[1] https://pinegrow.com/
Because of the debacle around VSCode extensions owned by Microsoft that recently surfaced here on HN, it's good to have an alternative.
Do you have a link? Curious to know what the concerns were.
Many of Microsoft's extensions are closed source. This one does not appear to be, but MS has been known to replace open source VS Code extensions with closed source ones in the past.
I think it's mainly the `No additional processes` point. Live Preview serves the page, likely by spawning another process to host the server.
I like putting an auto-reloading browser window behind a 60% opacity Vim window.
how do you set it up?
The terminal is iTerm2, but the basic Mac terminal or common Linux ones can do opacity too. Didn't go out of my way to set up auto-reload, so idk how to do it in general, but the default create-react-app dev setup does it.
I was expecting something more like WYSIWYG editor, that actually edits HTML visually in real-time. Something akin to old times of first webpage editors.
Hah yeah, I was picturing Dreamweaver before I clicked the link
I like to use standalone tools with no dependencies, so I made this open source html editor with instant preview as a single html page:
https://github.com/no-gravity/html_editor
It has a few convenience functions already. Open for pull requests.
This is great, A tighter feedback loop is always better for everyone.
I'm also getting some serious Déjà vu for the web tools of the 2000's. History really does rhyme
[dead]
Are we trying to reinvent web development? Last few years have been wild. We abandoned HTML CSS and JS websites that used to work just fine and ran after frontend component frameworks and now the circle is getting completed by building tools and extensions we had 20 yrs ago
>We abandoned HTML CSS and JS websites that used to work just fine
Hmm. Have you actually done much web development in the last 10 years?
Building websites with raw HTML, CSS and JS 10 years ago was very much not "just fine". There's a reason frameworks were invented.
Oh I think it is very much "just fine", but people have requirements which make things too complicated. I find it way harder to work in a React app than a few .html and .js files. TypeScript's cool though.
Most people working professionally as web developers have limited ability to reduce the requirements and have to implement what their company ask for. At that point having something to manage the complexity is much better than not.
The reason being CV driven development in most cases.
For the large part of projects I work on, plain old server side rendering with sprinkles of vanila.js work just fine.
At least folks now rediscovered SSG, but they seem to build rewriting bundlers in Rust as well.
> sprinkles of vanila.js work just fine.
Bullshit. jQuery as a library didn't inherently cause spaghetti code, it was predominantly just used as a cross-browser selector function and some standard library augmentation/fixes before JS itself caught up. Sprinkles of progressive enhancement jQuery were exactly the problem that caused frameworks to be created. Sprinkles of vanilla JS lead to the exact same outcome, minus a jQuery library load.
> it was predominantly just used as a cross-browser selector function and some standard library augmentation/fixes before JS itself caught up.
Do not forget jQuery.ajax, making cross-browser JS HTTP interactions possible in the first place.
Whatever dude, we're doing ASP.NET MVC and Spring/Jakarta with vanilla.js just fine, go improve that CV.
How long have you guys been around? How large/old is the codebase? How many members are on your team?
We have been around since decades, being hired guns for Fortune 500 consulting.
Codebases are as old, or as new, as customers require for their business cases.
What do you consider "not fine" about websites written in "just" html, CSS, and js?
1) Rats nest of non-declarative JavaScript.
2) Rats nest of JavaScript callbacks.
3) Overlapping stylesheets with !important everywhere.
4) Elements used for style not their semantic purpose (<b>, <strong>)
5) Subtle and not-so-subtle browser compatibility issues.
Also: using JS for things where HTML and CSS would have been sufficient, creating some of the issues above.
5) is the only valid reason, the rest has comparable alternative shitty things when using whatever framework
No amount of discipline was going to make medium-large websites maintainable back then. Today it's actually possible if the creators know what they're doing. Tooling isn't going to prevent people from doing stupid things.
I agree with HTML+CSS+JS websites being not fine. But to be honest, js callbacks are more of a language thing than a framework thing. You don't need to use frameworks to write promises.
You can't reuse pieces of UI functionality (a bundle of specific html, css and js) unless did copypasta which is obviously awful. Sharing business logic across different areas of an application becomes much harder and you can't non-trivially write and run tests across areas of your application because you are just using html,css and js. And the big monster: state. Sharing state safely across different areas of an application becomes much harder. You end up writing your own micro framework trying to make all the above work. At that point you might as well use as existing battle-tested one
So, instead of "Building websites...", would it be fairer to say "Building some types of web app..."?
Using them was fine. but developing them, no. It's way more work just managing event handlers for a start.
mainly the CSS
This. A not so great analogy is you can always drop a single php file into your /var/www/ (or even do cgi) and get your "dynamic" website running like decades ago, but people don't do that any more for any website that is not a tiny one with just a few pages (barring famous exceptions like WordPress). People realize there are good reasons to use frameworks, and often, use other languages for website backend.
Let's be honest. Those old HTML+CSS+JS didn't have the interaction levels of modern applications. And jQuery was great until you reached a level of complexity after which it became jquery Bolognese. There are 2 main challenges: state and reusing pieces of html. Both of these are much harder in modern applications due to their complexity. Try reusing a piece of HTML using HTML+CSS+JS alone (no Node or back-end tools allowed). Try keeping state synced across a modern application without using state management libraries.
Most "applications" I visit in my browser have no business being an application. The "clear search history" button in my start menu has no business loading a React environment with three redirects either.
Some web applications need a boatload of frontend stuff to make them usable, but I rarely encounter websites that warrant such overkill. A payslip/email subscription/car rental website with a profile page and maybe three forms I can possibly need to submit doesn't need to be a fully interactive application with loading bars and offline support, leave that stuff for the websites I visit more than once a month.
At this point React/Vue/Svelte devs are probably cheaper to hire than basic JS devs, but technology wise the amount of Javascript my browser needs to load for the most basic interactions is mind-boggling. More than the "this meeting could've been an email" meetings, I run into "this web application could've been a POST request" web pages.
I have to second this, 100%. Not everybody is developing the next Canva or the next Google Docs.
To me it sounds like people trying to justify that what they do has some higher value than what it really does.
Tailwind is reviving the style attribute.
I've taken the next step and written my own tool that lets me put all my Tailwind attributes in a separate file grouped by element selectors. :-)
There are complex reasons behind my development of this. To be honest, I don’t think the editing functionality of this tool is particularly useful. I believe the real-time preview and element selection features are the ones that offer broader utility. I am considering making the editing feature disabled by default and allowing it to be enabled through settings in the future.
I don’t think it was meant to criticize your work :)
It’s just fun to see that we (here : you) are reinventing tools that everyone used 20 or 30 years ago.
I remember making my first websites in Dreamweaver. I remember it being hated by "pro" developers but this plus an FTP client (which was integrated IIRC) was enough for teenager me to be live on the internet.
The nostalgia hit me, I remember before Dreamweaver, there was Netscape Composer, W3C Amaya, and similar software.
How is Dreamweaver these days?
part of creative cloud, $20/mo. Last update May 2024 https://helpx.adobe.com/dreamweaver/using/whats-new.html
I came here to comment about Macromedia Dreamweaver (at the time I used it). It was an ok software for the time. Acceptable WYSIWYG.
Bring FrontPage back! ;)
Nah, I went from jquery to Backbone, Angular, and React. I don't miss jquery, and I like the functional/declarative APIs of JSX. It's a lot like just writing HTML, and CSS, and I still write plenty of JS as pure functions or plain objects, and they're lovely to test.
I don't really see the purpose of the OP when I have vite and subsecond rerenders.
I'm not really a frontend dev, but React (w/ JSX, and w/o Redux or whatever) is the only web thing I've ever used that made sense. Everything else like CSS, Angular, and jquery made me go "wtf."
And what is more crazy, acting as if they are something new, instead of something that is 20 years old.
No one's doing this, or at least not in the way you're implying.
reminds me of good old Macromedia DreamWeaver times :)
It seems there have been many opinions questioning why a tool for editing pure HTML is being developed now. Here is my current view on this matter:
These days, it's rare to directly handle HTML files on the frontend of web applications, and placing key elements using absolute or relative coordinates is also uncommon, so the use cases for this extension are currently quite limited.
However, it could be somewhat useful in areas where web technologies are not yet widely adopted but need to be implemented simply. When creating individual components, such as with Vue.js, the real-time preview might become valuable. It could also be helpful for building non-application content like simple landing pages.
There are so many websites downloading entire web frameworks, tens of megabytes, to display static web pages. Maybe a contact form, or a twitter embed or something. I absolutely loathe it and if these sorts of tools even slightly move the needle towards bringing back standard HTML sites, I'm so incredibly for them.
The web is so flat and dull now.
we've come full circle - macromedia dreamweaver had this in 2001
Wait till you hear about Typescript, you know adding types to ECMAScript, like Macromedia did some 20 years ago. :)
Being in the industry for 20+ years and starting as a teenager making games in Flash it makes really hard for me to treat webdev seriously with all their revolutionary innovations.
At work I often encounter a resistance to a tech or solution I propose, because "there hasen't been any substational contribution to the repository in a week, seems dead to me". To which I kindly respond with a question - how do you calculate hypotenuse, because it's been a long time since Pythagoras made the last commit. Meanwhile, some of my friends are still doing side jobs using CakePHP, 20 years later. :)
> how do you calculate hypotenuse, because it's been a long time since Pythagoras made the last commit.
Also, Pythagoras should be rewritten in Rust for safety.
Careless bastard. If safety wasn't his concern he at least should have written it with style using NextJS with tRPC using React Server Side components hydrated on the fly with edge locations in mind utilizing streaming components backed by Drizzle ORM further cemented by AuthJS. I'm sure there would have been plenty of starter kits had he tried npm create.
EDIT: RCS
Today I value web stuff for one thing and one thing only: they run in the best sandbox we have. I can run untrusted programs from hackernews folks without worrying! I wouldn't do that with native code of course, way too easy to hack me. But they won't waste a browser 0-day on random HN readers... Whatever can be done in the web, I usually like to do it there as no-body has to trust my code then.
> I can run untrusted programs from hackernews folks without worrying
The assumption is that native code has virtually unrestricted access to your system while JS programs don't, which is true. But if the untrusted JS program is wrapped up in web extension, in 2024, it could do almost as much damage than native code especially since most non-techies don't have much of value in their machines. The value exists on walled sites
> Being in the industry for 20+ years and starting as a teenager making games in Flash it makes really hard for me to treat webdev seriously with all their revolutionary innovations.
I think the framing here is unfair.
It's not that the people innovating in JS or HTML think what they're doing is "revolutionary" or has never been done before. Generally they are applying ideas that have been developed elsewhere, but are currently lacking in whatever their specific area is.
I'm glad to have mostly avoided frontend dev, but we've also had some bonkers backend trends like SOAP. It was like closing your eyes and wishing for a full-stack impl to appear if you write enough XML.
Actually, one of the things I miss the most from AS is... E4X.
I work with ton of json, including hundreds of kubernetes definitions per project, and I really miss the ability to parse the data so swiftly and effective with native syntax.
I've never used E4X, but it at least looks like it'd make XML more tolerable.
Most XML experience I had was ejabberd and XMPP. Was thoroughly pissed off by the end of it. We ended up sending JSON over IQ messages instead because we were super done with XML, only to find that Apple's XML parser takes O(N^2) time to parse each element. Had to split the elements to make it work. 0/10 would not recommend.
Unless you are ready to maintain the product for the long term, proposing to use new tech is just resume development.
A few gigs ago I joined a BigCo as a part of contractor group to build a new project. The BigCo had a staff member to bootstrap the project and build a prototype which was internally reviewed and approved. When we put our foots on the ground it was already settled that the app will be build with X, Y and Z as the core components.
Two months later that staff member left the BigCo for another organization, and when we found the actual job posting for his position the X, Y and Z were explicitly stated as nice to have for a candidate.
¯\_(ツ)_/¯
JavaScript 4, had it not been sabotaged.
> how do you calculate hypotenuse, because it's been a long time since Pythagoras made the last commit.
Asinine - everything advances and needs maintenance over time, even geometry. I invite you to try building a game without using quaternions or projective (ie non-euclidean) geometry.
Edit: does hn award points based on contrariness? Or is it just that people on hn think they're super clever with their contrary point?
quaternions - 1843, Hamilton
projective geometry - 1420's but big in the 19th Century.
These are things I used heavily programming earth mapping systems in the mid 1980s to mid 1990s. Principal reference text was from the 1920s.
... The guy I responded to is saying Pythagoras is good enough. Do you know what year Pythagoras died?
495 BC. And his Theorem is still good enough for most practical purposes, so his point stands
Does that invalidate his theorem (that he cribbed from the Babylonians)?
No one said it invalidated his theorem. They said it has been expanded upon.
Also, comparing web technologies to something as fundamental as the pythagorean theorem is reductionist and overall pretty ridiculous. Web technologies need maintenance. Proven mathematical formulas don’t.
They actually asked if I was aware what year he died.
The eponymous triangle work is just as valid as it ever was in Euclidean geometries - lot of work there. That work is just as wrong as it ever was in non-Euclidean geometries - maths is timeless like that.
> Also, comparing web technologies to something as fundamental as ...
Take that up with whomever it was that did that.
I understand what you want to say here but...
Do you need these things to write Sokoban, Tetris or any other simple 2d game?
> does hn award points based on contrariness? Or is it just that people on hn think they're super clever with their contrary point?
It’s both, and seems to be a theme here. HN generally despises the mainstream, so anything that goes against that is praised with little additional thought. A great example is the recent article about “founder mode” which is definitely one of the most idiotic contrarian things I’ve ever read, but receives heaps of upvotes every time it gets posted.
Came in to post something similar. Dreamweaver was where my pro web life began. I want the WYSIWYG idea to work, but with the complexity of responsive design with modern css, I don’t see the model working well, at least in my workflow.
I was so excited when I first discovered Dreamweaver and was gonna make so many great websites. ironically my Engineering degree program had other thoughts
Yes, but Dreamweaver had the render broken since about 2001 (I don't know the actual date, mine is a joke).
Vs code being chromium means actual browser rendering
Well, Visual Studio 6.0's Visual Interdev (1998) had actual browser rendering (via the Trident engine used in Internet Explorer I assume), including Java applets, which would run in the "Quick view" mode, but also amazingly in the Source [code] mode!
Mozilla Composer also existed and is the root of a lot of WSISWYG editors today because of the legacy it and others left in the HTML spec (content editable).
thats exactly what I thought, I'm old enough to even remember Netscape Composer. I was 10 y/o when used it lol
Hot Dog from Sausage Software
Don't forget Microsoft Frontpage
We still use Dreamweaver just because you can drop well structured Word documents in and get a decent HTML document out of it. Still not found a better process really.
When I was young, I learned HTML with Nvu, if anyone else remembers that.
I do! Wow, what a flashback. I think it was formed from Mozilla's built in editor, and later on died quite quickly and was forked under a different name, which, in turn, died quickly.
Anyone here remember homesite?
Ah yes! And HotDog html editor from “sausage software”.
Is there a way you can edit HTML directly in browser devtools and have it update in your code repo?
Is this a significant improvement from having a "live preview" on a browser?
You don't need to save.
And it has nice features like highlights selection
You know that every respectable editor nowadays has a auto-save feature on focus loss? So just alt+tab from your editor to your browser and refresh.
Would be much more valuable if you can live-preview Sass. It is easy to guess the impact of HTML edits I am making, but guessing impact of style edits is much harder and so live preview would be more valuable.
The title was a little confusing for me. Don't you edit HTML visually in real-time all the time?
Nice. Will this work with React as well?
You may want to check out previewjs.com (disclaimer I'm the author) although it's unfortunately not getting much love or attention lately, my kids are using all of that.
Well, life takes us other places sometimes.
Still, it's pretty cool that your kids are using previewjs.com!
No, don't bother - I'll see myself out :)
This tool only handles files that can be treated as static HTML. Therefore, it cannot currently be applied to React implemented with JSX. However, it may be applicable to Vue component files.
Or vue ?
Very unfortunate naming if you understand some German...
Nicer not to mock someone's name just because it happens to mean something in a completely different language =P
Definitely not mocking!
Just letting OP know, perhaps it'll help to communicate better with the German usership in the future...
Thanks for sharing but I don't find big differences with the currently existing "live preview" and other plug-ins. Can you explain what are the features of your Web Visual Editor? Thanks
A notable feature is the ability to synchronize code selection with visual selection in the preview. Since this extension has minimal functionality, the codebase is very small, making future expansions easy. It is designed to reflect changes made in the preview back to the code, so enhancing the editing capabilities within the preview may be beneficial in the future.
This is useful. I am occasionally day dreaming about moving my static site from Hugo to pure html which I write/edit myself.
Do these features depend on complexity of the html or that doesn't matter? Does Javascript work in live preview?
It doesn't matter if it's complex. I believe this tool can be applied if it consists of a single HTML file and the resources linked to it. If you're using Web Components, there may be some issues. JavaScript is currently disabled because it's difficult to determine its impact, but enabling it is technically very simple. If there is enough demand in the future, I will add an option to control the functionality of JavaScript.
Why do you fantasise about writing pure html manually for an entire website? Haven't you done it before?
I like it. It saves me a Ctrl+s and some setup for a hot deployment.
You missed the opportunity to name it Vscode-FrontPage. We Are So Back.
Nice to see you again, HotDog.
There's a name I haven't heard in many years
Does it handle js? I can't tell if this is only for static files from the documentation.
Since it does not handle JavaScript at the moment, I believe the applicable scope is quite limited.
I'd think maybe in you could do inline JavaScript. Or inline CSS. Or JavaScript urls in the links. Gosh, there are so many possibilities, makes me feel good about the architectural decisions that led to this point.
Thank you for using a FOSS license!
Ah yes, bracket editor by adobe is back
Interesting
This reminds me of Microsoft FrontPage more than 20 years ago.
Well now I have to try it. I used Frontpage for all of my web sites as a kid and I miss it a lot.