I promise writing applications for the browsers is not challenging. You don’t need big frameworks or component madness that’s more of the same.
You don't, but in any sufficiently complex app you'll end up writing a sort of 'mini framework' of your own as you abstract all the things that crop up more than a few times. That framework might be really nice at the start but it'll get more and more hacky as the project continues, especially if you're constrained by resources. Eventually you'll regret not using something standard.
If there are more than a couple of developers on the project it'll be something no one really likes after a year or two.
If there are more junior developers it'll be a reason for them to want to get off the team because they won't want to be a part of the 'old legacy code'. Then it'll be hard to find people who want to join.
Eventually, as it gets harder to recruit people to the team because it's on a weird, legacy framework that no one knows, there'll be a big project to refactor it on to something more standard. That'll probably be React. At the same time most of the senior developers will be calling to scrap the codebase entirely and rebuild it (wrongly in almost every case, but they don't care and want a greenfield project to play with new things on.)
This is a story that has played out at every large org that builds apps internally, and probably a lot of startups as they mature and need to hire more devs. You might as well skip all of it and use a standard framework from the start.
Anyways this idea of internal frameworks has always been weird to me. Nobody says this of code outside the browser, so why would they say this inside the browser? When I think about in those terms this clearly becomes a simple organizational problem and I don’t need a framework telling me how to organize things like a parent telling me to do chores.
https://github.com/prettydiff/webserver
When you aren’t using framework like components state restoration is a single function that runs only on page load. There is no state explosion and on localhost the SPA fully renders and finishes state restoration in about 105ms from http request.
I would start by organizing the code in a sane and logical way. But that's why I said, if you enjoy coding this way, great.
I get the impression that people who are only used to seeing front end code as JSX don't have any idea how to proceed when its just JavaScript. If they aren't also writing code outside the browser they are likely never exposed to application code in any real form because all they see is template abstractions. The reality is that it is just JavaScript which is no different in the browser compared to in Node, except for calling a different API. If this is the case then anything that isn't JSX is cause for an anxiety attack, most especially if its more than 120 lines of code.
If you are not capable of reading code then no matter of alternate guidance will matter.
I knew anything I said your answer would be something in this line. You think what you wrote is amazing but it is just verbose bad abstraction. If you think the difference between 4k lines of code and separated logical modules is just a matter of fewer lines (which might not even be the case), there is nothing I can say to you but it is funny that you use this terrible code as an example. You literally wrote all DOM manipulation repetitively and inefficiently by hand. But it makes you proud! Congratulations, I guess.
I couldn't care less about JSX tho you made too many assumptions about someone that thinks the example code sucks.
It isn't about being proud, or awesome, or some silly vanity. Its about being fast, almost 100ms fast, and organized well enough for quick maintenance.
There are a bunch of amber flags that immediately stand out, like this being an almost 4k line file with a commit history by only one person, and an idiosyncratic approach to naming and formatting. None of that is necessarily bad on its own, but this feels like code that is written by the author for themselves, rather than for any other potential readers of the code. It's a lot easier to write code if you're the only reader, because you can keep a lot of the code's context in your head, and you don't need to write it down in the same way.
I skimmed through the start of the file and then jumped up the bottom looking for an entry point. From there, the table state jumped out to me as a thread I could follow, so I started exploring that.
The first thing that jumped out at me was how much defensive programming you are doing. There are lots of "if state X is not null" or "if event is not null" sections where it's not clear from the types or the logic that these values can ever be null. This makes me a bit nervous, because if you don't know whether something can be null or not, the reader is going to find it even harder to tell.
The next thing I noticed was how difficult it is to follow state changes around. Part of this is state being set in multiple places at once (e.g. `state.tables` and as data attributes on elements), but also because you use both `.dataset.xyz` and `"data-xyz"` fairly interchangeably, which makes it difficult to jump to the usages of some bit of state if that uses a different syntax.
This got me (finally) to some of the DOM manipulation code, which is what I was just eager to see in the first place. I landed in the tables.populate function, and the most surprising thing that jumped out to me here is that every table seems to be special-cased with a bunch if-else statements, partly for the rendering of each row, and also for updating the payload. Searching through this code, it seems like this mechanism of switching on the type of each module/table is all over the place, and that updating one part of the code is going to have massive knock-on effects on other parts of the code as well.
I'm going to stop here because I need to get on and do other things. I agree with you that you have largely managed to avoid building your own framework, but I think this is very much to the code's detriment: a small amount of abstraction would go a long way here in terms of, e.g. isolating the different tables from each other, or managing state effectively.
I can fully believe that you find it easy to write and maintain this code, but I suspect that has a lot more to do with you being the sole maintainer of this code than it does the clarity of the code. I see people confuse these two ideas a lot, but it's important to separate them.
Like I said at the start, I'm grateful for the chance to see your approach, and if it works for you then my opinion if it doesn't really matter. But it unfortunately does not convince me of your claims about the benefits of this style of development.
For me that comfort is achieved through reuse and audits around data structure types through use of TypeScript. Now that ThpeScript is natively supported in Node it’s even faster still because there is no need for a build or compile step. The code just runs as is. This is also even true for code that executes only in the browser so long as it’s imported into a node module, which I do anyway to reduce the number of file requests into the browser.
If you want reactivity in web components, you need a wrapper or another framework/small library.
Yeah it is. I don’t like React but I’ve been doing this since the days of MooTools all the way through Backbone to the libraries we have today. Once your app reaches a certain size and/or reaches a critical mass of contributors it does get challenging and modern frameworks reduce that challenge.
That can be taken way too far. Almost every time I’ve worked with Redux I’ve found it infuriatingly unnecessary. And React is far from the best framework out there. But it is a huge benefit all the same.
With regard to application size we fortunately now have TypeScript. All you really need to scale any application is types, functions, and code reuse.
It just takes the minimal amount of discipline, and some conventions. I know it can be done because I did it, lots of people did it just a few years ago (some of those apps are STILL running today.)