Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: Good resource on writing web app with plain JavaScript/HTML/CSS?
185 points by pipeline_peak on Nov 17, 2022 | hide | past | favorite | 193 comments
Coming from WPF and Winform, I find web development to be unnecessarily complex, but I refuse to believe that’s true.

I just want to make 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. To me, the browser is the UI framework.

When I Google around to get started, I find obnoxious Medium articles. I don’t want to copy and paste instructions and throw something together without a clue what’s going on. Mozilla has good documentation, but I don’t know what’s a good source to actually get a web app running locally that I can eventually deploy online. Do I really need Node? Compared to WPF/Winform this is a mess, or so I hope not.

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




Some of these responses… wow.

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


> Some of these responses… wow.

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.


People just love to talk about their favorite stuff... They have the right to post it, but I also have the right to ignore their suggestions


It can be pretty tiresome and there are some topics I just never bother reading because they are inevitably full of humanbot autoresponses. Anything to do with note or mail apps, for example, will be just packed with readers taking their own particular dog for a walk, regardless of its relevance to the topic at hand. Pub bores, the lot of them.


Exactly.


`has()` for form validation really looked interesting but then I saw on their first example in your link that it is not supported in Firefox https://caniuse.com/css-has


I dream that one of these days, CSS will get a selector similar to `has()`, but that can target text content, not the structure. E.g. I want to be able to write something like:

  article a :has_("click here ")
to select elements that are otherwise hard or impossible to target. Of course, I don't want to use it on the websites - I want it for userstyles, so I can swiftly and efficiently deal with the insanely bad UX of most of webpages, despite their authors making it hard to fix (often on purpose).

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


For userstyles, you can do that with uBlock's custom filters [1] [2]

  news.ycombinator.com##a:has-text(Hacker News):style(color: green !important)
[1]: https://github.com/gorhill/uBlock/wiki/Procedural-cosmetic-f... [2]: https://github.com/gorhill/uBlock/wiki/Static-filter-syntax#...


The only problem with that is that uBO applies it via JS polling (I think?) and this results in the unstyled content flashing very briefly. Pretty annoying sometimes; hope it also gets into a standard (or jyst gets a native implementation for the sake of adblocking).


My idea of a better web browser design is some CSS commands which are only available for user styles, including these features (text content, shadow DOM, etc; although, such things might also be useful even if not restricted to user styles) and some others, such as more control over priority, and overriding the meaning of other CSS commands (which are restricted to only being allowed in user styles).


In some contexts, which includes JavaScript and thus user styles, you can use XPath, which interacts with all nodes, not just element nodes like CSS. Your sample selector would be this, if I have understood your intention correctly¹ (that you’re targeting the <a> element, and don’t care if the text “click here ” is an immediate child, or spread across multiple children):

  //article//a[contains(., "click here ")]
The equivalent to document.querySelector in JavaScript:

  document.evaluate(
    '//article//a[contains(., "click here ")]',
    document,
    null,
    XPathResult.FIRST_ORDERED_NODE_TYPE,
    null,
  ).singleNodeValue
And the document.querySelectorAll (which returns a static node list) equivalent would use ORDERED_NODE_SNAPSHOT_TYPE, with .snapshotLength and .snapshotItem(index) on the result object. Yes, this API is written in a very old style, and could do with being wrapped in a more pleasant API.

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 ")]
These will be more efficient than the first-used selector. Where CSS is mostly unaffected by selector complexity because it largely evaluates from right to left, XPath is more likely to be doing full traversals, which will benefit from more specific selectors, hence things like prefixing paths with /html/body, or only evaluating in document.body, in order to skip traversing the head altogether, if that will never match; and you can easily imagine that contains(//a/text(), "…"), which selects text nodes that are children of <a> elements and thus has selected nodes that have a trivial string-value, will be faster than contains(//a, "…"), which will need to stringify every <a> element, entailing further traversal and string construction. Mind you, the differences in all this will mostly be very small in practical terms.


It’s behind a flag in Firefox; should be on by default “soon”.


Even without Firefox support, :has() is supported by about 83% of web users, which is pretty good considering it first shipped 8 months ago.


For layout/design, there’s open props [1].

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/


I don’t like Open Props on technical grounds: it’s pointlessly inefficient, largely an abuse of Custom Properties, to my mind, shipping a completely superfluous layer of indirection to every client, rather than flattening almost all of the properties at compile time as could and should be done. If you’re using something like Sass, you’d use variables for this sort of thing except where you do want to change values dynamically (e.g. different values in light/dark mode). Using Custom Properties for everything is just wasteful if you’re not going to have anything subsequently using the definitions themselves.

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


Number 1 lags when scrolling on a 2018 MacBook Pro. Not a good advertisement of a product.


hmmm it's good in my 12+ year old laptop in firefox.


Yeah, I have to wonder if something else is going on with your machine/browser. Runs absolutely perfectly on my 2015 MacBook Pro.


I bet you don't use the Safari Browser. I checked again with Firefox on Mac and I didn't notice any performance issues.


Fine on a 2015 Thinkpad running Firefox on Fedora.

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


Lags while scrolling on a 2021 MBP as well.


[2] crashed Chrome 3 times. Mac Monterey.


For personal projects, sure. But good luck writing a medium to large sized app, full of business logic in Vanilla JS.

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.


In the professional projects I have done the majority would have been possible to do with HTML/CSS/JS. The only reason not do that was that customers typically need some sort of backend and that was back then just simpler to do by other means.

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?


My problem is with "magic" frameworks.

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.


Do you feel React is overly magical? React was the first of these web frameworks that I was exposed to. I didn't have a ton of vanilla html/css/js experience when I first encountered React, but the fact that each component just returns some HTML is pretty unmagical to me. You could conceivably just use React (or, JSX really) to organize your app code in a pretty comprehensible way.

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.


> The hate for JS frameworks is usually warranted

It's almost never warranted.


So true, and hating JS is still a dogma that everyone has to assume ..


You're suggesting that most of those that hate Javascript do so because someone told them they should and not because they've used it? From[1]:

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


Well why do you hate javascript?

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


No real standard library. You have the web API or the Node API to work with, and both are inconsistent.

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.


Well, I agree to most of the pain points, the ecosystem is a mess, due to history.

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


If we ignore all those pain points and ignore that we're sticking to "the good parts" and have to employ strict discipline and not rely on hundreds, if not thousands of unvetted dependencies and use typescript even though its type system has holes in it and nobody should mention the myriad build systems or varying APIs in browsers (its main target) or that its community can't come to an agreement on module formats/namespacing…

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


You are of course free to dislike anything.

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.


There are degrees of hate. If we're talking about programming languages, then I hate JS, while there are languages I love. Who likes the experience of writing in Bash, for instance? It's ugly, limited, and has a series of gotchas, which is much like JS.

> hate has the vibe of wanting to destroy something

You may be right, and given half a chance…


C++ I think gets similar hate.

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


I've definitely written Perl that someone has cursed at. Probably me!


Done: https://github.com/prettydiff/share-file-systems

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


agreed. it's amazing. Actually just wrote a site a few days back only using HTML, CSS. It's a simple site, but still looks good with only a few hundred lines of CSS. peeps are nuts for thinking that you need javascript and bells and whistles.

I did miss SCSS though.


Netlify forms seems like the perfect product for OP.


Let me share my recommended learning resources using Divio's model.

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


I can recommend https://devdocs.io for reference and https://glitch.com for prototyping (and hosting if your needs are modest!) as well some good sample projects.


I'd like to recommend the MDN Learning Area, which they list under "Guides" (I think fits under #2 in the above list).

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

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


Start here: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/fo...

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.


MariaDB/MySQL + PHP + HTML/CSS and some vainilla JavaScript if necessary. What else is needed? I deploy in production using FTP. My version control is ZIP files in some old hard drive. Of course, this won't work if you're working in a team or are developing a huge web app, but for 99% of use cases, this just works.

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


You’ll get no complaints about the stack from me, but I do have to push back against your approach to version control a little bit. Even if you’re the sole dev, having easy access to change history, checking out specific versions, or even branching and merging your experimental changes, are all a godsend. And a git repo is much easier to manage than having to contend with all your “query-fix-final(1).zip”s.


I think working in a team is quite common, isn't it? Especially if you are starting, how are you supposed to find customers if you are alone and lack experience? And even when you have the experience, I think most companies would prefer to hire a company rather than a single developer.

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.


Using something like Git is highly recommended even if you're solo, just because it is so useful to have a log over changes. It doesn't really have any downside and can even easily replace FTP as the deployment method. Using FTP can be a bad idea as the replacement of files might not be atomic and can result in an invalid state.


If you are solo, you would not use Git, which was designed for hundreds of collaborators working on a project.

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


No, I definitely still use Git on solo projects, there’s no reason not to do so.


If you know it, use it. But it's not worth learning if you don't already know it. Or, it's at least fairly low on the priority list.


Strongly disagree. Learning complex girl workflows is unnecessary unless you're in a team. However, learning the absolute basics is really easy and has benefits over "storing previous versions in a zip file". By absolute basics I mean add, commit, reset. If you add basic branching (checkout and merge) you already get a very powerful tool to experiment with your code without worrying about fucking it up. Then you can learn the rest when you have a use for it—log, diff, even rebase.

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.


From personal experience, I’ve self learned over a dozen of languages, a bunch of frameworks, databases, etc. and shipped many products and side projects as a solo hobbyist/entrepreneur and I’ve failed adopting/learning git at least a handful of times. I also have not been hampered by my lack of source code tools. I have managed by using my normal process of zipping or creating backups of the project root folder at certain points. Same as I’d do with any other task.

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.


I don't know how this has happened, but at some point in the future I must invent a time machine, go back to 2005, and submit a post to HN that arrives today. That's exciting.


There is nothing wrong with PHP for websites. I'm fact, PHP is probably the best option for most people(that's a bold statement). It does many things better than other languages. It's not without reason that PHP is the most used language for websites.

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.


> It does many things better than other languages.

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


Templating is built in.

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.


he he… I'm not the OP, and I'm not knowledgeable enough in programming languages to answer this question. But I also would be curious to know what the other languages are doing better, regarding backend website development (apart from consistency, which I don't argue is important).

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 must be going crazy, the amount of posts I’ve been seeing recommending PHP on HN lately is making me doubt my sanity.

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.


I've observing on HN what seems to be a trend back to self hosting and that essentially is going to lead to the simplicity of the good ole LAMP stack. I see what seems like a lot of fatigue with all the frameworks, dependencies, containers, etc. It was like those things had initial excitement but then longer term were more of a burden/risk/hindrance.


I love to dunk on PHP as much as the next dev, but if you're recommending JS instead then you're not really thinking about it enough. Pretty much all the issues with PHP apply equally to JS.

The cool kids dunk on both of them.


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

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


If you use something like Astro or anything focusing on minimal JS style SSR/SSG then that’s basically the PHP experience but without an extra language, and given that OP asks for simple web apps, getting 100% lighthouse is too easy. With basic CRUD apps you can easily get 0.2s TTI.


> MariaDB/MySQL + PHP + HTML/CSS and some vanilla JavaScript if necessary. What else is needed?

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.


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

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/


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

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.


Me and other contributors are writing and maintaining "Web app from scratch" scripts for popular frameworks here:

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.


Why using python3-django on debian instead of a venv and the last lts of django from pypi on your script[0] ?

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


How would you replace the line

    apt install -y python3-django
with "a venv and the last lts of django from pypi"?

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.


Like this:

    python3 -m venv .venv
    . .venv/bin/activate
    python3 -m pip install django
I think python packages should be installed through pypi, instead of being installed using whatever package manager your system use.


To me that is like way more convoluted than just using containers.


Can you elaborate on how "using containers" gives you a running Django instance?

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


You could have the environment ready and be ran on any container distro.. all they need to do is mount the files and go.


Complexity is slowly winding down with next generation frameworks like Svelte and SolidJS, but I suppose you don't want that anyway.

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.


The problem with such frameworks is that they depend on JavaScript, which was not meant as a systems software language. JavaScript is simply the wrong tool for the job. What would help would be a state-ful GUI markup language so JS doesn't have to reinvent most of the GUI wheel.

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


I was in the same boat with wanting to just learn plain HTML/CSS/JavaScript.

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.


Definitely, https://gomakethings.com is what I instantly thought of after reading the OP.


I don’t want to copy and paste instructions and throw something together without a clue what’s going on

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.


To give you some perspective for where you're coming from: it's like you're inquiring whether it's possible to write a GUI app on Windows in C without all the complexity of Visual Studio tooling and WinForms Builder. You also don't want to be bothered with dependencies. That's essentially what you're looking at here. A very small standard library and you have to reinvent the wheel for a lot of things that should exist out-of-the-box.

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.


Looking at the state of these comments, modern day front end dev is truly ridiculous. There's not one common answer or approach suggested.


OP: Hey guys how can I learn to write a simple vanilla webpage?

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!


While I _agree_ with the sentiment that front end dev is a mess. This is like saying "Modern Sports is Ridiculous because there's not one team". There will always be multiple approaches to building Apps just as there are many sports teams.


Backend dev is such a mess. Should I use Rails? Or Django? Or Lavarel? Or MS Dotnet? Or Node? There’s no common approach suggested.


It is like shopping for a bottle of wine.


You don't need framework. You can create classes, make api requests (axios), add 3rd party libraries in vanilla.

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.


I purposely wrote my home page (https://langworth.com) with plain, vanilla JavaScript, which features both WebGL and plaintext clients for a server-side text adventure game, because I wanted to remind myself that it's not that difficult to build something interactive and fun without miles of modern front-end tooling.

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


FYI uBlock's privacy filters block your script.js file for some reason.

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.


Thanks! I know that uBlock blocks the tracking script, but the rest of the site seems to work fine for me (also Chrome on Mac with uBlock Origin). If you have the time, could you check the dev tools console and email me with what you see?


I would advice you to at least use some kind of web component wrapper. I have used https://lit.dev/ a lot, even to build a large app and it works really well. You can get started very quickly and the experience stay true to the underlying platform.

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.


+1 for this answer. Also consider stencil.js - it is just as powerful as React while still being a web component wrapper and it doesn't require converting props from strings to other types.


I am an amateur developper who codes for fun (and to make my family's life miserable though automation or a home chores app). I have a large background in IT and sysadmin-style coding.

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.


For simple web "app" like form and form processing where you are not using dynamic reload of page elements, you can drop JavaScript and go with PHP + HTML + CSS. Use vanilla procedural PHP with sane splitting in functions / files. This stack is good enough for simple web apps, but also good for a little more complicated like for example task list etc. You can optionally sprinkle it with some vanilla JavaScript for dynamic parts, like showing disappearing error messages.


> you can drop JavaScript and go with PHP + HTML + CSS. Use vanilla procedural PHP with sane splitting in functions / files.

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.


PHP. One file on a shared host for not too many headaches


"Users can create a form" and "simple" are not two things I would put in the same sentence. What's happening in the forms? Where does the form go? How many users? This immediately sounds "bigger than a web page" and suggests you need _some_ tooling.

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


It is simple, people have been processing forms with CGI-style tools for ages (php etc, even this website!). With modern web services the equivalent is to use zapier/pipedream or built in services like netlify forms.

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


I don't get your analogy here. How exactly is Zapier equivalent to CGI?


If you want your static html to process a form, a few years ago the simplest approach was to add a php file to your site.

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.


Makes sense, thanks!


I recommend just starting from scratch. As a programmer at heart I find programming like playing with Legos. While I needed to understand how all the underlying parts worked, I didn't need instructions on how to build a specific larger thing.

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


If you're coming from the WPF and winforms world IMHO you actually should find and use a framework. Find something that has a bunch of pre built components like cards, dialogs, buttons, etc. already styled and ready to go. You could go for something complex like react and a component library in its world, or go with something that is (mostly) CSS like bootstrap or bulma.

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.


You said app, which means you'll likely need some sort of backend. Express is pretty simple to get started with. These examples work out of the box and give you a simple starting point: https://expressjs.com/en/guide/routing.html

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


Other comments have already suggested guides for creating a simple static HTML site with light CSS & JS, whereas so many other comments are suggesting absurdly more than necessary.

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/


Regarding sane CSS I highly recommend the following resource: https://every-layout.dev/rudiments/


+1


Modern web is fairly complex but it doesn't have to be. What you're after is a simple form to submit that data to someplace. CSS and JavaScript in your case are only needed to improve the look and get some kind of dynamic feedback.

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.


I would start with ASP.NET Razor Pages to render HTML from the server and use a simple already done CSS framework like bootstrap or milligram.

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.


How do you deploy a .NET app these days?


https://learn.microsoft.com/en-us/aspnet/core/host-and-deplo...

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.


> How do you deploy a .NET app these days?

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


Good question that I am asking myself! Azure seems to have some good pricing now for hobbyist for DB and app but we are talking 20/m so not cheap but it is all managed / serverless.

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


Obviously Azure is the intended home from the MS point of view, but AWS does have out-of-the-box support for .NET 6 Lambda functions.

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


Thanks. I don’t have much AWS experience but that is good to know. To me it is another big cloud option. Big cloud options usually have extra steps. For example in Azure you need to configure your DB firewall to let the app have access, and so on. The more heroku level stuff would probably do this for you.


You can run .net core on Linux now btw, works great. See my comment at same level.


I’m currently early on working on a webapp/spa with no node and just some tooling I wrote myself (www.lona.so). I plan to document my process and post it at some point. My two points of advice if you’re looking to go the native route is to 1) look into web components and 2) find something to syntax highlight html strings (es6-string-html on vscode).

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


Try looking at my personal project: https://github.com/prettydiff/share-file-systems

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


> Web app > Do I really need Node?

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.


If you're coming from wpf and friends I can really recommend razor pages or blazor. Though razor pages are probably good enough especially if you are fine with running a server.

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.


I've used MDN and CanIUse.com for https://whatword.wtf (code here: https://github.com/fictorial/whatword) which is Vanilla JS, HTML, CSS, Node.js with Express.js. I haven't understood the motivation for frameworks like React. I saw the value in something like jQuery for workarounds in browser implementations of standards. It's amazing to me to see how many "web developers" don't really do web development but start with React and similar and can't go any deeper. Really wild to me but I understand how that happened... Ha, I sound old.


This article by Julia Evans shows how to "build web apps like in 2005" but use libraries from NPM, use ES6 imports and stuff.

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


Agreed. There should be more standalone, minimal libraries that don't require the use of NPM. Once you've added NPM, or similar, your complexity skyrockets - even if it's abstracted away from you, it's there.

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


What you describe has two parts: creating a form and filling it in (presumably with storing the results somewhere). While the second part is relatively simple, the first one requires quite some work. And although you can do it in vanilla JS, you'll be better of using some libraries.

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 recommend using Micronaut + Thymeleaf, its simple, easy and fast in both performance and developer productivity. Vanilla HTML, CSS and Javascript is fine. The best part by using Micronaut is that the documentation is really really good.

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


You are absolutely right; web development is unnecessarily complex when you use frameworks such as React.

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


An example of code for a very simple web page is displayed at Step 3 of this page. https://www.c-sharpcorner.com/article/create-a-simple-webpag...

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.


> To me, the browser is the UI framework

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


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

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


I fully agree with your sentiment. In case you need some tutoring, please don't hesitate to contact me here. I have 20+ years of experience in software engineering and webdev and I believe current state of web-development is completely screwed up.


> I find web development to be unnecessarily complex, but I refuse to believe that’s true.

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.


The Django Girls tutorial is supposed to be good for beginners. It takes you through everything up to Django Forms: https://tutorial.djangogirls.org/en/django_forms/ . I don't think there's any javascript in that tutorial. That combined with the Django Documentation: https://docs.djangoproject.com/en/4.1/topics/forms/ should be fine.


With Javascript Modules[1] on the browser, you can quickly build plain HTML, CSS, JS locally without the need for pre-compiling. Just import directly from unpkg[2] locally and start building!

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


Start with Bootstrap. You will see a simple HTML page with a CSS link tag. https://getbootstrap.com/docs/5.2/getting-started/introducti...

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.


You could check out WebComponents, that is the closest you could ever get from WPF using only vanilla DOM (without a DOM framework).

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.


I've done a decent amount of non-trivial stuff using .NET Core MVC (not Razor Pages, which is apparently less "magic" to the uninitiated but I can't actually speak to how it feels to use), with plain JS and CSS. That environment has libman, which allows you to download libraries in a very simple manner. I make JS "classes" with IIFEs and use Bootstrap for CSS. If you're not a complete slob it's not too bad. If you ever feel like you need minimizing and compatibility transpilation, that can be added after the fact.


You only need three things and no nodejs. NodeJS is mainly needed because many CLI and preprocessing/transforming tools are written in Javascript. If you don't use them, you don't need NodeJS. The three things:

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


I wish there was a programming equivalent as simple and visual as Excel, to prototype real apps with.

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.


Nodered perfect for backend also has frontend tools or combine it with plain html or htmx

Opensource had community libraries and selfhostable


Back in the old days before react and the like took off Jon Duckett's https://htmlandcssbook.com/ used to be a common recommendation for people wanting to actually grok HTML.

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.


I have a tiny book called How To Code that teaches the very basics of pure JS. I’m also recording a video that shows me coding up an application in pure JS this week. It is a raffle app that takes a list of names and picks one randomly. It will use HTML, CSS, and pure JS with nothing else. No frameworks, no compile or transpire step, etc.

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.


Check this out: https://github.com/1Marc/modern-todomvc-vanillajs


Just as an option, my staff at n0c0de.com develop pretty good Webapps with zero knowledge of HTML/JS/CSS using Bubble. The main downside is it needs to be hosted with Bubble and you need to pay a recurring subscription fee. You cannot do local development either (but the trade-off is quite worth it).

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.


You can create a very simple 'app' even without any javascript [0].

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/


Want to make browser-only webapps without node.js, bundling, building, transpiling and all that stuff?

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.


Agreed, the platform is not as good as Visual Basic was 30 years ago. No-code and low-code platforms do most of what you want. Unfortunately most are hosted.


I have a SaaS deployed that does just that.

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've been doing this for a couple of years, with the added requirement of Any Browser compatibility all the way back to Netscape, as a personal choice. Please feel free to skim my code for ideas.

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.


I was in a similar position. I use ASP.NET Core, works well, fine on Linux. I don't use Node but I do use TypeScript and getting that working smoothly with ASP.NET Core took some experimentation, I went down the webpack rabbithole but abandoned it as I don't have an SPA. I use Dapper in preference to Entity Framework.


You can definitely create and make a form, ala previous generation of web apps.

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


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

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


>> You can definitely create and make a form, ala previous generation of web apps.

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


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

No, it doesn't


Then please provide supporting arguments as I have done.


You did not provide arguments. You provided two statements: "You can build a form, but sadly web components are not popular" and "anything more complex than forms requires web component tech".

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)


OK let's look at how you communicated in this thread. Keep in mind I've been polite to you so far.

1. > You did not provide arguments.

Yes I did. I wrote:

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

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

You obviously know these are supporting arguments, because they seek to back up the statement that 'more complex apps are harder to build without frameworks'. This is high school level logic, so I will presume that rather than being unaware of what a supporting argument is, you're just being deliberately antagonistic.

2.

> No, it doesn't (end of post)

You misread me (see next point) and rather than responding with content (which would have cleared this up earlier) simply disagreed without supporting arguments.

3. You misread me. I wrote:

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

Judging by your comment about frameworks not using web components (which you'd know I'm aware of, given that I posted an article by the author of Svelte about why Svelte doesn't use web components), you think I’m discussing implementing a new framework. Nobody is discussing that. The OP is making a web app, not a new framework.

Implementing a web app without react or svelte would require using web components which is, as mentioned, a set of poor and unused APIs.

Given 1, 2 and 3, it's obvious that you're being clearly antagonistic to someone that has been polite to you thus far, I will change how I communicate - Dmitri, you're a cunt. Sorry Dan.


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

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.


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

Nobody is saying that.

Nobody has ever said that.

I have explicitly said the opposite since https://news.ycombinator.com/item?id=33635218.

You are arguing with yourself.


> Nobody is saying that.

> 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 wrote:

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


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

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.


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

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


It depends on the thing you want to create. The browser UI controls are limited at best, keep your expectations low.

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.


> It's best to use some tooling

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.


I wish I could avoid web tooling, because I completely agree. But I’m forced to use it at work. Thankfully I’m free for my personal projects.


>Writing Vanilla JS is error-prone unless you are very disciplined

the absolute state of web developers in 2022


If you are trying to create a stateful web app it's true. Even with frameworks it can be difficult. I wouldn't want to write anything complex in vanilla JS.

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


Genuine question: what would you recommend using?

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?


what I'm saying you do need to know JS really well before you even touch frameworks


Forgot to add

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


For something that simple you could check out PHP. Or even google forms, if you don’t mind something really simple and hosted by google.


You can definitely do that, the real issue is tracking changes you made to the webpages to alter them later, like adding a new form section. Also the DOM API is not the most consistent. But if you're well-disciplined in coding, it can be done, but make sure you have designed your implementation because the language itself is very permissive. Very much not necessary, but you can use a library for a more consistent DOM manipulation, like jQuery or UmbrellaJS [1].

You'll need some kind of backend, and you can either make your web app server rendered, which means embedding your frontend inside the backend, mostly by using the backend template language. Or split the two and communicate via XHR/AJAX.

If your forms are static, something like Netlify Forms and Netlify Identity can take care of both submissions and authorizations.

[0]: https://developer.mozilla.org/en-US/ [1]: https://umbrellajs.com/


Gotta do https://scrimba.com/


Wrote this a while back to teach our team TDD building this JS todo list from scratch without any frameworks: https://github.com/dwyl/javascript-todo-list-tutorial


Great topic, long topic. I could write a book on it. Wait! I did!

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


I write Go web servers that deliver HTML, CSS, and JS. I use the template library to fill in some stuff server side. As you get more advanced with the templating you can break things out into components. Best part is you don't need to compile your Javascript.


I like to use Bootstrap for CSS, because I'm not a designer and I want a graceful experience on all devices. Plain JS can easily be thrown in there. You can also just use the default HTML form submission behavior. Bootstrap offers some helpful validation styles for client side form verification.

Unfortunately, to remove CSS bloat from your completed Bootstrap template you need to use a node based script. Check "Purge CSS", although there is another one.

No need to get into bloated SPA frameworks or JS on the backend. From my side JS is just a necessary evil for webdev. Prefer to keep it in the browser where it is required. For the backend, choose a sane language you are comfortable with.

Using a WASM blob + canvas/WebGL as a client is another option which is increasingly appealing. You still need some JS glue, but you're free from some of the browser madness. Depending on how you build your client, you maybe able to recycle it into a standalone binary.


I’ve also made use of cheap web templates based on bootstrap. For example, Inspinia and Color Admin.

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.


Hey man,

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.


The web platform was mostly piecemeal and happenstance. Not careful, coordinated design.

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


I remember when Java EE came about. They had something called "Petstore Demo" running, and documented in articles. Isn't there anything like that for Node.js/js/html/css ?


Just use Elm. ( https://elm-lang.org/ )

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


Take a look at server side rendered PHP with some CSS for UI aesthetics and a sprinkling of JavaScript for client side dynamicism and Ajaxy posts to mitigate back button issues.


If I were you, I'd use Node/express with server side rendered templates. It's pretty straightforward for a simple project that needs a backend.


Read books. That's how we used to learn when those languages were invented.


PHP is your friend.


I spend a decade trying to replace PHP. Now I have a small freelance gig. Guess what I use?

PHP, Apache2, mysql ( sometimes, hardcoded)


It's so simple it's stupid.


Learn JS in MDN Try Svelte, Vue3, Quasar


I don't know of a readymade resource except checking the usual places (W3Schools, MDN, LinkedIn Learning, Codecademy, Udemy, etc.), but just wanted to address some of your points...

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


there are books on this topic. going back ~25 years. you can find books via Google, Amazon or visiting a library


at your command prompt with latest Node and npm installed:

  mkdir -p non-obnoxious-web-server/atc-test-plans
  cd non-obnoxious-web-server
  mkdir src
  mkdir public
  npm i --save express
Then make the following files...

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}`);
  });
public/index.html:

  <a href=/file-atc-test-plan>File a new ATC test plan!</a>
public/file-atc-test-plan.html:

  <!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>
Once you have done all that, at your command prompt again, do:

  node src/index.mjs
Hopefully that gets you started. Enjoy your journey! :)

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


Have you thought about ruby on rails?


Let me give a quick overview of modern web dev and maybe the perceived complexity will make more sense. I'll say right right off the bat that you probably don't need to care about 90% of this stuff and you can write raw HTML/CSS/JS, but it may help things make sense.

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.


I guess you will just end up writing your own framework in the end. There is a reason web framework exist - they all satisfy different needs in the domain of web development. Like routing, content update, state handling, event handling and so on. If you don’t need any of that, great, you can just learn and write plain html, css. So LMGTFY https://dev.to/jordanholtdev/how-to-create-a-web-page-with-h...

Cheers




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: