SuperHTML is here to rescue you from syntax errors, and it's FOSS

Developer Loris Cro reckons his LSP language server for HTML is a world first, and that the absence of such tools up to now has had grave consequences for the web. SuperHTML is a language server that talks to compatible code editing apps over the Language Server Protocol (LSP). What that means is that you can plug it into …

[TheMaskedMan]

"a complex CMS written in PHP that requires a web server, multiple workers, a Redis cache, and a SQL database..."

And presents and attack surface the size of a planet - I leave debate as to which planet as an exercise for the reader.

Of course, cranking raw HTML in Notepad never had any fancy language server malarkey, and I hope this doesn't give micros~1 any silly ideas. But has this really never been done before? I could have sworn Dreamweaver did some kind of code completion etc back in the earthy 2ks, but that was 20 years ago and I could easily be wrong. I do recall using an HTML validator before upload on some sites, but of course that wasn't live - more akin to a code / compile/ debug loop.

As for static pages, I'm all in favour. Simple is better, and usually faster, too.

[Guy de Loimbard]

Thank you for the point on attack surface.

In the fight to present information and a lack of actual nugatry HTML skills, the CMS is king, along with all of it's complexity and unecessary libraries and so on.

I used Dreamweaver and other IDEs back in the 90s and 00s to great effect, in fact I'm even considering posting a new website, full of my own drivel, but driven by static pages with a sprinkle of PHP for certain functions, but by no means massive attack surface.

Groundbreaking in it's return to a more simple time....... :) Maybe!

[Peter2]

As long as I get to keep SSI with those static pages as in HTML4 so that you can include a header and footer (so that the design of the web page is separated from the content) then i'm all for it.

[TheMaskedMan]

"As long as I get to keep SSI with those static pages"

SSI was soooo useful! When I first looked into HTML, I was amazed that it didn't have any kind of #include equivalent, much to the bemusement of my colleague who had a degree in IT rather than Computer Science and didn't know one end of a compiler from the other.

At one time I built a site with several thousand static pages, and used SSI to handle headers, footers, sidebars etc - maintaining that lot without some means of including common files would have been a nightmare. Yet, today, it's almost forgotten - I was looking for a hosting company a couple of years ago, and couldn't find mention of SSI on my preferred host's feature list. Support didn't know offhand, either - the guy I spoke to said he hadn't heard of it for years and nobody had ever asked. Still, he went away and found out for me - it was supported, so I signed up. Don't think I'd want to run a hand coded static site without it!

[PRR]

> As long as I get to keep SSI with those static pages

Back in 1999 or so, I had a HTTP server with either no or broken SSL. And a lot of overlapping groups of staff. The 4th time I re-typed all of Bill_B's CV I said "pull it from a boilerplate file". I did an inflexible demo in DOS BAT language, then a 98% functional version in MS DOS BASIC. 64K data segment, and my boilerplate file was pushing 57k. (Being very lazy, I pulled the whole file to RAM and used string functions.) The bookstore was closing-out WinNT(4?) bundled with Visual Basic for $10 so I made that leap. It would read tags and substitute boilerplate, recursively. Adding new persons or menus was trivial text-editor work. Extracting just part of a person's credits was easy (some people served two sections).

Then I got the opportunity to host on another machine (and let S--- take blame for downtime). But Mac/unix, hence a total rewrite in Perl. I forget why, but I know it was PHP at the end. Even with all the engine- and language-jumping, I figure I came out ahead in being able to populate new staff in thin slivers of time. (Worked against me when I went off salary to do piecework on the clock.....)

[Anonymous Coward]

Real frontier men back in the day wrote Perl built scripts to do this sort of thing before uploading with FTP.

I had a whole bunch of build scripts that I re-used on load of projects stashed on a floppy disk that did loads of things like generating a boiler plate and folder structure as a base to start from. Simpler times.

I still have those scripts along with an arsenal of other custom made build scripts, deployment scripts and so on to make life easier...along with a piece of technology that would have blown my young mind in the 90s...an IODD mini...that lets me carry an entire bootable OS (stored on an encrypted virtual hard drive, which I have backups of on the device itself and on my DAS, NAS and various other places) that I can mount on the device that gives me access to not only the scripts, but an entire OS to run them on using any machine within reach...this device along would have shaved days off projects back in the day...amazing.

Tons of effort goes into setting up a slick IDE, completion, picking frameworks etc etc these days, but not nearly enough effort into figuring out how you will set yourself up at a client to save time (you can't always use your own laptop, and even if you do, you want it in a clean state that is immediately ready and does not contain another customers data)...back in the day, you probably didn't have a laptop (they were bloody expensive, went obsolete really quickly, weighed a ton and you had to wait ages for one to arrive if you ordered one. You were therefore at the mercy of that one shitty spare machine the customer had stashed in a cupboard as a spare (which you'd have to setup on top of a chest or drawers or a small row of cupboards, usually in the corner jungle of 90's office flora) until you proved your worth and they invested in a new one just for you and found you a desk...those were the tough days, out in the wilderness, no package managers to help you, strange uncharted hardware to work on...proper survival level web development.

It was just you, the water cooler, the leased jungle of plants on a weirdly expensive maintenance contract that have been moved to the corner because nobody liked them and they can't throw them out until the 2 year contract ends and a shit PC...not even a chair sometimes...you'd have to make occasional dangerous journeys from the jungle to the sales department to download tools or upload changes using the only internet connected PC in the office...braving harsh conditions like talking about football (the trouble with Arsenal is they want to walk the ball in), talking about the wife with massive tits of that one sales guy and she's a "diamond"...etc etc...only after you've proven yourself in this wilderness would you be able to take your throne on 50% of the reception girls desk, on Tuesdays and Wednesdays when she isn't in, as king of the company website...the deity of HTML...the WEBMASTER! Life was going to be easy from that point on, forever...you are now the office "whizz kid", building web pages, fixing technical issues, setting up new PCs...earning free beer...you are invincible, untouchable and constantly wear a shit eating smug grin...forever you will be lauded as the saviour of the business...nothing can corrupt you...

*flash forward a couple of years to some time circa 1998*

POSTMASTERS, SYSADMINS and PROJECT MANAGERS begin appearing en masse on desks in dank basements to the sound of Orc horns...

...to be continued.

*end on cliffhanger, play dramatic 'Fellowship of the Ring' credits music, cut to credits*

[Mike007]

You can always use Javascript to fetch() then inject...

I am not happy to have needed to come up with that "solution" in the past.

<div src="..."> if the XHTML people hadn't been so obsessed with getting rid of tables they could have done these kinds of reforms....

[FIA]

Right... I'm adding 'Dreamweaver' to the reg forum trigger words list....

[Stephen Wilkinson]

Dreamweaver, Frontpage and all that ilk produced appalling HTML which I'd have to clean up when the files had been passed to me as the web developer, from the graphic designer.

I definitely don't want to go back to those days!

I still prefer to hand crank HTML if I'm honest - EditPlus is still my favourite text editor.

[Yorick Hunt]

DreamWeaver was great to quickly slap together layout concepts, but only fools would publish the HTML it produced verbatim.

It was also great that it had all of O'Reilly's HTML, CSS and JavaScript references built in, back in the days before every reference was available for simple access online.

I can't even remember which text editor I used back 'round the turn of the millennium to crank out web sites, but I'm sure it wasn't Notepad. I do remember though constantly having DreamWeaver running in the background to do "what if" renders and access the aforementioned O'Reilly's info.

[Anonymous Coward]

Frontpage was for peasants (usually because it was the Express version). It was often used in conjunction with Word (a la copy/paste) which would produce insanely crap HTML through the rich text conversion with Internet Explorer specific features.

Dreamweaver was for people with top hats, monacles and silver trays covered in Ferrero Rocher.

Notepad was the tool of kings because you could right click in your FTP client and open a page in notepad, then save and it would upload immediately.

The CuteFTP crappy built in text editor was the tool of legends because it had the same functionality of Notepad, but none of the stability...you could work in that for hours then suddenly...poof...it disappears...THIS...IS...SPARTA!

[Anonymous Coward]

Anyone remember slicing PSD files up and spending half a day setting border values to 0?

[ecofeco]

Dreamweaver did no such thing. The users of Dreamweaver did, but Dreamweaver itself did NOT just add bloat and its HTML was flawless. I was building sites for years for both desktop and mobile (A lost art these days). My sites ALWAYS worked perfectly on any screen.

Now Frontpage? What an incredible POS. NetFusion as well.

[Anonymous Coward]

Nothing Dreamweaver produced was flawless at a code level...sure it worked wherever you uploaded it, but that is not an indicator of clean and flawless code.

It was nowhere near the level of trash that Frontpage was, but it wasn't great.

Anyone that inherited a site built in Dreamweaver will tell you how much of a pain in the ass updating that site would be...especially if it was a more advanced site that took advantage of the PHP/MySQL support.

I'll give Dreamweaver some credit, it did help me learn/improve PHP skills at a time when accessing guides and tutorials was basically impossible for me, but getting a cracked copy of Dreamweaver was easy...but looking back on some of the projects I built and the code that was written and generated...not great...it has always been possible to do things in a couple of lines that Dreamweaver would produce a huge block of code for...that doesn't necessarily make it bad code, but it does make it more complicated and convoluted that it needs to be.

It was very much a product of its time, but it was also the gateway to PHP for quite a lot of people...even if it was a major source of projects that had SQL injection vulnerabilities...which ironically, I wouldn't have learned about at such an early age if Dreamweaver didn't cause the problem...so weirdly Dreamweaver taught me how to write convoluted vulnerable code that I had to learn to secure independently.

[Splod]

One would expect LLMs/AI to have a place in this but most of the effort appears to be going into active/logic languages (there's probably a better name), i.e., Java, Python etc. They could probably work well with either hand written html or cleaning up visual editor outputs. Maybe I'm just not noticing?

[Anonymous Coward]

"there's probably a better name"

Yeah. Programming Languages. HTML is a markup language.

[Charlie Clark]

I've written more than enough HTML in my own time to know that you need code completion as a bare minimum to get anything done and that was before it became necessary to make things pretty and all the hacks started appearing. Once we got away from using frames and tables for layout, the HTML itself became reasonably manageable but you really had to be good at CSS. Then came all the dynamic stuff for processing user input, etc. and this is when you really do start to need some kind of client + server approach, especially given the inherent restriction in http making it extremely difficult to provide the kind of feedback users need, especially after Microsoft successfully drove HTML development into a ditch for a few years. This led to an explosion in client-side scripting in Javascript and eventually into entire applications running in the browser, effectively bypassing the HTML process.

Things have sort of gone full circle since then, especially now we have some kind of persistent communication between client and server so that most work on the server is based around the data model with more or less tight-coupling with a client-side library which handles screen updates. This, ironically, means that HTML can be kept truely minimal and easy to work with, though for larger projects you'll probably want some kind of templating.

I've been away from website development for a while but have a couple of projects I'm looking forward to: some kind of static website generator like Jekyll, etc. for my ramblings; and a migration from Tumblr to Ghost. I've no great interest in Tumblr's content, but it's an excellent mobile client and we've used it for a few travel journals as an alternative to &lt; pick the network that people have to join &gt;. But now, along with the ads, people have to login to read our shit and posting image sets from the phone is beyond most static site generators…

[ecofeco]

Nailed it about M$ and the workarounds we had to do because of their ego and incompetence.

[Liam Proven]

[Author here]

> But has this really never been done before?

This isn't really my area -- I did without it and checked a preview pane -- but as I understand it, yes, it's been done before, but only in proprietary ways in proprietary tools. This is FOSS and works with any editor that speaks LSP, which includes dozens of them, old as well as new.

El Reg's editors were quite excited when they read my piece when I filed it. :-)

[TheMaskedMan]

"This is FOSS and works with any editor that speaks LSP, which includes dozens of them, old as well as new."

Ahhh, yes, my mistake.

[Tron]

HTML still works.

I used to use NotePad for my static HTML pages, before stepping into the future and doing them on NoteTab Light.

Google has no trouble finding them and popping them on the first page of results, without any SEO.

[Sampler]

Re: HTML still works.

Because universal search which will push sites you visit regularly to the top of the results?

Or for actual users trying to find information who've never heard of you before?

[Combat Epistomologist]

And there is the Nikola option (edit: which I see NOW someone else already mentioned) — a smart, powerful site builder written in Python that generates static deployment-ready HTML/CSS with no CMS or PHP required. Combined with Isso, you can even get interactive blog commenting still with no need for PHP.

[Anonymous Coward]

Whilst not really code completion the way many expect it, Emmet does HTML completion pretty well using short hand.

https://emmet.io/

It's been around for ages. If you still think in the old school way (as I do) when writing HTML, i.e. starting with some form of shorthand pseudo HTML then filling in the gaps...the emmet plugin is amazing.

For example, let's say you want a table with 3 rows and 3 columns. You'd type something like table>tr*3>td*3 then hit CTRL+E and boom there is your table ready to go.

I'm sure many of you know about Emmet already, but for those that don't, give it a try...saves you potentially millions of keystrokes a year...it won't improve your HTML, but if you already know HTML like the top of your cock, it will speed you up no end...it also supports some UI frameworks as well like Bootstrap.

[Anonymous Coward]

"requires a web server"

All websites require this if you want them to be accessible on the internet. So I'm cancelling that one out.

"And presents and attack surface the size of a planet"

Well that depends on your topology to be fair, not everything in that stack has to be internet facing. It can increase your attack surface considerably, no doubt, but by how much and to what degree depends on how you deploy it...most folks (I'd hope) don't use direct database connections on their frontend anymore, they will create a backend internet facing API which provides a layer the database can live behind to prevent it's ass being on the internet. Quite a lot of people these days use some kind of BaaS...like Directus, Firebase, Pocketbase etc etc...which puts the database behind a general purpose API, most of these are free and open source.

Redis isn't as common as you might think. I see it a lot on websites with massive traffic but not so much on smaller sites. It again doesn't have to be internet facing, you can tuck it away behind an application proxy.

The typical "bargain bin" setup I use to mitigate a lot of attack surface is to use Cloudflare (or some CDN or other) as the entry point from the internet, which sends requests (authenticated with TLS) back to a reverse proxy (usually NGINX, which is the final internet facing box) then I have my application servers behind NGINX (load balanced if I have several of them) which connect to the database / redis / whatever...usually on an internal network of some kind (local if it's a bare metal deployment in a DC, or using a virtual internet network if it is cloud based, either way, it's off the internet and only accessible directly on the internal LAN). Sounds like it might be pricey, but you'd be surprised how cheap a setup like this can be, easily less than £40 a month in most cases for sites with a "general" amount of traffic...on cheap VPS boxes, the 4 quid a month jobs, you can easily reach numbers in the tens of thousands if your application isn't massively data heavy possibly more if it's just a blog etc.

Unless the application itself is attacked (which is a different matter entirely) the only internet facing box available for attack is the NGINX reverse proxy setup...which I would argue is less vulnerable than a straight up webserver hosting static HTML, simply because it isn't reading / writing anything from / to itself, it's just the messenger.

What does definitely increase is the complexity of your setup, looking after this sort of setup requires much greater skill than looking after say a single Apache box hosting a static site for example.

To me, the more complex solution doesn't make much of a difference, I've set it up hundreds if not thousands of times and I'm not breaking a sweat doing it either way...it is 2-3 boxes more to maintain which increases the required time to perform maintenance, but doesn't really increase the difficulty much for me personally, if at all...the only thing that would make me sweat in the more complicated scenario is if I didn't build the application...that presents an attack surface I have little to no control over and can undermine my efforts if the developer is a moron...which is quite common, because the developer is the easiest place to trim some fat in terms of costs etc...especially these days with them being ten a penny on the job market.

[Anonymous Coward]

KISS

Keep It Simple, Stupid

[Bebu]

I wish...

I had this years ago. The small amount of my content creation was purposely limited to html, CSS ( no javascript) so a tool like this would have been invaluable.

Trying to secure a web service that required the panoply of PHP, CGI, *sql etc etc for a CMS or a wiki, was a bridge too far - requestors were told to go to WordPress (or to buggery - if there's a difference.) No breaches and users often discovered there is a lot you can do with static pages and in one case augmented with Makefiles. ;)

[Alan J. Wylie]

Nikola

For my personal, self hosted web site I used to use Blosxom, but it's getting old in the tooth. I recently moved to Nikola, available as a package in Gentoo. It's a Python program that takes as input plain text files with some HTML markup and turns them into more featured HTML. Fortunately importing my old site was pretty easy using the RSS support in Blosxom.

[Chris Gray 1]

Re: Nikola

Having little patience and a horrible memory, I didn't even try to find tools to use (poor memory => forever forgetting how to do the things I need to do). So, I just wrote a couple of C programs. "tnall" produced thumbnails (exec-ing a standard Linux image program to do the actual work of course). "mkpage" took a text file that listed the images for the rows on the page, possibly with individual footers, along with the text and header material, and created the static (table-full!) web page. Can't recall when I created the tools - it was a long time ago.

So, I didn't have to learn anything new, and putting up a webpage of images just required choosing the images, creating descriptions, creating the surrounding text, and deciding where it should link into my website. And yes, many would consider the pages ugly. Check the wayback machine for www.graysage.com .

Unfortunately, to keep my ISP from getting unhappy with me, I recently unpermitted most of the directories of pages. I do now have higher bandwidth, but its been over a week and the various crawlers are *still* trying to access now-unpermitted stuff!

[NJS]

Re: Nikola

Been using mkdocs in Python myself - write the pages in markdown and then let the tooling do the rest.

Bit of a faff as a one off exercise to get the content across from the old static pages into md but once it was presentable enough for the code to chew on it actually looks pretty decent and from here on refreshes of the site should (fingers crossed) be updating content and updating the template.

I stuck with a static HTML site for (does a name lookup... oooh nearly 20 years!) but I just don't have the time to keep fiddling with it and keep the HTML current - hopefully this way the maintenance burden drops off.

[karlkarl]

HTML+tables+m4

Has worked for decades. The rest is just "fluff".

(... yes my websites look like crap but thats not the point ;)

[horse of a different color]

If you are using tables for layout, may I refer you to shouldiusetablesforlayout.com

[karlkarl]

Heh, they should now try to center the "No." vertically and still have it render correctly on all browsers. The cowards!

[Anonymous Coward]

>Heh, they should now try to center the "No." vertically and still have it render correctly on all browsers.

Yep - spend some time on wayback machine, guess which ancient artefacts are 10x more likely to render correctly. Mind boggling to me than in 2024 we are still serving people dodgy, time-limited user-interfaces and not simply content/data to skin and consume however we like.

[Dave559]

shouldiusetablesforlayout.com

Hehe, some nice easter eggs in the page source for that site!

[Liam Proven]

> m4

M4, as in what used to make sendmail.cf _slightly_ less brutal?

Is this some sort of BDSM thing? Mortification of the flesh, for dabbling in the sins of the Web kind of thing?

[karlkarl]

Yep. And the same processor that makes GNU Autotools so *cough* beautiful to work with.

[Roopee]

+1

...for mentioning BDSM :). FetLife is a nice social network site to use, and some of it is open source and on GitHub, and all of it is open-minded! The devs have a sense of humour too.

[Zippy´s Sausage Factory]

Ah, sendmail.cf - that takes me back. In much the same manner as seeing a collection of medieval torture instruments, if I'm honest.

[Howard Sway]

would like to see a switch back to plain old static HTML

The problem lies not so much with Content Management Systems - when new content is added regularly to a site, nobody wants to have to work with raw HTML to do so, they just want to supply the text of that content. The problem is on the Content Publishing side where every web page served gets dynamically created on the fly for each user. A great many sites that don't change content too many times daily could be made way faster and less bloated by generating new static files every time new content is added, and just serving those up.

Those serving up fancy AJAX pages that dynamically push new content to clients, and other bloated horrors would of course have to stay as they are, but the web in general has far too many over-bloated and poorly performing web sites due to poor technology choices that are completely unnecessary for what is being served up.

[Liam Proven]

Re: would like to see a switch back to plain old static HTML

> they just want to supply the text of that content

I saw a blog post on the Orange Site a couple of years ago that was called "the language of the Web is HTML" or words to that effect.

In essence it said all you needed was HTML, CSS and images.

The Javascript weenies were _up in arms_, aided and abetted by the PHP folks and their acolytes. Livid they were. :-D

Me, I want to dump some Markdown in a folder and have it magically appear on the web, without anything interpreted in anything involved in between. No JS, no PHP, nothing that isn't type- and bounds-checked native code, thankyouverymuch.

I think I also saw sites where someone found a way to directly serve .TXT files over HTTP. Links were the hard bit. I saw a web page constructed without even HTML, and I kinda liked it.

Can't find either again now, sadly.

[Natalie Gritpants Jr]

Re: would like to see a switch back to plain old static HTML

I edit my personal wiki using MD files in emacs and publish via a filter to convert md to html in apache:

# Apache configuration directives for the local wiki pages.

ExtFilterDefine md-to-html mode=output intype=text/markdown outtype=text/html cmd="/usr/bin/pandoc --from=gfm --to=html5 --template=/var/www/html/pandoc.tmpl"

<Directory "/var/www/html/wiki">

Options +FollowSymLinks

AuthType basic

AuthName "Wiki"

AuthUserFile /etc/apache2/htpasswd

Require valid-user

SetOutputFilter md-to-html

AddType text/markdown .md

</Directory>

[O'Reg Inalsin]

Yours is only one of two comments mentioning markdown (MD)

Markdown was launched in 2004 by John Gruber, and in good FOSS fashion there are now a multitude of flavors of MD and programs to convert them into static HTML.

Widely used for software documentation and software blogs. Much easier to read too.

[DaveLS]

Re: would like to see a switch back to plain old static HTML

Nearly thirty years ago I used Perl and the CGI.pm module to generate web pages on the fly from plain text content provided by people who didn’t know HTML. It was fine insofar as it went (internal access, limited audience) but probably not a good idea for wider public use nowadays, given the likely vulnerabilities and load on the server.

[doublelayer]

Re: would like to see a switch back to plain old static HTML

That depends on what you want your site to do and how much you want to do to make it happen. Most of the sites I have made, not being a professional web designer, are hand-written HTML. I still need a backend language though because most of them do at least some nonstatic things. They take user input and send it to me, or they build pages from templates so the user can select something I hadn't premade a page for and still get a result. Someone who likes the splitting approach (XKCD) might say that I'm making web applications rather than websites, but when the application is humble enough, the dividing line isn't clear. I tend not to use JavaScript, not because it isn't useful, but mostly because I don't like it and some people won't run it.

Making a website out of text files is possible, because most browsers will display a text file when they're sent one. You won't get most of the nice things about HTML unless the browser chooses to interpret the text file as HTML anyway, which sometimes happens, but in that case you're not using plain text, just badly written HTML. If you want clickable links, you don't want plain text. Maybe you want a markup language that's closer, but if you want features other than characters and line breaks, it's not plain text.

[Korev]

Re: would like to see a switch back to plain old static HTML

Me, I want to dump some Markdown in a folder and have it magically appear on the web, without anything interpreted in anything involved in between. No JS, no PHP, nothing that isn't type- and bounds-checked native code, thankyouverymuch.

Have you seen Hugo?

[Liam Proven]

Re: would like to see a switch back to plain old static HTML

> Have you seen Hugo?

TBH, no, I haven't, and it sounds quite interesting. Thanks for the link!

I will have to see if the deeply new-thing-sceptical friend who hosts what I laughingly call my website would be willing to install it. He won't allow anything written in any form of PHP on any server he runs, is very suspicious of Ruby, and dismisses containers and most 21st century tech.

(Said website is really just a rescued mirror of my nearly-3-decade-old home page, and apart from changing a few dates, I've not touched it this century.)

[John Smith 19]

"generating new static files every time new content is added"

Storing them in some sort of IDK server-side cache?

I find it very hard to believe that most (all?) CMS's do not offer this option already*

Regenerate-on-demand is a strategy when memory and storage is scarce and processor cycles are quite plentiful. Which might be the case for a web page that's read by millions of viewers simultaneously so you want every resource to be contention-free.

Except do you really have literally one-processor-one-viewer on those massively read sites?

And while sales presentations will no doubt tout this as a benefit who really needs this level of load. IMHO a lot of the time the biggest load on the servers is the CMS itself. The CMS task is starting to look to me more like an enhanced make utility + file system structuring problem.

*Hidden away down the obligatory umpteen levels of menu options head "Other stuff" or something equally uninformative.

[Philo T Farnsworth]

I dunno. . .

What that means is that you can plug it into Visual Studio Code – or many other LSP-compatible editors, from Emacs to Kate to Vim.

If I have emacs, what more could I possibly need?

[Liam Proven]

Re: I dunno. . .

> If I have emacs, what more could I possibly need?

A usable, ergonomic user-interface that looks like it's at least from the 1990s?

[Philo T Farnsworth]

Re: I dunno. . .

I was mostly joking with that comment but, admittedly, only mostly.

I don't want to start an editor war but. . .

I develop and maintain a complicated web application that's thousands of lines of JavaScript, HTML, and python¹ and do it all with emacs.

I've tried several IDEs and they all just introduced unnecessary complication and generally got in my way.

I find emacs to be as ergonomic as I need it to be -- my hand doesn't need to reach for the mouse every couple of seconds since the CTRL key is right there by my pinkie. CTRL-X CTRL-S is so instinctive that half the time I don't even know I've saved my work

Just for example, show me an IDE that will allow me to split a window vertically or horizontally so that I can look at two (or more) parts of the code at once or pop an entirely new window if need be and I'll be happy to look at it.

Your mileage may certainly vary and if you don't like emacs or like something else better then, well, I'm not in the royal line of succession, so I'm not going to attempt to tell you you're wrong. I like what I like because it helps me get my work done and stays the heck out of my way.

_______________

¹ Don't blame me. I inherited it and I've been thinking about a rewrite but the scientists that use it are happy with it and if they're happy, I'm happy.

[Boothy]

Re: I dunno. . .

Quote "Just for example, show me an IDE that will allow me to split a window vertically or horizontally so that I can look at two (or more) parts of the code at once or pop an entirely new window if need be and I'll be happy to look at it."

Visual Studio Code lets you do this, just right click on the tab for an open file and select 'Split <direction>", options being Up, Down, Left or Right. You can do this multiple times, so could have the same file open in multiple sub windows, 2, 3, 4 or more times, each one having it's own scroll bar etc.

Grab any of these tabs, and pull it off the main window, and you now have an independent window, you could then drag this over to a 2nd monitor for example. (and yes, you can split this now separate window).

[Philo T Farnsworth]

Re: I dunno. . .

Okay, I'll honestly give it a try. I downloaded and installed VSC (holding my nose a bit because. . . ugh. . . Microsoft).

I will point out that emacs allows me to split a window with CTRL-X 2 and pop a new window with CTRL-X 5 2 (I had to check because I do both so automatically that I honestly wasn't sure of what the keystrokes were). No right click this, choose menu that but, hey, I still drive a car with a stick shift, too, so again, your kilometerage may vary.

And with that, I shall CTRL-X CTRL-C my participation on this thread and go find something useful to do, like laundry.

[Roopee]

Re: I dunno. . .

> it’s Microsoft

Use the MIT-licensed version called VSCodium instead - still MS but without all the telemetry etc (which is added after, by MS, to produce VSC.

[Boothy]

Re: I dunno. . .

Thanks, wasn't aware of this version, and a quick look and VSCodium is in my software manager (Mint 22), so will give this a go.

[Splod]

Re: I dunno. . .

Try Vscodium. It's supposed to be the true opensource version without MS telemetry reporting back to Redmond control bunker!

[Beeblebrox]

Re: I dunno. . .

> I don't want to start an editor war but. . .

I can't hear "editor war" and "emacs" without saying "vi".

However, I'm so over old fashioned editors (ed, please move along).

[PerlyKing]

Re: I dunno. . .

vi vi vi - the editor of the Beast!

[Liam Proven]

Re: I dunno. . .

> an IDE that will allow me to split a window vertically or horizontally so that I can look at two (or more) parts of the code at once

MS-DOS 5's EDIT.EXE, released 1991?

[Chris Gray 1]

Re: I dunno. . .

... and I've been writing games, compilers, run-time systems, etc. etc. for decades using only emacs. Occasionally a quick edit in another directory will use vim. However, I did get quite annoyed when first using emacs: I mis-shifted on save-all-buffers and got some kind of email package started instead. Without asking, it took all of my email inbox and moved/changed it to elsewhere. Quite annoying. I used "describe-bindings" and built an emacs startup file to disable all of the keybindings I didn't use (and of course the vast majority I'd never heard of). Over the years more basic bindings have been added to emacs, but I haven't updated that startup file - my fingers know better now.

[Philo T Farnsworth]

Re: I dunno. . .

I wasn't going to return to this thread but it's been bugging me all day (yes, I need a life).

With all due respect, if Mr Proven would be so kind to amplify his criticism of emacs, I'd really be interested to know what he doesn't like about its UI.

Yes, I'll freely admit it is not the most intuitive -- there's a substantial learning process -- or user-friendly of interfaces (or perhaps, it's just choosy about its friends?) but, as someone pointed out, the only truly intuitive user interface is the nipple. Everything else is learned.

The fundamental automobile interface (steering wheel, gas and brake pedal) haven't changed in about a century, plus or minus, which leads me to assert that an changing user-interface is not necessarily a good thing -- would you want to learn to drive all over every time you got into a different car?

My personal choice of emacs is admittedly idiosyncratic and perhaps a bit lazy -- I've learned to use it and don't feel compelled to learn a new UI just to learn a new UI that may or may not bring a whole lot of advantage to the party.

Anyhow, if Mr Proven has a spare moment, I'd be willing to be educated.

[Liam Proven]

Re: I dunno. . .

> Mr Proven would be so kind to amplify his criticism of emacs

Sure. Did that in 2021.

https://www.theregister.com/2021/12/17/tilde_text_editor/

[Philo T Farnsworth]

Re: I dunno. . .

With all due respect, the word emacs only appears once in that article and doesn't really address how emacs fails ergonomically or really ergonomics or UI considerations in any great detail, either. Perhaps I'm missing the point (an admittedly not unheard of situation).

Re: window splitting, that was, (a) the first example that came to mind and (b) I believe emacs predates MS-DOS 5's EDIT.EXE by a significant number of years -- emacs was, after all, a replacement for teco (sort of).

Regarding fingers, mentioned elsewhere in this thread, mine were formed in the late 1940s and I met my first computer in 1966, an IBM 1620 (don't ask), complete with IBM Model 029 Keypunch, if that gives me any cred (or discred?), and first learned emacs while working on a Cray Y-MP/48 running UniCOS in the late-ish 1980s, so maybe I'm just an old geezer who isn't going to change no matter what anyone says. . .

Again, I'm not pounding the table and saying everyone should eschew their favorite IDE and change to emacs. I'm silly but not that silly. I don't think there is One True Editor.

If it gets your work done, enjoy, please.

But it works for me.

[PRR]

Re: I dunno. . .

> A usable, ergonomic user-interface that looks like it's at least from the 1990s?

But my eyes, and fingers, are from the 1950s. Were fully mature in the 1970s. There were some further economic and technical changes but nothing huge. The people who developed the TeleType, the VT-52/ADM3a and their apps were not stupid. Most keys to be within pinkie-reach, not scattered like throwing dice in the sea. I'm not convinced any real UI work has been dome since Xerox/IBM/Apple CUI(s).

(Personally, I can't work emacs but only because I am not smart enough to handle it, not even to shut-down without core-dump.)

As for a later comment about splitting a window, file, or files for long-range close comparison-- don't most programmer's editors do this? Maybe too eagerly (for my small mind)?

[Liam Proven]

Re: I dunno. . .

> But my eyes, and fingers, are from the 1950s. Were fully mature in the 1970s.

Mine were a decade later.

The thing is, keyboard design wasn't mature until the mid-1980s, and software end of the 1980s.

Which is what I covered here:

https://www.theregister.com/2024/01/24/rise_and_fall_of_cua/

[Androgynous Cupboard]

Making things simple is very difficult

That's basically the issue in a nutshell. It is far, far easier for developers to keep adding things other people have made until it works, than to make it themselves from an empty file. Which is why we have JQuery, Bootstrap and a million other frameworks that take you one step away from the actual website, and why those sites we have 25 nested DIVs where one would do.

I'm also going to put up my hand and say there's nothing wrong with JS. Simple JS is all you need for things like rolling quotes from customers, auto-generated indexes of blog article and so on. If you need that stuff, it can all be done client side easily enough. The problem comes - again - when you buy into the framework-du-jour to do this, which locks you into a process that is "making things simple" in a complicated way.

I had an email from a potential customer a few months ago asking if we could do some processing on his website, and sent me a sample page. Flat content clearly generated from data server-side, but no bells and whistles on the page itself. It was delivered with over 1MB of CSS, minified of course "for speed" so you wouldn't benefit from any cross-site caching. Absolute nightmare. Who was it that said when sculpting your start with a block of stone and stop when you've revealed the statue within? Websites, apparently, work the other way - start with nothing and keep adding things until you have something approximately the same weight and utility as a block of stone.

[CowHorseFrog]

Re: Making things simple is very difficult

WHy is using js bad ?

Why does it matter how little or much js is used ?

[Neil Barnes]

a collection of static HTML files and one or two CSS files. No JavaScript anywhere.

Damn. I've been doing it the hard way. Apparently.

[tiggity]

Vanilla web site

I run one that's basically HTML and CSS (with a few server side includes of various .txt files so lots of stuff can just be uploaded as plain .txt files, though as all content in the .txt files is rendered as HTML any HTML markup will get processed. *)

This is for a club I am on the committee of and I update all the league & cup results and tables & so site can be nice and simple.

I have some simple code thats allow automated markup creation and upload of results / tables to the website based on results that are sent in to me (obviously, as the time spent automating saves hours and hours of hand crafting markup in the long term, relies on correct format used by people sending in results )

So, no JS anywhere, all works fine, only attack service is FTP access to the web server (plus chance of zero days / config issues on the hosting server - its not my server that hosts it, so no control over that)

Unfortunately have to use such stuff as react, angular etc. in day job, so club website makes a nice change to deal with a simple, streamlined site that loads & renders "instantly" & pulls in nothing from CDNs or similar & works for people with JS disabled & will work on any browser (within reason, e.g. if you unearthed a fossil such as original pre CSS being a thing Mosaic browser then layout might look a bit odd as CSS would not work, but nothing would actually break & all content visible ).

* If other committee members want to update content on the general information pages they can just upload appropriate .txt files via FTP (I have a little front end that makes it easy) - and as they aware that HTML is supported some use their own HTML editors to format the text (sadly, one person uses word and its ability to export / save as HTML, which creates awful markup)

[DanielsLateToTheParty]

Frameworks, eh?

For whatever my sins were, I've been issued a site with Tailwind CSS. It tries to be minimal by only having a single CSS rule per class name. So now you get to enjoy the prospect of HTML made up almost entirely of class strings.

Here's an actual example from their boasting ("It's tiny!" they declare) web page:

<input class="focus:ring-2 focus:ring-blue-500 focus:outline-none appearance-none w-full text-sm leading-6 text-slate-900 placeholder-slate-400 rounded-md py-2 pl-10 ring-1 ring-slate-200 shadow-sm" type="text" aria-label="Filter projects" placeholder="Filter projects...">

Thank heavens they didn't use inline styles or that could have ruined everything.

[Ken Hagan]

Re: Frameworks, eh?

"Thank heavens they didn't use inline styles or that could have ruined everything."

Indeed. That would have been an abomination.

[CowHorseFrog]

Re: Frameworks, eh?

Having a class with a single css rule is plain stupid, you might as well just inline the rule or property and value and save the indirection.

[Kubla Cant]

Re-use and encapsulation

Commercial-scale software engineering always benefits from re-use and encapsulation. Doing everything with static HTML is OK for a small number of pages. But a big site with extensive commonality and a complex UI is going to be slow to develop and hard to maintain if it's just a collection of massive HTML scripts.

Syntax errors are the least of the problems when creating HTML pages. Getting the look and behaviour to meet requirements, at all scales, takes a lot of effort (for me, at least). And then you have to change it....

[CowHorseFrog]

Re: Re-use and encapsulation

The way HTML documents work is broken. The attempt to make everything as terse (aka styling and inheritance) as possible makes for a very annoying and time wasting dev eloper experience when one wants to start changing rules that are everywhere in the app, because changing a single css prop can have unknown consequences because it might just change something unexpected.

[Anonymous Coward]

Re: Re-use and encapsulation

Yes, it also bugs me when I try to speak French, and they have all these weird words and constructs that aren't the same as in English.

HTML works exactly as intended - and for good reason. In fact, the HTML horrors are caused by people with your attitude to it. You are thinking of "visual web sites on browsers" and the "best viewed in IE6" mentality - the majority, sure, but not the point of HTML. If that bugs you, use a different format. PDF may meet your requirements.

Oh, and changing a CSS property will only affect everything if that's how it's setup. That's the "cascading" part that allows you to change the look and feel of a whole site it a consistent way.

There's nothing stopping you individualising CSS elements and removing propagation.

[CowHorseFrog]

Re: Re-use and encapsulation

AC: HTML works exactly as intended - and for good reason. In fact, the HTML horrors are caused by people with your attitude to it.

cow: My attitude ?

The horrors are caused by fuckwits like you that dont appreciate how fragile cascading causes a change over here in one rule might end up targetting other elements because the rules are not targetted enough or the cascading selects far more than t he original author cared to think about.

[Rich 2]

I don't do a lot of web stuff, but I have my own website I maintain and am just reworking my wife's website for her business. And in all cases, I follow the "collection of static HTML files and one or two CSS files. No JavaScript anywhere" principal. Maybe occasionally a bit of javascript but not very often and only when I really can't find another way with css (you can do an awful lot with css if you bother to try)

I'm fully behind any drive to get rid of the hideously bloated interweb we have created for ourselves but I'm pretty sure that sorry ship has long-since sailed

[Ian Johnston]

I maintain a website for a non-profit organisation which I wrote in static HTML over one afternoon nineteen years ago and which has had minimal changes since. It looks a little ... old fashioned ... but works on any browser and requires minimal storage and bandwidth. We keep thinking of updating it, then we find something more important to do.

[s. pam]

Acronym bollox

I'm sorry El Reg writers but the acronym % is too high in the article to keep my attention!

[Korev]

Re: Acronym bollox

What's wrong with TLAs?

[t0m5k1]

I gave up on CMS, and other frameworks and just use Hugo or Jekyll where possible. Once you get used to how it works and you're set on the theme all is well.

There really is no need to use some whizz bang fancy framework if all you need is a simple site to give a message or point customers to relevant portals and contact details.

Add to that the ability to spin it up in a docker it just becomes a very lightweight, naturally secure no brainer change.

[Luiz Abdala]

Optional application of the fonts you chose in Frontpage.

For some odd unspecific reason, I only remember trying to use Microsoft Frontpage some 35 years ago, and it royally messing my choice of fonts up. I mean, I specifically go into the HTML code, place a font choice on specific parts, and it just deletes the tags. No respect. No matter NOT doing it in code, it would not save the page with the formatted fonts on it. Just opening something in it would mangle any page. That was in the Netscape days, but still, it was a rude behavior.

I have no reason to believe Micros~1 has evolved any bit in that time. But eh, back on topic, whatever tools are available these days should simply not even let you worry about HTML code at all, but it lets you tinker down on it anyway. Right?

[Liam Proven]

Re: Optional application of the fonts you chose in Frontpage.

> Microsoft Frontpage some 35 years ago

So, 2 years before timbl released HTML 1.0 and a year before Windows 3.0 was released?

My my, you _were_ an early adopter.

[Anonymous Coward]

Re: Optional application of the fonts you chose in Frontpage.

Indeed. Wikipedia claims the first release of (Vermeer) Frontpage as November 1995 (with Microsoft buying the company in Jan 1996).

Having horrible flashbacks of fiddling with getting Frontpage server extensions working on Apache probably around mid 1996. Those were (unfortunately) the days eh?

[ecofeco]

Re: Optional application of the fonts you chose in Frontpage.

I have those exact same scars (Frontpage, Apache). It started my hate for M$.

[John Smith 19]

"It started my hate for M$."

Indeed.

A lifelong passion for many who've had to clean up the messes they generate.

[steelpillow]

"In a distant and better-forgotten era"

Nope. I still do it today. I maintain a moderate-sized 100% static website using the text editor of the moment - currently MATE's Pluma. HTML, CSS and that's your lot. Code highlighting but not code completion. Sheesh, how I hate smart "completion" algorithms, they so get in the way.

Back in the day, tools like the text-based Arachnophilia and the multi-mode HoTMetaL Pro added valuable productivity, but nothing today matches up to them. In particular, HoTMetaL Pro offered a "Tags-on" semi-WYSIWYG mode which was invaluable for cleaning up copy-paste muddles and the like. Just enough completion to close containers in a dumb, predictable way, and easy as pie to drag-and-drop stuff in and out if it got the closing location wrong. Seamonkey Composer is the only F/LOSS tool I know which still offers tags-on, but that is still stuck in a half-baked and buggy transition to CSS and HTML3/4.

[Rich Harding]

Re: "In a distant and better-forgotten era"

My cursory scan missed your mention of Arachnophilia, which I've just name-checked myself :)

[Uncle Slacky]

Re: "In a distant and better-forgotten era"

I'm in the process of setting up a new site entirely using Seamonkey Composer, it does everything I need.

[Peter Galbavy]

I thought this was what hugo was for? markdown to static site...

[Anonymous Coward]

A couple of years ago I suggested a rebuild to a client for a site I built in the early 90s when hand-coded HTML was the only option. He said "if it ain't broke don't fix it" he was perfectly happy that it was fast and effective. So I tried it with an online speed test, I was disappointed to find it only scored 99 out of 100 (of course I was unhappy so I fixed that missing 1%). It left me thinking maybe there's something to be said for building sites as if we were still reliant on dial-up modems and doing away with all the bloat of current technologies.

[Lomax]

Allaire Homesite

...nuff said.

[Rich Harding]

All of the pixel for pixel cross-browser compatible HTML used on the original BBC ReviseWise and BiteSize CDs - of which several million ended up in circulation - was hand-coded in Arachnophilia. (Tables were *definitely* involved - we're talking Netscape and IE4 and 5 here!)

I don't do that much web work these days, and as a consequence my self-built CMS - originally in ASP and ported to PHP in 2004 - is only now in use on a couple of personal sites. The most complex site for which I'm responsible uses Yii2 (coded mainly using Geany), which I quite like, but everything else is hand-crafted, tiny, and fast.

[ecofeco]

Built my first websites with Netscape Composer!

I miss those days that you could use something that was free, to make something millions of people could see AND use! And the biggest hurdle was how reliable the FTP was of your hosting company and how fast you could make your website load on user's dial-up modems.

(and of course the cost of an ISP account)

[Anonymous Coward]

I just wrote my own TLS terminating reverse proxy application server lib that can either serve static assets deflated in memory embedded in the data section of the executable or from file. It also includes an in memory object database that hoses SQLite, LMDB or take your pick, it can do 50 to 100m range lookups pers second has lock free read and write and works via pointers. it automatically serializes the declared runtime structures to JSON with no intervention from the user, structures can also include arrays, list, hash tables, bloom filters or tries for persisting to disk or syncing to JS client side. No DB schemas, No CGI, No script languages required, just bung in a runtime function tag for the html page preprocessor to call the named runtime function to generate the html from posts or gets and add dynamic URI endpoints to handle whatever else you want. It compiles for linux, windows, mac and arm, deploy it as an desktop application with web gui, bung it in the cloud, run multiple websites from home. Zero configuration needed. Result exe is 1.9kb plus TLS shared objects.

Why anyone needs lamp stacks, scripting languages or sql for simple websites or applications is beyond me, it's like banging rocks together and grunting incoherently. The only down side to this it that I currently have to suffer escaping double quotes in the html and being a dyslexic trilobite I don't know if the html is valid or not until I recompile but that is at least blazingly fast. so its just a case of trial and error and error...so if I can plug in a html validator into my IDE well that would be great.

If only I had half a brain left and could code in a commercially acceptable language de jure I'd probably be offered a big bag of cash for my efforts but then I also need a Hannibal lector mask and restraints in public, lest I scream or yell obscenities and offend someone or do a proper agile scrum Rugby Union style and try to bite an ear off.

[steelpillow]

Why anyone needs lamp stacks, scripting languages or sql

Back in the day, clicky buttons required either semi-absolutely-positioned clicky transparent overlays or javascript OnMouseover stuff. Nowadays CSS handles that, but is still very bad at drop-down navigation menus. If you wanted reusable page content, to save pushing out that same nav menu on /every/ page, framesets were your friend. But they did not do stateful bookmarking, so instead of fixing http for that they killed framesets and substituted loads of crap. iframes are about the best left, but still pigs. To make these things user-frendly, you still need scripting.

I guess that if you want things like a site search feature or an email toy which hides your address, then LAMP+SQL would be handy.

So sites like yours and mine are pretty limited in the user experience we can offer.

[CowHorseFrog]

Many exploits happen on the server, so whether the server outputs HTML or JAVASCRIPT or anyting doesnt change this basic fact.

[John Smith 19]

This reminds me of the Shuttle control software......

Let me explain.

The original Shuttle launch SW used a "Tilt table," basically like the parameter map in a cars EMU but in 3d. It was essentially an open loop system that ignores pilot input till you get to orbit.

V1.0 used an "average" set of upper altitude wind levels during the ascent but this was inefficient. These can be wildly variable throughout the year, resulting in payload reductions of 100s (1000s?) of Kg. So improvements were possible, but how to do them? A)Gut the software and replace with an "optimal" onboard guidance package B)Develop offline SW tools to build a new tilt table on the day, then upload it securely.

Here's the thing. Both options demand significant verification efforts (NASA Wallops and Goddard do world class AI for mission operations and "optimal part" design work)but option A involves radical change to the vehicle software. B leaves it intact. This was not a trivial amount of effort.

NASA went with option B and Day-of-launch-I-Load-Update was born. The I-table ("Information") layout is the same one as the 1970's, but the SW to fill it was developed 20 years later.

IMHO the CMS task has much in common with this scenario. It looks to me like some of these CMS's are acting as very large interpreters of user input rather than building a near-static page image, IE more like a make utility (IE Option B in the Shuttle SW case).

I think the key challenge which is CMS specific concerns what happens when an object on the server is moved somewhere else, renamed (for some reason) or just flat out deleted. Logically the developer wants to add such an object in insert-"Thingy.jpg"-regardless-of-where-it-is-or-not-if-it's-been-deleted mode. If something happens to that object outside the page that flags the page as "dirty" and needs to be regenerated, either the first time it's called, or during a "quiet" period (whenever that is). Shades of ELF scripting?

This is pretty easy in the interpreter model where everything is dynamic, but possibly much harder in compiled mode. A tradeoff most companies that develop CMS systems seem quite happy with.

Just my 2p's worth.

[devongarde]

Wrote my own validator

Having had too many issues with CMSs (such as required patches breaking everything), I hand built my own website in static HTML, CSS, etc.. It's rather big. I found I made too many mistakes, and, worse, I felt none of the validators were up to scratch. They ignored most attribute errors, link checkers failed to check all the links, at the time there were no ontology checkers, and so on. In the end, I got fed up and wrote my own website validator (not just pages). This was a bit of a humungous mouthful to chew. I started before covid and it's still incomplete. All the same, I think it's pretty good at HTML, ok at CSS, can verify many common ontologies, and so on--although I might be slightly biased. The main issue is it's a command line tool which you have to build it yourself (with Visual Studio under Windows or gcc/clang under various unii). If anyone wants to have a look, you can find the "static site checker" on github by seeking devongarde ssc, or at it's own luxembourgish site. I really would be grateful for genuine feedback.

[Anonymous Coward]

Coyote Linux

Anyone remember (or used) Coyote Linux? It was a single floppy disk Linux distro with a fully functional web server. Absolutely slick. You could bring it up on an old cruddy desktop PC, server a fully functional web site, and be fairly certain it wouldn't be hacked. No, not overly powerful, but if you just wanted some static pages up it was perfect. Too bad it went the way of the Dodo. Would be lovely to see it resurrected at some point.