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.
Using modern HTML and CSS will get you pretty far these days.
For example, dealing with forms used to be problematic in a few different ways without JavaScript or something server-side.
Now form validation can be done with CSS [1].
For example, static site hosts like Netlify have services for dealing with the form data [2]. 100 free form submissions per month.
I agree that tooling is out of control. Jekyll [3] is great for getting started with building static sites. When using Jekyll, my build tool of choice is a Makefile [4].
[1]: https://webkit.org/blog/13096/css-has-pseudo-class/#styling-...
[2]: https://www.netlify.com/products/forms/
[3]: https://jekyllrb.com/
[4]: https://blog.mads-hartmann.com/2016/08/20/make.html
It's pretty amazing, HNers' capacity to read a request that includes a clear, concise (and satisfiable) requirement—no frameworks—and then dozens of respondents write up answers predicated on the use of this or that framework, thus contradicting the entire premise for the question.
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).
I like the MDN for quick reference but the actual HTML spec is actually quite well written and has lots of useful examples [2].
[1]: https://open-props.style/
[2]: https://html.spec.whatwg.org/
As an example, on their site, they’re sending about 68/12KB gzipped of styles. Some are already unused and could be removed by straightforward dead code removal. Inlining variables that are set only once and removing their definitions (which incidentally encompasses that dead code removal) reduces it to 40/8KB which will both transfer and evaluate faster. (A further 20% of the styles are also unused and possibly sanely removable.)
The hate for JS frameworks is usually warranted, in this case I think nuance is missing. It's also not as black and white as people paint it to be, IMO.
But there is quite some projects where you don't even need that.
Learning HTML/CSS/JS is a good idea as ultimately any framework or serverside code will interact with some combination of the three. Having a strong grasp of how HTML/CSS/JS work is the perfect foundation for learning something that runs serverside. And you get there by building projects that predominantly lean on the three. Whether they are private or professional, who cares as long as they are cool and someone learns something from it?
For example angular hello worls is super duper simple. But then business apps become a giant pile of crap, the eprformance goes to shit and sometimes stuff that should work stops working. The issue is the magic, if use a sane library you can just run the code in debugger step by step and see what happens but with magic stuff you get a giant call stack with garbage that is impoosible to understand.
So when I can I rip out magic and replace it with function calls , getters and setters. Maybe is my bad luck that I always have to work on prtojects created by others and all the time this others did it wrong. Nobody can convince me that angularjs1 is a framework designed by competent people with experience in GUIs, maybe the newer version are better if those buys learned on the job what they should have known from the beginning.
It's almost never warranted.
The hate for large frameworks is warranted by their poor performance and bloat while struggling to achieve simple objectives in the most challenging ways.
I did miss SCSS though.
1. overview/explanation:
- https://web.dev/learn
- https://www.patterns.dev
2. (hands-on) tutorial:
- https://github.com/microsoft/Web-Dev-For-Beginners
- https://freecodecamp.org
- https://www.theodinproject.com (note: includes React)
- https://fullstackopen.com/en (note: includes React & GraphQL)
- online courses -- recommendation: CSS for JavaScript Developers and Three.js Journey
3. how-to guide:
- https://css-tricks.com
- developer blogs
4. reference:
- https://developer.mozilla.org
- https://javascript.info
MDN: Learn web development - HTML, CSS, JavaScript, Web Forms, Accessibility
https://developer.mozilla.org/en-US/docs/Learn
Once you throw a few input elements and a submit button into an html file, you can use the network tab in your browser's "Web Developer Tools" or "Inspector" to see how the form submission looks over the network.
You will need some kind of stack on the server to interpret the submission and do something, like stash it in a database or maybe in your case just append a string to a file. I like Node and use nothing but its built-ins for creating servers and writing to my filesystem.
Speaking of built-ins, python and php can be good too, they can create and interface with sqlite databases out of the box.
So I don't have an exact direction to point you but feel for you re: crap medium articles. I found it worth paying $25 to https://teamtreehouse.com/ to choose from the many tutorials there, lots of intro content of good quality.
The only thing I focus on is valid markup, accessibility, performance, good error handling, and getting a 100% in Lighthouse. At least I'm doing better than my bank's "modern" home banking app in Angular that breaks half of the time and can't even handle multiple tabs :)
But unless the client wants to manage the content, I agree that MySQL + PHP + HTML/CSS/JS works great for simple websites. I would add git and lint tools too.
If the client wants to manage the content, then using a CMS such as Drupal or WordPress may be required.
Instead, a simpler version control system (something like Git?) would suit you better.
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.
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.
This is a surprisingly usable stack, I'm tempted to agree.
Personally, I'm on the fence about using server side rendering (which PHP is pretty good at) versus just writing RESTful APIs, because browsers now have fetch API built in which makes consuming them easy (no need for jQuery or necessarily even something like Axios).
Of course, I might still go for a reasonably feature complete framework like Laravel (which handles certain things that you're very likely to get wrong, like auth/encryption or working with mail queues and such), or Slim (which is a nice option for smaller setups, essentially a micro framework; like Lumen used to be).
> I deploy in production using FTP.
This isn't ideal from a performance or reproducibility perspective, but can be workable. A caveat here could be file permissions, depending who is uploading what and how, as well as copying over files that should perhaps be transient (e.g. vendor directory, when you should be using Composer or something like that instead).
Personally I'd go for containers since writing a Dockerfile and shipping/running a container image (even with just Docker or Docker Compose, or Docker Swarm) isn't all that hard. If nothing else, it works wonderfully for getting as many databases up and running as you need, running different versions with different ports in parallel, managing resource limits, configuration and so on.
> My version control is ZIP files in some old hard drive.
This is a very counter cultural stance, that may or may not border on insanity in the eyes of those who want to exaggerate for the sake of an eye catching sentence. Others might joke about file names like code_2022_11_17_release_final(1).tar.gz.backup2 which this workflow might lead to.
Personally, I think that this is just a bad idea, even when working alone. It's good to be able to see what was changed when and have different changesets that you can easily compare, navigate or merge into whatever solution you decide on. Also, it's very nice to be able to revert granular changes, if that's ever necessary.
Try implementing a feature, realize that after changing 34 files you want redo certain parts and need to revert changes in 14 of them, do that with just a few clicks or keystrokes in Git (or other VCS) solution of your choice.
Version control is just a good idea in most software development cases, period. That said, opinions on how to use it and which system to use rightfully differ, as does what to version, whether to use something like Git LFS, whether you need a web UI of some sort or should you work with patches and so on.
You can do a kind of halfway house with Htmx. Have your backend generate HTML fragments, and Htmx in the browser will inject them into the page without having to do full-page reloads or complex vDom manipulation.
https://htmx.org/
That depends on the target website (or web app), but as a web visitor, I usually dislike having the stuff rendered client-side, it always feels slower. Also, for content-based websites, I like when JS is optional.
https://github.com/no-gravity/web_app_from_scratch
The idea is to have a self-explanatory shell script for each framework, which turns a fresh Debian installation into a running web application with routing, templates and user accounts.
So far, we have Django, Flask, Laravel and Symfony. In various stages.
If you look into the scripts, you see that they are pretty much tutorials in code form. Reading one of them shouldn't take more than 10 minutes. After that, you know exactly what your web app does.
[0]: https://github.com/no-gravity/web_app_from_scratch/blob/main...
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.
Do you mean using a premade Docker image that comes with Django installed and configured?
For the front-end you probably want at least a CSS framework. I recommend this:
https://kylelogue.github.io/mustard-ui/index.html
It looks good and doesn't have strange font-size hacks that could make it incompatible with external CSS.
IIRC it's possible to include it as a single CSS file and call it a day.
You don't need JS at all for a simple form.
As for the backend: I unironically recommended PHP. It's a whole rabbit hole of different solutions, but you can always fall back to a framework-less solution. Just be mindful of security issues.
Missing GUI widgets: https://www.reddit.com/r/programming/comments/otixwo/comment...
Mozilla docs didn't quite do it for me but I swear by W3SCHOOLS website.
I also found this guy's website helpful: https://gomakethings.com/
I think the author is on HN; he swears by plain JS.
For me I just wanted to write a simple cross platform app, I decided Dart/Flutter was the way to go in the end.
Don’t read medium. Web world has less order than MSVS world, so you have to settle on a tech stack first and read these manuals. Also don’t think “hey it’s just web, I’ll figure it out”, it’s a path to headaches.
Here is my advice, based on I avoid frameworks but still get it done.
“Just html, css, js” will get old quickly, like in half an hour or so. You want to try it much later, after feeling okay in webdev.
For frontend start with Parcel or Vite, both are zero-config bundlers (as in compile, link, autoreload). You’ll need a separate Node.js-based project for a frontend. Use Bootstrap for CSS, since you can’t css yourself from ground up and don’t really want. Use Sass for CSS (you have it out of box with Parcel/Vite).
After a week or two with pure DOM, take a look at jQuery ecosystem, Mithril.js and Vue.
Frontend runs in a browser and is limited in what it can do.
For a simple backend (it talks to files/db, basically a regular program with an http server instead of gui) there are js and non-js options. Node.js Express. Python Flask. The key idea for searches in other languages is “I want to serve few files and api routes”. Make backend a separate project, web world is not zero-config ready for all-in-one projects.
Read most relevant parts of each manual and don’t visit medium unless you’re “in context” and know what you want exactly, but forgot where it was in a manual.
References: MDN, CSS-Tricks.
Stack: Node.js, Parcel/Vite, Bootstrap.css, Sass, Express/Flask.
This will be a good starter with a straightforward setup.