[LordHeini]

To go quite a bit off topic.

The author says that he starts with a single html file and splits it or incrementally adds stuff when needed.

That course of action has proven to be a really bad idea on every non trivial web project I worked on.

Mostly for teamwork and maintainability reasons.

E.g there is no clear project structure, the next dev will not understand stuff and do things differently. And welcome to the chaotic legacy code hell. It's like Php all over but in Js.

I usually work for customers who to some extend now what they want. I choose an appropriate tech stack for that use case. The team can use that stacks conventions to develop the project. There is no need to slowly grow, everything can be done in parallel and due to the conventions stuff sticks together in the end.

This sort of work flow has a tendency to just pile incredible amounts of code in files thousands of lines long. That is going to be unmaintainable in no time.

Everyone claims they don't do that but they all lie (yes you too).

Also everyone has a chance to end up maintaining the resulting amorphous blob (could be you again).

This lacks tooling like hot reload, spell checkers, linting and so on. You will need that anyway so why don't you start with it?

Also you need tooling for deployment like config files. Tests, Ci and what not...

Lack of documentation. Since this follows your personal style your colleague needs to follow. A framework provides documentation for that. Working like this, the docs need to be written by the devs. Although they may claim otherwise they usually don't.

[dgb23]

You are optimizing for entirely different use cases.

There are a whole bunch of devs who work alone or in (very) small teams. For this type of work it’s really more of a hindrance to have an imposed structure and tooling.

We want to get to your goals as efficiently as possible. Minimal abstractions, guidelines, tooling, indirection, magic, surprises and general overhead are in order. We don’t want to struggle with questions like “how to do this in X”. We already know how to do it, so we just do it.

As time goes on and LOC get merged we find ways to add sensible structure and compress our code.

[mrweasel]

There's another comment that talks about medium to large project, and it's the same thing, it's a different use case. I don't care about medium or large projects, I need to add a quick semi-dynamic element to an incredible basic web app.

In my case, setting up a React or Angular project is going to be more work than just writing the whole thing in vanilla JavaScript. This has the added benefit that I actually understand what's going on.

The modern JavaScript frameworks are great for large projects, but it feels like learning Django in order to make an API that goes "pong" when you do a get request. I get why this happens. Vue looked great 8 years ago, small, simple and easy to get started with. Then it grew to support more and more use cases, and larger projects and now we need a new tiny framework. Or we can accept that JavaScript has come a long way and that many of us might not need a framework.

[oefrha]

No, proper structure and tooling (especially for HMR) are important productivity boosters for solo developers as well. Single file scales to about 1k LoC, it’s only viable for toys and tiny projects; beyond 2k-3k LoC you’ll hate yourself every time you need to change something (been there). And ad hoc shell script in place of npm/yarn/whatever proper package manager, which is way easier than said script? I hope that’s show business and not actually used.

Btw, this direct module import approach means you’ll be shipping a lot of unused code to users.

Edit: If you only need a tiny amount of progressive enhancement on top of static HTML: forget about this import map and ad hoc npm script business, use petite-vue (single script, 6KB, add a script tag like good old jQuery).

[selfmodruntime]

> There are a whole bunch of devs who work alone or in (very) small teams.

And you still need to reimplement a bunch of stuff if you don't use oss packages. And the next maintainer will curse your family for generations because of your own custom framework.

[mmcnl]

Imo being "smart" like this is reinventing the wheel and doesn't give you any productivity gains.

[dgb23]

It's not reinventing anything. It's just avoiding complexity until necessary.

[mmcnl]

Writing custom shell scripts to avoid complexity usually achieves the opposite result. I can Google npm errors, but not why a custom shell script fails.

Second, anyone reading the repo is now expected to understand not 1 but 2 languages.

Finally, the shell script performs basic tasks that npm does out of the box.

Because of above reasons I think this solution is needlessly complex.

[jacquesm]

As someone who does this too: it depends. If you take time out every now and then to completely refactor your code base it can actually be surprisingly effective. I've done exactly that on my last project and I'm pretty happy with the end result, you can have a look for yourself:

https://gitlab.com/jmattheij/pianojacq/-/tree/master/js

This project will likely never be finished, there are always nice new things to add or requests from people, there is no commercial pressure because it is a hobby project and I don't have a boss to answer to. And even if such refactoring operations take me two weeks or more (this one I did while I was mostly just working on a laptop without access to a keyboard so it was sometimes tricky to ensure that nothing broke) in the end it is worth it to me because I am also paying the price for maintaining the code and if it is messy then I would stop working on it. Project dependencies are the absolute minimum that I could get away with.

The project moves forward in fits and starts, sometimes I work on it for weeks on end and sometimes it is dormant for months. In a commercial setting or in a much larger team I don't think this approach would work.

[samwillis]

> If you take time out every now and then to completely refactor your code base it can actually be surprisingly effective.

So much this!

Current project I'm on, I own the entire front end for a major modernisation (AKA rewrite) of a legacy application and we are working in 4 week "sprints". I'm giving myself two days every month just to refactor the code I wrote that month.

How you plan to structure a project never works out, you always find better ways as you go and as the objective and priorities change (they always do).

On another tangent, before pivoting into software development I used to be a mechanical/industrial engineer. The parallels between coding and CAD are enormous. With CAD you also need to be spending 10% of your time "refactoring" your model. It's almost exactly the same from a maintainability perspective and leaving the model with good hygiene for the next person to work on.

[jacquesm]

> How you plan to structure a project never works out, you always find better ways as you go and as the objective and priorities change (they always do).

I always joke I write everything three times. The first time to get a feel for the space, the second time because I think I now understand it and then again when I finally really understand it. Most of the times these three look absolutely nothing like each other.

[samwillis]

I think that even extends over longer time periods to projects as a whole and an evolving team. Sticking to my current project which has a nearly 20 year legacy and looks nothing like what it was when it started:

V1: Perl CGI, HTML forms, very little js

V2: Perl CGI, JQuery, Ajax (done badly with js code generated by Perl code)

V3: Perl backend rest API (will be "public"). TypeScript+Vue front end.

Each time a transition has happened as the application features have outgrown the architecture, and more has bean learnt about how people use the product and therefore what it needs to do.

In this case it has now grown the the point that Node and build tools are required.

[jacquesm]

Neat, is this a public project. You make me curious what it is that you are hacking away at!

[samwillis]

Avoiding Googleable backlinks, if you search for "integrated antibody sequence and structure tool" you will find it.

I'm the first "product" person without a bioinformatics background to work on it. The new version isn't out, but is a significant rewrite with an aim to massively extend its functionality in future. (Current "public" version isn't even the current commercial version, and very 90s in style!)

Backend is a very large Perl codebase implementing a significant amount of algorithms from academic research.

It's been awesome to work on, my ideal sort of project where I can bring a technical product focus and learn about interesting technology and science at the same time.

[Timon3]

I looked through your code a bit, and there are a couple of things I'd flag in a code review (e.g. use of non-local variables). Ironically these are things that are a lot harder to do, and easier to spot, if proper modules are used.

[jacquesm]

I'm sure you would, and if you looked at earlier versions of that same code you'd see mountains more of those.

I'd love for everything to be perfectly pure though and side effect free. The pressure is always on to improve it further. As for code review, feel free and open tickets for whatever you spot and hopefully one day I'll get around to it. Better yet: submit pull requests.

[vidarh]

There is no clear project structure if you don't write down what the expected project structure is. Which you really need even with a framework, because the frameworks only provide really rough high level structure.

While I loathe files thousands of lines long, I also loathe the endless chasing of things from file to file that tends to be the result of applying big frameworks to tiny projects.

[bsenftner]

Really? It has been well over a decade since I cared about file length or number of files. Any number of code editors has search, multi-file search, and "go to definition". I've got one personal project that is a three.js character creator, where my js is one file of somewhere north of 200K lines. Who cares? I sure don't. If another were to join the project, sure, I'd break it up into smaller files so others can work on separate bits - but that's the only value of separate files anymore. Nobody prints code anymore, and if they do it is code fragments and not one's entire program.

[vidarh]

I find it a lot easier to reason about logical chunks of code that are clearly divided. I rarely want to see just a specific function, but a cohesive unit that can be read in sequence and make sense. You can do that in a single file too, but in my experience, large files tends to lead to code being spread out without a narrative determining order because people (myself included) are rarely disciplined enough. Files act as a convenient clear grouping to me. On the other extreme, when people insist on splitting everything up into the smallest little unit, it drives me entirely nuts for the same reason. I want to be able to read through the code without jumping back and forth all the time.

But when it's just you it's all down to preference, so do what works for you.

[deltarholamda]

I get where you're coming from, but I have on occasion wanted a fairly simple one-trick-pony sort of SPA. Think a GNU userland tool, not Word.

Thinking outside the node-vue-kitchen sink sort of development box is a good idea. Maybe you don't have a grand idea, maybe you just have a kinda neat idea. Punch that thing out fast and light. You can always grow it bigger, but maybe you don't need to.