Using modern HTML and CSS will get you pretty far these days.

For example, dealing with forms used to be problematic in a few different ways without JavaScript or something server-side.

Now form validation can be done with CSS [1].

For example, static site hosts like Netlify have services for dealing with the form data [2]. 100 free form submissions per month.

I agree that tooling is out of control. Jekyll [3] is great for getting started with building static sites. When using Jekyll, my build tool of choice is a Makefile [4].

[1]: https://webkit.org/blog/13096/css-has-pseudo-class/#styling-...

[2]: https://www.netlify.com/products/forms/

[3]: https://jekyllrb.com/

[4]: https://blog.mads-hartmann.com/2016/08/20/make.html

It's pretty amazing, HNers' capacity to read a request that includes a clear, concise (and satisfiable) requirement—no frameworks—and then dozens of respondents write up answers predicated on the use of this or that framework, thus contradicting the entire premise for the question.

  article a :has_("click here ")

That, and I'd like some way to punch through shadow DOM, because as far as I can tell, elements in the shadow DOM cannot be addressed by userstyles at all, which prevents me from fixing annoyances in some webapps (looking at you, Gerrit).

  news.ycombinator.com##a:has-text(Hacker News):style(color: green !important)

  //article//a[contains(., "click here ")]

  document.evaluate(
    '//article//a[contains(., "click here ")]',
    document,
    null,
    XPathResult.FIRST_ORDERED_NODE_TYPE,
    null,
  ).singleNodeValue

See https://www.w3.org/TR/1999/REC-xpath-19991116/ for the syntax, and https://developer.mozilla.org/en-US/docs/Web/API/Document/ev... for document.evaluate(). You will sadly not find a great deal of other useful documentation.

As for shadow DOM: yeah, you can’t target closed shadow DOMs at all in any way, by design. Fortunately most are open so that it is at least possible to get into them, even if it’s a pain since the normal tools can’t pierce the boundary.

—⁂—

¹ If you wanted to only match “click here ” in an immediate child text node of the <a> element, these four work and are equivalent:

  //article//a[./text()[contains(., "click here ")]]
  //article//a[text()[contains(., "click here ")]]
  //article//a[contains(./text(), "click here ")]
  //article//a[contains(text(), "click here ")]

I like the MDN for quick reference but the actual HTML spec is actually quite well written and has lots of useful examples [2].

[1]: https://open-props.style/

[2]: https://html.spec.whatwg.org/

As an example, on their site, they’re sending about 68/12KB gzipped of styles. Some are already unused and could be removed by straightforward dead code removal. Inlining variables that are set only once and removing their definitions (which incidentally encompasses that dead code removal) reduces it to 40/8KB which will both transfer and evaluate faster. (A further 20% of the styles are also unused and possibly sanely removable.)

A product is poorly-advertised indeed, but which product?

The hate for JS frameworks is usually warranted, in this case I think nuance is missing. It's also not as black and white as people paint it to be, IMO.

But there is quite some projects where you don't even need that.

Learning HTML/CSS/JS is a good idea as ultimately any framework or serverside code will interact with some combination of the three. Having a strong grasp of how HTML/CSS/JS work is the perfect foundation for learning something that runs serverside. And you get there by building projects that predominantly lean on the three. Whether they are private or professional, who cares as long as they are cool and someone learns something from it?

For example angular hello worls is super duper simple. But then business apps become a giant pile of crap, the eprformance goes to shit and sometimes stuff that should work stops working. The issue is the magic, if use a sane library you can just run the code in debugger step by step and see what happens but with magic stuff you get a giant call stack with garbage that is impoosible to understand.

So when I can I rip out magic and replace it with function calls , getters and setters. Maybe is my bad luck that I always have to work on prtojects created by others and all the time this others did it wrong. Nobody can convince me that angularjs1 is a framework designed by competent people with experience in GUIs, maybe the newer version are better if those buys learned on the job what they should have known from the beginning.

I guess once you get into all the hooks and contexts and fancier stuff things might start to be a bit magical. But I like it a lot better than Angular, which I agree is very much overly magicked.

It's almost never warranted.

> In 2008 Crockford published a book announcing his discovery that Javascript, contrary to prevailing opinion, has good parts. He describes this as "heresy", and as "possibly the first important discovery of the 21st century", noting that it came as a "great surprise to the community of javascript developers, and to the world at large." He attributes the discovery to his having read the ECMAScript Standard, which he says "literally changed my life." He also notes that the specification document is of "extremely poor quality", "hard to read", "hard to understand", and says that the ECMA and the TC39 committee "should be deeply embarrassed".

I own that book and I still hate Javascript (it's not the fault of the book). Is there another language with such a book?

[1] https://en.wikipedia.org/wiki/Douglas_crockford#Opinions_on_...

There are many languages that I do not like, but I hate none, so I am curious for the reasons of that strong feeling?

The language is very permissive, making it not only easy to shoot yourself in the foot, but in the head as well. There is no easy way to say that your code is semantically correct because JS will allow it to digest anything. So, unless you do thorough review, bad code can easily get through.

Dependency hell if you're using NPM.

I'd be happy if the community was focusing on implementing some kind of default set of libraries, instead of adding syntactic sugar now and then on top of JS. I remember switching from Java to Kotlin, and the collection API was a real pleasure to work with. But in JS, everyone wants to use their set of libraries. Creating a starter project will get you hundreds of dependencies that you can never vet.

"The language is very permissive, making it not only easy to shoot yourself in the foot, but in the head as well. "

But I am actually not aware of much footguns of the language itself.

That is, if you stick with "the good parts" (even though I share not all the views from the book).

" Creating a starter project will get you hundreds of dependencies that you can never vet."

And it is possible to write clean vanilla js, or stick to limited frameworks. You have to maintain strict discipline though. And nowdays I would use typescript for a new project.

…and then I'll have no reason to dislike this language. Got it. Am I allowed to dislike the newish template literal syntax too?

But you said "hate" before, which is a bit stronger than not liking.

The only time I came close to hating a language, was when I was forced to overtake someones half assed php project.

And I still do not like the syntax and have never touched any php code ever since, but I still do not hate the language, or its designers or users. I just avoided it. But hate has the vibe of wanting to destroy something ..

And well, yes, a nice clean start of the web would not be such a bad thing - if there would be some language or plattform everyone can agree on. Which is likely not happen and will just recreate the mess we have already.

> hate has the vibe of wanting to destroy something

You may be right, and given half a chance…

Perl maybe, if you end up having to re-read some.

The hate for large frameworks is warranted by their poor performance and bloat while struggling to achieve simple objectives in the most challenging ways.

I did miss SCSS though.

1. overview/explanation:

- https://web.dev/learn

- https://www.patterns.dev

2. (hands-on) tutorial:

- https://github.com/microsoft/Web-Dev-For-Beginners

- https://freecodecamp.org

- https://www.theodinproject.com (note: includes React)

- https://fullstackopen.com/en (note: includes React & GraphQL)

- online courses -- recommendation: CSS for JavaScript Developers and Three.js Journey

3. how-to guide:

- https://css-tricks.com

- developer blogs

4. reference:

- https://developer.mozilla.org

- https://javascript.info

MDN: Learn web development - HTML, CSS, JavaScript, Web Forms, Accessibility

https://developer.mozilla.org/en-US/docs/Learn

Once you throw a few input elements and a submit button into an html file, you can use the network tab in your browser's "Web Developer Tools" or "Inspector" to see how the form submission looks over the network.

You will need some kind of stack on the server to interpret the submission and do something, like stash it in a database or maybe in your case just append a string to a file. I like Node and use nothing but its built-ins for creating servers and writing to my filesystem.

Speaking of built-ins, python and php can be good too, they can create and interface with sqlite databases out of the box.

So I don't have an exact direction to point you but feel for you re: crap medium articles. I found it worth paying $25 to https://teamtreehouse.com/ to choose from the many tutorials there, lots of intro content of good quality.

The only thing I focus on is valid markup, accessibility, performance, good error handling, and getting a 100% in Lighthouse. At least I'm doing better than my bank's "modern" home banking app in Angular that breaks half of the time and can't even handle multiple tabs :)

But unless the client wants to manage the content, I agree that MySQL + PHP + HTML/CSS/JS works great for simple websites. I would add git and lint tools too.

If the client wants to manage the content, then using a CMS such as Drupal or WordPress may be required.

Instead, a simpler version control system (something like Git?) would suit you better.

But here's the thing: without VCS, if you ever do need anything slightly more sophisticated... you're on your own.

Yesterday I was helping a friend debug some code from an intro CS class, and I was so stressed out about changing something whithout being able to revert it, because he obviously wasn't using git.

Granted, I really wish there was a mainstream git alternative, ideally simpler, without the more complex features catering to large teams. At least there's a lot of graphical interfaces on top of git, which make it really intuitive to use and can bring the great VCS benefits without the investment of learning git. Maybe simple interfaces to complex tools is a good middle ground.

Anyways just pointing out that it can be complicated to some people and it’s completely unnecessary. I still can’t think of a single problem I’ve encountered over 20+ years of doing this that git would have helped me avoid. My code bases always have forward momentum and rolling back any part is unusual for me. But if I needed to, I have a backup.

Had I followed your advice, the git roadblock would have prevented me from shipping anything.

There is of course situations where PHP isn't a good solution. I would prefer to use something else if something like websocket was important or if performance was critical.

PHP today has about as much in common with PHP from 2005 as today's javascript has in common with javascript from 2005. Languages change.

Such as? (Aside from inconsistency, it's indeed unbeatable at that)

It doesn't maintain state between requests, and that is a perfect match for HTTP.

It's easy and fast to deploy. You don't need to restart things or think about reusing ports to update without downtime.

It's easy to sandbox, making hosting very cheap compared to most other languages.

It's basically "serverless" with really good startup times.

It has better performance than most other interpreted languages.

It has support for many functions that many other languages would require a dependency for.

Development speed quite fast as a result of the large amount of included things.

You can to some degree decide if you want to use strict types, or just ignore it.

It has a large ecosystem with multiple great, feature rich, and battle tested frameworks.

It's has very good backwards compatibility, and it's easy to upgrade large code bases to newer version.

It's documentation is the gold standard according to many.

While it's definetly not one of the coolest or most fun languages, it's definitely one of the greatest for the web. Doesn't PHP run something like 75-80 % of all websites today? Clearly it's doing something much better than others.

PHP may be very inconsistent, but its syntax is also very stable. You don't need to spend hours rewriting your application to use the latest PHP version. I'm not sure if it may have been a good idea to have a "Python 3"-style release, maybe.

I am no latest tech only hipster kid, but making a fast no bloat website this day with modern JS stack is pretty darn easy.

For me it’s hard to evaluate cause I’ve been doing it for years but I’ve recently thought it to a couple of people with no coding experience and they got it.

Seriously, people are terribly close minded about the JS ecosystem and the fame is well deserved maybe but seriously if you have some minimum guidance of what to stick to it’s one of the best and easiest stacks around.

The cool kids dunk on both of them.

Are you talking about static websites, or API-driven? Can you put an example?

This is a surprisingly usable stack, I'm tempted to agree.

Personally, I'm on the fence about using server side rendering (which PHP is pretty good at) versus just writing RESTful APIs, because browsers now have fetch API built in which makes consuming them easy (no need for jQuery or necessarily even something like Axios).

Of course, I might still go for a reasonably feature complete framework like Laravel (which handles certain things that you're very likely to get wrong, like auth/encryption or working with mail queues and such), or Slim (which is a nice option for smaller setups, essentially a micro framework; like Lumen used to be).

> I deploy in production using FTP.

This isn't ideal from a performance or reproducibility perspective, but can be workable. A caveat here could be file permissions, depending who is uploading what and how, as well as copying over files that should perhaps be transient (e.g. vendor directory, when you should be using Composer or something like that instead).

Personally I'd go for containers since writing a Dockerfile and shipping/running a container image (even with just Docker or Docker Compose, or Docker Swarm) isn't all that hard. If nothing else, it works wonderfully for getting as many databases up and running as you need, running different versions with different ports in parallel, managing resource limits, configuration and so on.

> My version control is ZIP files in some old hard drive.

This is a very counter cultural stance, that may or may not border on insanity in the eyes of those who want to exaggerate for the sake of an eye catching sentence. Others might joke about file names like code_2022_11_17_release_final(1).tar.gz.backup2 which this workflow might lead to.

Personally, I think that this is just a bad idea, even when working alone. It's good to be able to see what was changed when and have different changesets that you can easily compare, navigate or merge into whatever solution you decide on. Also, it's very nice to be able to revert granular changes, if that's ever necessary.

Try implementing a feature, realize that after changing 34 files you want redo certain parts and need to revert changes in 14 of them, do that with just a few clicks or keystrokes in Git (or other VCS) solution of your choice.

Version control is just a good idea in most software development cases, period. That said, opinions on how to use it and which system to use rightfully differ, as does what to version, whether to use something like Git LFS, whether you need a web UI of some sort or should you work with patches and so on.

You can do a kind of halfway house with Htmx. Have your backend generate HTML fragments, and Htmx in the browser will inject them into the page without having to do full-page reloads or complex vDom manipulation.

https://htmx.org/

That depends on the target website (or web app), but as a web visitor, I usually dislike having the stuff rendered client-side, it always feels slower. Also, for content-based websites, I like when JS is optional.

https://github.com/no-gravity/web_app_from_scratch

The idea is to have a self-explanatory shell script for each framework, which turns a fresh Debian installation into a running web application with routing, templates and user accounts.

So far, we have Django, Flask, Laravel and Symfony. In various stages.

If you look into the scripts, you see that they are pretty much tutorials in code form. Reading one of them shouldn't take more than 10 minutes. After that, you know exactly what your web app does.

[0]: https://github.com/no-gravity/web_app_from_scratch/blob/main...

    apt install -y python3-django

I would be curious to see which lines you replace this with and if the script runs the same afterwards.

Personally, I run an application either in a container or in a VM. So I never had the need for virtual environments. Does the latest Django version give you something you are looking for that is not in Debian's version?

A benefit of doing it the Debian way is that it is easy (one line of code) and no extra system has to be put in place for updates. As Django is updated along with your OS updates.

    python3 -m venv .venv
    . .venv/bin/activate
    python3 -m pip install django

Do you mean using a premade Docker image that comes with Django installed and configured?

For the front-end you probably want at least a CSS framework. I recommend this:

https://kylelogue.github.io/mustard-ui/index.html

It looks good and doesn't have strange font-size hacks that could make it incompatible with external CSS.

IIRC it's possible to include it as a single CSS file and call it a day.

You don't need JS at all for a simple form.

As for the backend: I unironically recommended PHP. It's a whole rabbit hole of different solutions, but you can always fall back to a framework-less solution. Just be mindful of security issues.

Missing GUI widgets: https://www.reddit.com/r/programming/comments/otixwo/comment...

Mozilla docs didn't quite do it for me but I swear by W3SCHOOLS website.

I also found this guy's website helpful: https://gomakethings.com/

I think the author is on HN; he swears by plain JS.

For me I just wanted to write a simple cross platform app, I decided Dart/Flutter was the way to go in the end.

Don’t read medium. Web world has less order than MSVS world, so you have to settle on a tech stack first and read these manuals. Also don’t think “hey it’s just web, I’ll figure it out”, it’s a path to headaches.

Here is my advice, based on I avoid frameworks but still get it done.

“Just html, css, js” will get old quickly, like in half an hour or so. You want to try it much later, after feeling okay in webdev.

For frontend start with Parcel or Vite, both are zero-config bundlers (as in compile, link, autoreload). You’ll need a separate Node.js-based project for a frontend. Use Bootstrap for CSS, since you can’t css yourself from ground up and don’t really want. Use Sass for CSS (you have it out of box with Parcel/Vite).

After a week or two with pure DOM, take a look at jQuery ecosystem, Mithril.js and Vue.

Frontend runs in a browser and is limited in what it can do.

For a simple backend (it talks to files/db, basically a regular program with an http server instead of gui) there are js and non-js options. Node.js Express. Python Flask. The key idea for searches in other languages is “I want to serve few files and api routes”. Make backend a separate project, web world is not zero-config ready for all-in-one projects.

Read most relevant parts of each manual and don’t visit medium unless you’re “in context” and know what you want exactly, but forgot where it was in a manual.

References: MDN, CSS-Tricks.

Stack: Node.js, Parcel/Vite, Bootstrap.css, Sass, Express/Flask.

This will be a good starter with a straightforward setup.

Sure if it's a single page "app" with just a form you're gonna be fine. But what if it's expanding to two pages? Suddenly you have to maintain at the very least a separate header for two html pages including all meta and resource tags. Web Frameworks take care of that. So my advice would be to at least look at static site generators if you think this is where the project is headed.

HN: No problem, just deploy a container, set up nginx, use Express, VueV3, run the Esbuild Go tool, leverage the MVC pattern and get the dependencies with Webpack, then you need to use a web component wrapper on top of bootstrap and style it with SaSS compiled to CSS - easy peasy!

The only thing you have to watch out for if you are making a public app (but I think you are doing internal) is security- in vanilla you must implement protection yourself (xss, content secuirity policy etc.) and most modern frameworks already either implement that or make it easier to do.

It started as a single page but I eventually broke it out into a few files for organization. The WebGL parts are lengthy and boilerplate-y because, well, that's GL for you. https://github.com/statico/langterm

Even after disabling it, though, it's just a blank screen (Chrome on Mac).

Clicking "Use text mode" does work though and brings you to a console.

I think lit is really a library that deserves more attention since it's so good.

Unless you simply want server rendered html, you can achieve that easily with htmx to get a bit better experience. Then you may use whatever language you want and just return html.

This is not the answer you are waiting for but hear me out. If you plan to write some code beyond that single one page then I would really, really recommend investing time in a *simple* framework that does everything.

I use Quasar for any application/page I am writing. It is based off Vue3 and provides plenty of components. Anything beyond 3 lines of HTML (literally) becomes a Quasar app. Yes it is overkill. yes it creates big apps for a simple content. yes, yes yes.

But it also means that whatever problem I have, I have a solution that works everytime and I can scale up if I need to.

I have applications with a form and a button. I have applications that became PWAs. I am not a developper so I did not have a clear idea at the beginning what the effort or future would be.

Quasar helps me to not worry about that. A form and button application is 5 minutes. A 1à forms and 3 buttons and some processing is 5 minutes. Making a PWA and mobile app from that is 1 more minute.

Your form suddenly transforms into a monstrosity where users want to see the time, weather and the result of 16x34. You got it covered.

My case is a very specific one (an amateur dev who wants to have a good hammer to be able to see all apps as nails). Quasar fits the bill.

I like this approach for simple websites, and it can be a very useful learning exercise, but I don't think this is enough to find a job later.

Presumably, you will need a back-end and you could do the front-end in either browser-land or server-land. If you're a back-end or systems developer by background, do it in the back-end. Get a well featured back-end tool to do most of this for you. Django, Rails etc. If you want realtime UI updates (form construction, validation hints), think about a "hot HTML loader" paradigm such as Hotwire[0]. IIRC, some/all of Hotwire is built into Rails now.

CAVEAT: I've been too deep in js-land to know if Hotwire's any good. It's the one I'd look into first from having read around a little. Svelt second, but I suspect Svelt has got too much "build time" tooling for your size project & coding preferences.

[0]: https://hotwired.dev

You can get a lot done with no /low code tools, heavy frameworks like django and rails are really not needed.

Nowadays it is to create a zap webhook and point your form there.

My point was that this is not and has never been a complex thing requiring a framework or a complex backend.

I found MDN to indispensible in learning to make web apps. Everything from learning the basics of string/array/date/etc... objects, to modern ES6 modules.

JS/HTML/CSS - https://developer.mozilla.org/en-US/

CSS - https://css-tricks.com/guides/

As far as actually building apps? After 20+ years of programming, I found my own light weight JS code turned into a framework over time for building apps the way I wanted to. Mostly vanilla JS.

But it didn't stay vanilla JS because too many things are hard on your own. Since everything you build you have to maintain, I found it easier to use jQuery years ago with all it's extra tools. Today? I am still removing jQuery from my code, as vanilla JS does everything jQuery did for me. (I stopped using their widgets as soon as browsers supported features by default, like a proper date picker, etc...)

So, my advice, start from scratch. learn all the pieces one at a time as you need them. This will keep you from getting overwhelmed.

Are their good resources for these from scratch online? Sure, but maybe a book is a good idea here, as it forces a more basic linear learning process if you start at the beginning. Not sure I'd take this route, but it may work for some people.

To your original question - no, I don't know of single source. But no, you do not need Node. You can create an html file and load it directly in a browser, you don't need a server to get started. But this is just step one...

I say this because where you're coming from you're used to plopping down a dialog and throwing components like forms and buttons and such on it. With plain HTML and CSS it is much, much more free form and you can easily be paralyzed by choice or indecision with how to design or even just how to layout components. With a framework like bootstrap you're given layout primitives like a grid and higher level components like a navigation bar, menus, etc. which are much closer to what you're used to from C# and windows.

Then you can layer on HTML, frontend JS, and CSS. With modern typescript you can definitely write pure JS and be "fine".

That said, after a while once you grok how it all works, I would try React.

> Do I really need Node?

As an alternative, you could look at using a vercel template with some sort of out-of-the-box cloud database. These are super simple to get started, although they go against your goal of not using frameworks for the most part. https://vercel.com/templates

The one thing I haven't seen mentioned and would recommend exploring for OP's use case is: Github Pages. This would probably be perfect for serving the type of site they're describing and would eliminate numerous layers of complexity. https://pages.github.com/

So you have the client webpage, this can be a really simple webpage without any style that just has several form tags (Reference: https://www.w3schools.com/tags/tag_form.asp).

Then you need to send this data to some place. You can use standard html actions to do this to a back end script, a rest api, or even to a formatted email that will be sent via the user's email client.

You may need node to code the back end if there isn't one you can use. You can also use google sheets. See example here: https://github.com/levinunnink/html-form-to-google-sheet. This is really only useful for a small prototype so at some point you would need to standup your own backend somewhere. That gets more complicated because now you need a script (could be JavaScript & node for example or PHP or anything else) which processes your form request and stores it to a database someplace else.

Good luck and happy coding.

Then focus on learning the backend as you are going to need that anyway.

Learn basic HTTP concepts if you don’t already know.

Then add JS sprinkles as needed to improve the app.

Google the things you need as you go.

Do a JS course or book if required. Then MDN and the ES spec are good references.

To make the page refreshes seem like dynamic AJAX updates you can cheat and use HTMX which is a JS library but pretty simple and you might feel at home there coming from WPF.

Here's how to deploy it on a Linux VM. Most of the instructions are about setting up nginx (the reverse proxy). You can follow those instructions to deploy it to a cheap digital ocean droplet for example, or an AWS VM.

Once it's set up it's trivial to deploy by FTP.

Or you can deploy it to Azure, which is simpler and can automatically trigger a release on a git push, but more expensive if you need certain things which force you off the free tier:

https://learn.microsoft.com/en-us/azure/app-service/quicksta...

You can still deploy it to IIS too, but I think the writing's on the wall for hosting via IIS so not sure if it's worth learning.

(Note that this is an answer to this specific comment, not to the OP)

The latest .NET builds binaries that work without needing a framework installed on the server. They are effectively just like any other application, so the same tooling you'd use to kick off any executable will work fine.

A simple option might be to `scp` it onto a server and manage it as a systemd service. Or perhaps stick it in a container (it builds cross-platform so Linux is fine) and use a deployment pipeline. If you need extra options then you can front it with nginx etc, but it will also handle direct traffic itself (including TLS).

For persistence you have the usual cloud stuff, otherwise there's great support for Postgres or even fully embedded SQLite or similar. And .NET is very performant too, so for most use cases scaling vertically is all you'll ever need (except for redundancy of course).

I could go on with other options, but in brief I think that what I'm saying is when it comes to deployment these days being .NET makes it at least as easy as the alternatives, unlike the old Framework days when it was much more 'special'.

(Edit: for a hobby it seems you can get cheap on https://azure.microsoft.com/en-ca/pricing/calculator/ by picking:

Sql DB: East US > Single Database > vCore > General Purpose > Serverless

App Sercice: East US > Linux > Free

Estimated monthly cost $1.27)

Otherwise you can run it on any linux box and install all the dependencies yourself, if you use .Net Core or .Net 5 or higher I think.

And of course you can rent a windows VM and it should run directly on that.

What I don’t see is anyone outside of Azure wanting to support .NET in a serverless way out of the box. Feels like there might be a gap for a Vercel of .NET.

I appreciate that isn't the same level of ease as some other abstractions or serverless frameworks, but it is definitely a mainstream option.

If you’re totally new and getting started, just throw in some code into an html file and double click it!

* Vanilla JS (TypeScript) with tiny HTML and CSS. No frameworks and no unnecessary abstractions.

* A full OS like GUI

* Solves for decentralization

* Provides a script to toggle between support for Node’s CommonJS and standard ECMA module systems

* Easy state management that works better than anything from a large framework

* Super fast. Written for extreme performance. For example the file system search is faster than file system search from the native OS. Page loads with full state restoration in less than 0.3 seconds.

* Fast build and language compile. The full build task takes less than 3 seconds.

* Original WebSocket implementation for better performance and safety with a smart message queue

* Automated documentation management

* Fast test automation with an original test automation solution. Most of the end to end tests executing in the browser executes in about 6.5 seconds for about 280 assertions.

* The node side of the application is command driven from the terminal with interactive command documentation

Feel free to open a GitHub issue if you have any questions or would like to learn more about how I try to solve any kinds of technical challenges.

Do you need a back-end? If so, doesn't need to be written in JS.

React / Angular are for SPAs- single page web apps- load once and you've got the entire client.

No reason it needs to be this way. Just serve the page from the back-end.

Also perfectly fine for it to be an SPA. You can use React, which has some nice features for managing the page lifecycle.

Preact is a much lighter weight React.

Svelte and htmx are both nice alternatives.

The web is complex, but only as much as you choose it to be.

I would also stick with running a lot of the calculations server side. Unless you really need the client interaction.

https://jvns.ca/blog/2021/11/15/esbuild-vue/

Edit: it looks like the kids are calling these "javscript micro libraries" nowawadays

It also depends what you mean by "creating" a form. If you can just choose from a predefined set of templates, it would make things much easier, and you could get away without using a JS framework (or even without JS at all, if you wish - you can use a more traditional approach with RoR, Django etc). But my general impression is that people drastically underestimate the amount of work that needs to be done in order to make a complete app, with authorization, user roles, properly secured etc.

I do also think a single PHP file is maybe the easiest option.

But there are alternatives!

Here's an example application built without heavy frameworks. It is very maintainable and easy to understand: https://github.com/wisercoder/eureka

It uses two 500-line libs:

This is the component "framework", it is 500 lines: https://github.com/wisercoder/uibuilder

This is the router, it is 500 lines: https://github.com/wisercoder/mvc-router

Paste that code into a text file, save it as 'simple.html' and load it into your browser. As you modify/delete/add-to the code, reload it to see the result. This MDN site: https://developer.mozilla.org/en-US/docs/Web is a very good reference.

There are lots of vanilla javascript resources on the web to learn from.

It's not. It's a haphazard collection of hacks and one-off solutions that first grew organically, then not at all, then got taken over by bizarre corporate interests.

> I don’t know what’s a good source to actually get a web app running locally that I can eventually deploy online.

You need the backend part for this that handles for submission. For the frontend you need a static web page with just HTML and CSS.

So I would stop looking at JS to keep your sanity, and look at a simple PHP or Python or Ruby framework/lib that will give you the scaffolding to handle form submissions and templating to create an HTML page. Like Sinatra.

Since you already do .net I presume, you can go ahead and do that in ASP.net :)

Succinct description of the state of the web. Long will this continue.

Sorry, it's true. There are frameworks to make web dev "easy" in terms of less typing, but the learning curve for those is huge. There's lots of gotcha's to work around.

What's really needed is a state-ful GUI markup standard. HTML lacks about dozen GUI idioms that have to be reinvented via JS + Dom, and they rarely do it well, or at least well as a package. Part of the problem is that JS wasn't meant to implement GUI engines; it's not a systems software language.

In terms of references and learning resources, I always go to MDN or javascript.info

[1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guid... [2]: https://unpkg.com

Add some form controls. https://getbootstrap.com/docs/5.2/forms/form-control/

Then if you need server processing, use Visual Studio to create an ASP.NET API to process your form.

To me all that is really missing today in the DOM is a good DOM diff algorithm. Building a DOM fragment from a stateful model is easy. The hard part is updating the DOM currently displayed. the "event ups, data down" model from React is a good architecture at the end of the day, but one needs a DOM diff library to update the DOM efficiently. The rest is classic "MVC" rather than "MVVM". So you'd have to get familiar with Event Delegation as well.

* HTML if you don't already know.

* CSS Box Model, Flex and Grid.

* Plain old JavaScript.

For CSS topics above, there are pretty short videos on YouTube under an hour or so.

If you feel like going sophisticated, encapsulate things as web components. They're mainstream now.

These three above can DO EVERYTHING and everything else boils down to these anyways. Everything else is bloatware.

There are several 'no-code' tools that use a Google Sheet as a starting point (Glide Apps), but ultimately the code runs on their databases, and you end up not knowing what the actual business logic would look like in Javascript.

Even tools like Wappler, that offer a visual layer to build functions, and lets you export and deploy the code yourself, will use their own helper functions to abstract the complexity away from users.

Opensource had community libraries and selfhostable

To be fair that's less of an quick guide and it's maybe dated in the javascript content(who uses jquery today) but it's a beautiful book that showcases how elegant html can be when attention is given to the actual markup.

Reach out if you’re interested. I won’t publish the video for a few weeks, but maybe you could preview it and give feedback or ask questions.

My email address is in my profile.

It is a no-code platform that helps create webapps using a pretty good UI driven front-end and back-end logic.

Feel free to email me. It can be a good choice for the app you want to develop.

I had gotten this template ages ago and I've forgotten where it was from. But for me, it was a revelation how much you could accomplish with plain HTML and CSS.

Whenever I have to create something like submitting different forms, I can accomplish using this template by just adding a form 'action' in the individual divs.

[0]: https://nojs.abhij.it/

This experimental view library might interest you: https://github.com/jehna/longwood

It's usable with plain in-browser Javascript, no other tools needed. You can split your frontend to components and do conditional rendering logic just as with any templating library.

Choose a back-end that includes easy handling of POST requests (Php, Django, Elixir-Phoenix) and ignore all the Javascript garbage they peddle on top.

You don't need a CSS framework or a language that compiles to CSS, you can recreate most modern responsive web-apps with 500 lines of pure CSS and a good understanding of the flex property.

You don't even need Javascript if all you want is simple forms.

I think it's doable and sustainable, and is less likely to break on you in the long run because you're not including a huge chunk of code you're not the primary maintainer of.

Sadly web components APIs are bizarre and unused by most web developers: https://dev.to/richharris/why-i-don-t-use-web-components-2ci...

Moreover, you really don't want web components for a simple form because even form participation is weird with web components.

> You don't need web components to create a simple form.

Yes, we agree. I am saying anything more complex than forms requires web component tech that isn't popular or liked by developers.

No, it doesn't

You can go to State of JS and see the top used frameworks https://2021.stateofjs.com/en-US/libraries/front-end-framewo... You can then tell me how many of them "require web component tech" (hint: only lit uses web components as underlying tech, none of the others use those, and have no intention to)

You keep stating this as a fact with literally zero supporting arguments.

No, web components are not required to build a web app. Web's largest and most successful web apps and web sites have been built before web components even became a thing and keep being built without using them.

> I will change how I communicate -

You are not communicating. You're presenting your personal opinions as facts.

> Nobody has ever said that.

nailer, 1 day ago:

"I am saying anything more complex than forms requires web component tech"

https://news.ycombinator.com/item?id=33638793

---

nailer, 7 hours ago

"Implementing a web app without react or svelte would require using web components"

https://news.ycombinator.com/item?id=33652391

---

Edit. It's also funny/sad that you say "nobody is saying that" to my comment which quotes the exact part were you're saying that.

> I am saying anything more complex than forms requires web component tech

> Implementing a web app without react or svelte would require using web components

Which is true, creating anything more complex than forms *without a framework, as the OP mentions* would require web component tech.

You wrote:

> No, web components are not required to build a web app

What I wrote is not the same thing as saying "web components are required to build a web app".

Occam's razor: I suspect you genuinely made a mistake, and may speak English as a second language, but also are very young or not well developed, so rather than admit the error you're trying to argue with me about something I never stated.

For the third time you present this opinion as undeniable fact, when it is not true in any way, shape, or form.

> What I wrote is not the same thing as saying "web components are required to build a web app".

You literally just said that.

> I suspect you genuinely made a mistake, and may speak English as a second language, but also are very young or not well developed,

Ah yes. First it was calling me a cunt. Now it's ad hominem attacks.

> so rather than admit the error you're trying to argue with me about something I never stated.

Literally, again and again, you insist that complex app require web components (the question of frameworks is entirely irrelevant). When I answer that no, they are not required, you are pretending you provide arguments, calling me a cunt, or calling me "not well developed".

Again:

Even if you build stuff without frameworks, web components are not required. To see proof that they are not required it's enough to look at literally tens of thousands of complex web sites built without them before they ever existed, or since. Yes, tens of thousands of complex sites that were built (and are being built) without web components or web frameworks.

Moreover, the only reason those web frameworks exist is that people reached a certain level of complexity, and packaged that complexity in a single generic solution, and still they don't require web components.

But sure, do go on stating your bullshit opinion as fact with zero supporting arguments while calling people cunts. This will show the world how well developed you are.

> For the third time you present this opinion as undeniable fact, when it is not true in any way, shape, or form.

It's the majority opinion of the web dev world. We ll use components, moving from using React / Svelte / Vue etc to W3C web components is tough, and moving a world without components at all would be very, very difficult.

The existence of some great backbone.js or GWT web app written in 2005 doesn't prove that statement to be incorrect.

If you think it does, say why, but not to me, I'm tuning out. Bye.

https://chrome.google.com/webstore/detail/hn-blocklist/cgphk...

PS. I tried being polite while you did 1, 2 and 3 https://news.ycombinator.com/item?id=33652391. You have zero right to complain about how I conducted myself towards you.

Writing Vanilla JS is error-prone unless you are very disciplined, writing "Vanilla" CSS is OK for the most part, Vanilla HTML is fine. It's best to use some tooling, but there are dozens to choose from.

Please don't hurt OP. They're new to this and want help.

They should avoid web tooling forever if they want to maintain their sanity. It's just a mess of a hundred and one tools that all do half of what every other one does, built by people who just refuse to get along and standardise on the Best Way ™ to do things.

the absolute state of web developers in 2022

You also lose a lot of niceties with DX, like TS and components.

Both companies I worked for in the early 2010's ended up recreating their own (subpar) implementations of what React does.

While I do agree the bar to get started on the web is too high, I feel like it's never been so low?

React and frameworks like Next.js have been great to use. Much better than what I was using back then.

I don't have experience with e.g. Laravel/Ruby on Rails though. Are these any easier to work with?

I want to make a simple app where users can create and fill out a form. ATC test plans, to be exact.

https://www.amazon.com/Single-Page-Applications-end-end/dp/1...

You can go quite far with these, and you don’t even have to strip out all the unused dependencies if you don’t want to.

The included minified bundles will deliver a ton of different swiftly common UI behavior, with super light config, (sometimes just the right html).

As parent said, you can easily add your own custom JS for any given page.

If you want to go deeper into modern JS, such as organizing your code into modules or making use of your own chosen node modules—-forgo toolchains and just use esbuild. It’s great.

I am working on framework to quickly build simple web apps/ui. http://WidgetTerminal.com

Would love to talk to you about your use case. Contact info in my profile.

You'll find that it is unnecessarily and necessarily complex unless you adopt a framework that makes design decisions for you.

I don't have time to do a whole screed about this morning, but do give it a look-see.

PHP, Apache2, mysql ( sometimes, hardcoded)

> Coming from WPF and Winform, I find web development to be unnecessarily complex

The web is actually quite a bit lower-level than that, sadly. Winforms (at least when I last used it in the late 90s...) was actually really nice in comparison, especially when you use it with Visual Studio. Web has nothing quite like the built-in GUI editor in VS, except maybe something like Adobe Dreamweaver -- which is an approximation of a browser's renderer, not an actual pixel-perfect layout engine.

If you're looking to "compose" a web app out of UI widgets -- dropdowns, buttons, menus, etc. -- you might want to consider going one level of abstraction higher and using something like Bootstrap or UIKit or SemanticUI. These are NOT Javascript-extending frameworks the way React or Angular are, they're just collections of very useful UI primitives with sane defaults. You can typically use these just by dropping in a couple <script> and <link rel="stylesheet"> tags (meaning you're staying well within "vanilla" HTML/CSS/JS).

> a simple web app, no React, Angular or any of that. That can’t be too hard right? I’m sure in large scale, that stuff has its place, but I don’t need it.

Actually even for a small app, the right framework can make it quite a bit simpler than vanilla JS. But I won't preach here since you're specifically not interested.

> To me, the browser is the UI framework.

It's not though =/ HTML by itself isn't very useful; it doesn't do interactive things at all without either Javascript or some sort of backend that you POST to. CSS lets you have hover states and dropdowns but it's still not real interactivity.

So you have to choose... do clientside logic (entirely doable in vanilla JS, just tedious as heck and error-prone) or offload it to a backend server of your choice (using whatever language or framework you want; there are many).

> I don’t know what’s a good source to actually get a web app running locally that I can eventually deploy online.

Over the last ten years or so, we've gone from "deploying" web apps to actually needing to "build" them first, kinda like compilation/transpilation + bundling + tree-shaking (size optimization) all in one. But by and large you shouldn't need to do that (have a buildchain) if you're writing vanilla HTML + JS + CSS. That usually just leaves you with a bunch of files that the browser runs directly.

To run them locally, you can spin up a simple web server (something like Apache or Nginx, with or without Docker or Lando or other such containerization services) or if it's really simple enough, just open the file directly in your browser.

To host them online, you just have to upload them anywhere -- the old ways of SFTP still work, or these days there might be Git-based plain HTML hosts (I'm not sure; it's not so common a need). If you're feeling lost as to where to host your files, check out Nearlyfreespeech.net, Google App Engine, Cloudways, Hetzner, DigitalOceans, etc. You can always manage your own S3 instances too and deal with CDNs and DDoS etc. on your own, but why...? No need to reinvent that wheel.

> Do I really need Node?

No. Node is a server-side/backend runtime for Javascript. It replaces things like PHP or Ruby or Java on the backend. If you're making a vanilla JS web app for browsers, you do NOT need Node... unless you are deliberately choosing to make your backend in Javascript too!

The reason Node is sometimes used for frontend web frameworks is just that it keeps the ecosystem in one language, so the frameworks themselves and build tools and developer tools etc. often depend on note. But once the web app is built, it is deployed to the web as regular files that the browser downloads, and Node won't be a part of that final package. It's just used in development and building. But none of that applies to you if you're using vanilla.

> Compared to WPF/Winform this is a mess, or so I hope not.

Web app development IS a mess, because it grew organically from competing interests and incompatible standards. The W3C tried to create standards for a decade or so but eventually Google and then Facebook took over and led the way and reshaped the web in their image instead. These days, web apps aren't really driven by standards anymore, just major corporate releases like React and Next.

It's only going to get messier as Svelte, Vue, etc. compete for framework mindshare and Vercel, Render, Fly, Cloudflare, Deno, etc. compete for hosting & runtimes.

If you're looking for a clean ecosystem to deploy to... web is NOT it.

HTML+JS is super low level and primitive, so all these frameworks arise around it as abstractions to make developers' lives easier. It's questionable whether they actually improve user experience too, unless used very very carefully (and I say that as someone who uses them daily at work).

> I want to make a simple app where users can create and fill out a form. ATC test plans, to be exact.

I'm not really sure what you mean by that... can you explain? Is ATC air traffic control, like for aircraft pilots? Is a test plan just a bunch of files (pdf/docs) or something more? Where should those files go once the form is filled out?

I wonder if this is something you might be able to do more easily in a service like Wix or Squarespace, rather than building your own web app.

It also sounds like the kind of thing an experienced web dev could whip up in a few hours, vs you having to learn the ropes (a decade of chaos)... up to you, of course.

  mkdir -p non-obnoxious-web-server/atc-test-plans
  cd non-obnoxious-web-server
  mkdir src
  mkdir public
  npm i --save express

src/index.mjs:

  import fs from 'fs'
  import path from 'path'
  import express from 'express'

  const app = express()

  app.use(express.static('public', {extensions: ['html']}))
  app.use(express.urlencoded({extended: true}));

  app.post('/atc-test-plan/new', (req, res) => {
    const date = `${Date.now()}.${performance.now()}`;
    try {
      fs.writeFileSync(
        path.resolve('atc-test-plans', `${date}.json`),
        JSON.stringify(req.body, null, 2) + '\n'
      );
      res.send(`Thank you, ${req.body.firstName}! Your ATC test plan is saved.`);
    } catch(e) {
      console.warn(e);
      res.status(400).send(`Your data contained some errors. Please review with your supervisor`);
    }
  });

  app.listen(80, err => {
    if ( err ) {
      throw err;
    }
    console.log(`Server up at: ${new Date}`);
  });

  <a href=/file-atc-test-plan>File a new ATC test plan!</a>

  <!DOCTYPE html>
  <html lang=en>
  <meta charset=utf-8>
  <title>ATC Test Plan</title>
  <style>
    /* whatever you like */
    :root {
      --my-color-1: lime;
      --my-color-2: aqua;
      /* etc */
    }
  </style>
  <form method=POST action=/atc-test-plan/new>
    <h1>ATC Test Plan</h1>
    <fieldset>
      <legend>About You</legend>
      <p>
        <label>
          Your first name
          <input type=text name=firstName autocomplete=given-name
            required
            placeholder="Jane"
          >
        </label>
      <p>
        <label>
          Your family name
          <input type=text name=lastName autocomplete=family-name
            required
            placeholder="Citizen"
          >
        </label>
      <p>
        <label>
          Your callsign
          <input type=text name=callsign autocomplete=nickname
            placeholder="Maverick"
          >
        </label>
      <p>
        <label>
          Your email
          <input type=email name=email autocomplete=email
            required
            placeholder="maverickj@flightschool.skies"
          >
        </label>
    </fieldset>
    <fieldset>
      <legend>About your ATC Test Plan</legend>
      <!-- I'm not an expert on ATC test plans so I'll leave this up to you! -->
    </fieldset>
    <p>
      <button type=reset onclick=DoubleCheck(event);>Clear plan</button>
      <button>Save plan</button>
  </form>
  <script>
    function DoubleCheck(click) {
      const doIt = confirm('Are you sure?');
      if ( ! doIt ) {
        click.preventDefault();
      }
    }
  </script>

  node src/index.mjs

PS - I did this because I love HTML, JS, CSS and their "natural" style.

Ultimately, everything is transformed down into plain old HTML/CSS/JS but there are a bunch of tools we use to make this easier and more stable for users.

---

Let's start with frameworks. You say that "the browser is the UI framework", but it's quite literally not a UI framework. Updating the HTML in a page is extremely tedious. You have to do things like set the innerHTML of elements.

innerHTML: https://developer.mozilla.org/en-US/docs/Web/API/Element/inn...

Frameworks provide an abstraction over these web APIs to all developers to easily update the HTML structure of the page on the fly. An important concept frameworks use is the "virtual DOM", or "vDOM", which is a representation of the DOM (E.g. the page) that is kept in memory. Using a vDOM means you don't have to traverse the DOM tree every time you want to update the page.

DOM: https://developer.mozilla.org/en-US/docs/Web/API/Document_Ob...

If you only have simple effects that only change a few co-located HTML elements a framework won't provide much benefit. However, if you have complex effects that may alter the global state and UI of your app a framework makes it infinitely easier to update UI.

Another benefit of frameworks is Developer Experience (DX). Frameworks use a component model, where you can compose your UI out of multiple components. HTML does not natively support this functionality, so it quickly becomes hard to reason about your page structure. Frameworks also allow developers to do things like selectively render a component without using CSS tricks like `display: none` which styles an element to not appear on the page.

---

Next up is tooling. The tooling ecosystem is quite complex, but luckily these days we mostly don't need to worry about the details.

One of the primary reasons for all the JS tooling is that developers want to write modern JS, but not all users have browsers which support modern JS!

Some users may be on old browsers where modern JS syntax or functions are not implemented and so the page would break. One job of JS tooling is to transpile modern JS or TypeScript (TS) into older JS that is compatible with all browsers.

Another function of tooling is to optimize the HTML/CSS/JS assets. Having large CSS and JS files is not optimal for performance, so JS tooling can automatically minify and chunk assets which makes it more efficient for the browser to load them.

Related to the above, how does our source even end up in a format that is usable for the browser? Our tooling also takes care of that by creating a dependency graph of all our files and external modules then resolving it and bundling everything together (And transpiling it!) into JS code the browser understands.

Node is often involved in tooling because the tools may be written in Node-flavoured JS (Slight differences to browser JS) or you may need a Node process to execute some JS code. However, there are tools that are written in other languages like Go and Rust.

---

Lastly is backend and full stack frameworks like Next.js. This is where Node really matters. Node lets you write JS that can run on a server. It gives you access to things like the file system that are not accessible to JS in the browser.

People often choose to have a Node backend for their JS app because it means they can write JS everywhere, but it's not required. You could have a Java or C# backend and a JS app.

Another reason Node is often used is because it has deep integrations with a lot of frameworks like Next.js so you can co-locate server and client code, and it allows you to write code which is isomorphic, meaning it can run on the server and in the browser.

Some apps require a backend to be deploy because their HTML pages are rendered on the server, like a traditional MVC framework does. Other apps may be purely rendered on the client, in which case you only need to deploy the static HTML/CSS/JS files.

Some newer frameworks will render your components to HTML/CSS/JS pages at build time, meaning you kind of get the best of both worlds. You can use frameworks and the DX that comes with them, but you also get a bunch of generated pages instead of one giant JS app.