How I Build Web Apps As A Freelancer

I agree with the points here.

I came from backend development, writing mostly in C++ and Python for most of my career. I've always found modern JavaScript frameworks so difficult to reason about because it feels like I'm always working through nine layers of abstraction.

Last year, I read Julia Evans's article "A little bit of plain Javascript can do a lot," and it inspired me to try to push regular JS as far as it would go in my next project. It's now 8 months later, I have thousands of users, and I'm still using plain JavaScript.[1] No babel/webpack or anything. I do use Flask to aggregate source files together, but I purposely avoid any cleverness there. Overall, I find the code much easier to debug than any of my other web apps.

One nice advantage of using only vanilla JS is that it's easier to find contributors. If you're a React project, then only React developers can contribute. But if you're a vanilla JS project, you're not bound to developers of any particular religion. Vue, React, Angular, Svelte developers can all work in a vanilla JS codebase.

[0] https://jvns.ca/blog/2020/06/19/a-little-bit-of-plain-javasc...

[1] https://github.com/mtlynch/tinypilot

Man, I hope I don't have to work on their code ever (edit: to clarify, I am not knocking their actual code!)

Being so against using any sort of transpilation you avoid even TypeScript and JSX? Even though Parcel gives you these things completely for free, out of the box?

I do not think this approach would scale to a team in any good way.

Also with regards to using something like unpkg URLs in built code, whilst I a not completely against using urls for dependencies (ala deno), isn't there the huge risk that without pulling dependencies in at build time, those URLs will break or become overloaded or compromised?

I mostly agree with the author on "I avoid the new and shiny." ... The post links to another named "TypeScript is weakening the JavaScript ecosystem". In that post, the author says "My context is that I've not looked into TypeScript yet. That means I have no idea how it works.". I am all for reading a good critique, but how can you adequately critique a technology if you don't know how to use it?

Personally, I have arrived at a similar set of ideas in my consulting gigs, though not the same technology stack choices.

I think it is the need to be maximally productive in the shortest amount of time. Basically, any time you spend fixing someone else's problem is time you aren't getting closer to the clients goals. It is not that the time isn't for the greater good, but the hours I have allocated to this problem are fairly tight to start with and I don't enjoy the "We are over budget. Here is why" talks.

I have reached the point where I have started using npm ls as a proxy for how much pain migrating a legacy app will end up being.

Love the section "I use open source to my advantage": https://timdaub.github.io/2021/01/16/web-principles/#i-use-o....

I started doing this a couple of years ago - defaulting to writing open source code unless I had a really good reason not to - and my productivity has gone through the roof as a direct result.

The way I think about this is that ideally as a software developer I should only ever have to solve any problem once. If I solve it by writing some open source code, and do it well, I'll never have to solve it again in the future.

I compare that to my previous decade+ of engineering where I would frequently find myself solving a problem that I'd already solved a couple of years earlier, but in closed-source code that I couldn't easily reuse.

So I'm not against these rules, but I do run an agency that builds bespoke JS Apps for folks and a few notes. My biggest feedback was to ensure you're communicating with your client and telling them why you make these types of decisions and point out some of the tradeoffs and later costs they might accrue.

1. Using some sort of typed JavaScript via Typescript or Flow makes for much more resilient and stable code. Particularly if you're developing re-usable APIs. You're doing the right thing with automated tests but missing an opportunity by avoiding a type system. We had a much fewer runtime issues once switching to a type system.

2. The above sort of necessitates a transpiler.

3. With respect to using your own code, most freelancers (I assume) are delivering code to third party teams to later maintain. Using common, shared libraries is a benefit for later developers, so this rule should be tempered with later benefits.

Some commenters are missing the point. They are narrowing their mindset by focusing how it would scale in a team environment. However, this post is coming from a freelancer perspective - it's a perfectly good set of principles, even for any side project.

Too many developers start their baby projects thinking they'll be building it alongside hundreds of fellow developers and spend weeks prematurely configuring their build tooling, boilerplate, tech stack. How it'll be supported in twenty platforms, etc. You're only giving yourself more headaches for later on.

I agree with your point on using your own work. People reach for the nicest looking library but there are so many standardized web apis capable of doing what they need, with only very little modification to make it work the way they expect it to.

I don't use it anymore, but I think being able to use Vue without any build step is one of its greatest assets. You can just start writing components on vanilla .js files just like in the old school days.

I mainly use Svelte now which unfortunately requires a compilation step but the benefits are so great it's worth it.

There's such a great disconnect between what front end devs need and what the W3C/TC39 keep adding.

> I avoid the new and the shiny

> (...)

> import { h, Component, render } from 'https://unpkg.com/preact?module'

Will break on breaking changes in upstream, as no version is specified? Or am I missing something?

Ed: not to mention when unpkg goes away...

Slightly misleading title change here - the article was "How I Build JavaScript Apps In 2021" but here it appears as "How I Build Web Apps As A Freelancer"

Web apps and JavaScript apps are not the same thing.

Here’s my general problem with people who profess statements like these: JS, putting aside typing, project structure, etc, simply has a small standard library. At some point, you’re rewriting utility functions that you absolutely should have, instead, be pulling in from tried and tested code base. An engineer whom merely rolls all of their own solutions doesn’t seem like the kind of engineer that builds maintainable technology.

I’d rather tree shake a lodash function than roll my own. Not because I don’t know how, but merely because that code is better than mine. Period.

I have a lot of sympathy for the arguments made here.

I strongly agree with avoiding overcomplicated processes and tools. When you start spending noticeable amounts of time trying to figure out your build process or how to manage your hosting infrastructure, to pick two repeat offenders, something is wrong. The overwhelming majority of web apps simply aren’t that complicated, and building and deploying them shouldn’t be complicated either.

Like the author, I am a big fan of tools like Parcel that have one job, do it well, and mostly “just work”. Virtual hat tip to Caddy as a web server for similar reasons. I think some of the more recent build tools like Snowpack and esbuild are worth watching too. All of these tools share the common theme that they attempt to make routine jobs simple, automatic and fast, so developers can get on with developing useful software.

In some ways, I take almost the opposite view when it comes to writing code. I tend to start almost everything from a clean slate, and usually I end up using a relatively small set of libraries, carefully chosen for each project, for productivity. I rarely use a heavyweight framework, as I think the benefits they offer are much more limited than their popularity would suggest and the potential long-term costs they come with are often underestimated. I almost never use scaffolding tools, for similar reasons.

I suspect this apparent dichotomy is a bit like what you build and what you outsource in a startup. There is the core idea, which is where you’re creating value, and you want to be as flexible and productive as possible in that area. For everything else that is necessary but not the unique part of what you’re doing, you want to be involved as little as possible. Outsourcing that stuff is good, but outsourcing 80% of something and still having to do the other 20% but on someone else’s terms is often the worst position of all.

Something was bothering me about this whole thing. I think I found what it is:

1) This is an entirely self-centered approach. "These are the tools that I like, and I code the way I'm productive, with the specific knowledge I've acquired, tailored to how I best work." That's a lot of "I" in there.

The idea of programming this way really bothers me because as someone who's hired freelancers, the best interests of your clients are nowhere in your calculus. Now, if you gave them the choice between lower cost code and code that anyone else can work on, it's your client's decision. But you are making that decision for them. If your clients are non-tech people who don't understand the ramifications of each choice, then you are doing them a disservice.

Nowhere in your article do you mention documentation or making your source easily understood by anyone else, so I rest my case.

It looks like if you are ever hit by a train, your client is screwed, and you've not thought about that.

2) I know that we, as engineers, love to reinvent the wheel, but when you start implementing stuff readily available you introduce bugs and security weaknesses. Maybe you trust yourself not to do that, but do your clients know you're not using industry standard code?

Anyway, your life, your choices. I'm not sure you've been on the client side inheriting code written like this that no new programmer can understand right away. Whoever inherits your code is going to have a lot of head scratching to do, and the only saving grace is that they will have your tests to validate any changes, and they will hope that your test coverage is appropriate.

But from the point of view of your own interests, everything you wrote is very beneficial.

JSDoc doesn't require any transpilation. It runs as native JavaScript code by using comments as type-hints. I can understand not wanting to use TypeScript, kind of, but not using JSDoc as well is honestly mildly negligent, especially when simply inferring types, i.e. being more strict about type coercion, is a massive boon to productivity.

I'm on the fence. After AngularJS, where all the work I had put into creating reusable components, all of a sudden it was gone, superceded by Angular. Everything from scratch, now with Typescript. And then I was trying flutter and it was great but also, like Angular, half-assed and not there. Then I had a period of writing everything in plain JS and embedding that in SSR pages served by Go. No reactivity :( But great SEO :) Now I found quasar, the promise is write once, deliver on all platforms. I prefer Angular to Vue but it doesn't have anything like Quasar and the Material components are lacking. vuex-orm, despite being new has more functionality out the box than ngrx-data. If you go SSR with JS there is a huge performance impact vs Go (read cost in hardware). Another downside of quasar is since it's all just a Webview on mobile you can't use grpc to communicate. grpc-web uses base64 encoding on the payload, which makes it useless. You can't use nginx on the front with grpc-web. But then again I can make it work with a RESTful backend and a websocket notifier. I would love reactivity on the frontend but SEO is more important. Adsense doesn't monetize Angular sites, says they have no content. So IDK... On the backend I write monoliths. Go is powerful enough to serve about 400 million visitors on commodity hardware, a single server. I had a cluster of 3 but it was too much effort maintaining them. Every now and then something would break. Ipsec or whatever. So I got rid of it. 1 server with raid10 and daily backups. Like I wrote Go wins on the backend. The frontend wars are undecided for me yet. I'm just one guy so I'll go with quasar and vue for now, despite my love for Angular. Also Angular is Google as is Flutter. And with Google you can't be sure they won't arbitrarily just end support one day to the next because Google's CEO felt like it today. I would love if Svelte had the tools. React, I tried getting into it but since it's so popular there are also many half-assed libs. Take their material ui. Yeah it looks nice on the outside but when you're about to use it boobytraps everywhere. Maybe one time I'll make the jump from vue to react idk. Maybe one day there will be something like Quasar for react. Idk.

Excellent post, if only for the fact that its a great way to share "what works for me" at a time when most of our local JS/Web meetup groups have been put on hold due to the pandemic, or gone onto Twitch / Zoom, so its harder to have those casual "I'm really loving such-and-such" conversations now. Thanks for sharing. FWIW I also like the general keep-it-simple / YAGNI approach. I switched from TypeScript to straight up JSDoc and with the right IDE setup it works beautifully.

The aversion to build tools is strange to me, for two reasons:

1) The pain points usually come when you're configuring things from scratch. If you're always doing solo greenfield projects, you can just carry around a boilerplate project and you should be able to largely avoid messing with configuration after the first time

2) "I optimize for performance and quality" Well, doing a JS build can help a lot with asset size and therefore performance, especially compared to doing a transpile at runtime which is what it sounds like this person is doing instead

This is a fair post and fair enough for striving for simplicity.

On the TypeScript thing, if you're already using Parcel it can do all the TypeScript stuff for you with nothing extra required!

I'm grateful tools like webpack/babel exist but I find it a bit depressing we still need them, their use-case are for problems that should have been long-solved.

I'm happy that you have fpund a stack you enjoy using!

Why not use Vue-cli or react-create-app?

I also don't like to setup webpack but by doing that you learn a lot about how things work.

This is for example why I started to write my own component framework in vue. Just to learn the underling stuff. It is also open sourced ;) https://github.com/lampewebdev/lcs-components-yt

What about security? I’d like to know author’s opinion on that. Very often this job requires you doing tradeoffs between performance and security, productivity and low hanging fruits, manteinability and team or future team composition, or maybe avoid choosing the coolest and performant technology around because there might be a scarsicity of developers knowing that technology etc. etc.

As someone who spent the last weekend getting to know Svelte... And thus fighting with Snowpack, Typescript and @web/test-runner (and then ditching it entirely and setting up jest), reading this was pretty zen-like.

Gonna check to see if he has a template or boilerplate that he uses for new projects.

Might want to edit the title, this is not a Show HN.(https://news.ycombinator.com/showhn.html)

Interesting set of tools. I'd love to learn how it works and see the code, there has to be some true craftsmanship inside.

Something that is unknown to a wide range of today's programmers.

Even if you don't want to write Typescript, not even using TS as JS Intellisense is an odd choice, it already catches so much without requiring any build step.

Imagine inheriting that guy's codebase.