Show HN: A VSCode Extension to edit HTML visually in real-time

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

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.

Tailwind is reviving the style attribute.

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.

And what is more crazy, acting as if they are something new, instead of something that is 20 years old.

How is Dreamweaver these days?

>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.

What do you consider "not fine" about websites written in "just" html, CSS, and js?

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. :-)

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.

part of creative cloud, $20/mo. Last update May 2024 https://helpx.adobe.com/dreamweaver/using/whats-new.html

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.

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 came here to comment about Macromedia Dreamweaver (at the time I used it). It was an ok software for the time. Acceptable WYSIWYG.

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.

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

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.

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.

So, instead of "Building websites...", would it be fairer to say "Building some types of web app..."?

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.

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.

Using them was fine. but developing them, no. It's way more work just managing event handlers for a start.

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.

No one's doing this, or at least not in the way you're implying.

Whatever dude, we're doing ASP.NET MVC and Spring/Jakarta with vanilla.js just fine, go improve that CV.

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.

How long have you guys been around? How large/old is the codebase? How many members are on your team?

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."

Bring FrontPage back! ;)

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.

> 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.

mainly the CSS

Also: using JS for things where HTML and CSS would have been sufficient, creating some of the issues above.

Do you have a demo of this? Sounds cool

Sure you can, Web Components exist now, and SSR components exist for 25 years across all main languages.

Yeah. I'd argue you should quit if you as dev have no say in the development, but what do I know

this ^ - and if js at all, then only using a subset which passes jslint.com without any errors or warnings. that the score of any site should be

100 100 100 100 1.1s max paint (mobile) 0ms block 0.0xx max shift A+ headers 0 errors and 0 contrast errors webaim goes without saying of course

I love this discussion -- it provides interesting perspective on the history, especially for me as a person who is learning web development.

it absolutely was fine. it was easy and many children were able to do it with minimal experience. the reason frameworks were invented was because the web devs at big tech companies decided to use dumb and sluggish hacks to simulate features that websites never did and still don't need.