Building a web app with no framework

The author seems to misunderstand why upgrades are forced on you by frameworks. It is not the framework that forces the upgrade, it's the build tools. If you compile JS or CSS anywhere in the pipeline, you need build tools (webpack, sass, babel, typescript, ng cli, ...) that support your current OS and node version, and that support the latest javascript and css syntax. While browsers have perfect backwards compatibility and would support using new javascript and css features on old codebases, the build tools won't allow it. Sooner or later you have to upgrade them, and this forces framework upgrades, which forces application codebase rework. You can delay this a bit by dockerizing the build tools, but I find this imposes more costs than benefits.

You can either embrace the build tools and the upgrade treadmill they force on us, or you can choose a no build tools route. You can do the no build tools approach without a framework, but you don't have to. For example, back in 2008 I ported a PHP server-side rendered application to ExtJS 3 as an SPA. I maintained it until 2015 and then another team took it over which has kept it in active development to this day, and it's still on the exact same version of ExtJS 3. They've never had a good enough reason to upgrade it to another framework (mobile UI is done using native apps). You could never do this with an angular application, because the build tools would force an upgrade long before that time.

If you want to follow this no build tools approach using a more modern framework, I made a version of Create React App that requires no build tools. It's just a cobbling together of a bunch of libraries floating out there that enable using react in this way, but it works. If you build your web app with that you will never have to upgrade the framework if you don't want to, which means you will never forcibly have to rework the application's codebase either, even if like that ExtJS app you continuously develop it for 15 years. https://github.com/jsebrech/create-react-app-zero

They may not be using a formal published framework like those mentioned in the article, but they have a personal set of tools, techniques, and methods on which to design and build things.

To maximize flexibility, minimize dependency, & maximize performance means you have to use some set of tools & methods (aka framework) that have been designed to reach those goals.

I'm an old guy now, and I've rarely seen a need for a front-end framework. I know that sounds like heresy.

I've never bothered to learn Angular, React, NextJS, Svelte or any of the alphabet soup named frameworks. Normal javascript works fine these days for a sprinkling of front-end interactivity. jQuery is not even necessary anymore.

And with more recent technologies like Phoenix LiveView, there is very little need to use any of those front-end frameworks.

Count me as old-fashioned, but very few apps really need those kinds of frameworks. They could mostly do without them.

Frameworks are mostly necessary on the backend.

Like menus, wysiwyg, tables (sorting, search, pagination), tabs, photo viewers, modular windows, accordions, form builder, notifications, cards, process sliders, color picker, ratings, spinners, stepper, uploader.

Then binding all of that together.

Out of boredom once I went through the redux tutorial, and coded an alternate version with vanilla JS. My vanilla code was actually shorter, including the code needed to implement something like the observer pattern.

JS in 2022 is a really powerful language, and the DOM APIs have improved tremendously. Now people will hit back with "well you'll just end up re-inventing a framework" - but do you really? You just write an app against the abstraction of the DOM, instead of the parallel abstraction of the react VDOM.

I'm sure at a certain scale it makes a lot of sense to standardised on a framework so you can easily replace people who burn out after spending half their time updating libraries. But for smaller projects - I'm just not seeing it.

Across a large team it’s trickier. You need to teach and agree on all the patterns and organizing principles. I wouldn’t attempt outside of very specific circumstances.

In my early years (circa 2015) I didn't know much about patterns and wrote this "super smart" code where I called all the API calls yet never used the results directly, passes all the responses through a pipeline, wrote them into a flat normalized state, then fired change events, and my views actually listened to change events and reacted to them to update the UI with a single-source-of-truth local store in both Objective-C and Java for our iOS and Android apps. (There were other "weird" things that "I invented" but this was the relevant part)

Sounds familiar? Then, years later, I learned about React Native and redux, and saga, which (albeit with a completely different language and syntax) roughly worked the same way I envisioned and wrote my app (which worked flawless and bug-free by the way, a validation of the pattern works).

Now, I use React Native (which also came as a bonus because when I learned it I also have automatically learned its web-counterpart React.js as well) which has the same "vision" in terms of store and observing/reactiveness.

Now I use React [Native] because it gets my work easier, faster, and is super popular. I know it will probably not be super popular in, say, 15 years, but the ideas and patterns (reactive programming, state/reducers etc) will be here, and I can adapt to $(popular-reactive-framework-with-nice-syntax-of-year-2035) because that will be making my job easier. (Assuming that I'll still be doing mobile/web development)

I think as long as we want to get the general philosophy of these frameworks and know how to implement the parts needed from scratch if we ever need to, they do more good than harm.

With regards to the stated drawbacks of frameworks:

> comply with their API

Is a fair point I guess. It's also the obvious tradeoff that everyone is willingly accepting. It also isn't strictly true either In most frameworks, like React, there are escape hatches to do things however you want. I've written React components that hand over control of the rendered element to some pure JS code to do some animation with a library that doesn't speak React for example.

> upgrades are effectively forced

I guess so. These updates often come with perf improvements, new features and only rarely do they remove existing API's. Not having to maintain an impromptu custom framework means someone else is focusing on optimising for me while I focus on business logic.

> train to learn how they work

Isn't this exactly the same as bringing in a new developer to work on your custom web app build that does everything differently to everyone else? he has to learn your strategies for routing, caching, state propagation, etc, and has no external resources to help him.

> compromise with the drawbacks implied by delegating control

I think this is a good point for web apps with a very high performance requirement. I don't see the problem with almost everything else though.

> lose skills. A number of developers either don’t know much about the lower-level APIs (because they always used the framework layer instead) or live in the past

This has been true since before all of the big web app frameworks became popular. I don't see the frameworks themselves being responsible for lazy developers.

Maybe because I built SPAs already pre -10 and I think that finally (as Vue entered the scene) even frontend development can be fun, structured, testable, etc.

But the reason I write is this: When it comes to SSR, I still think node/js is absurdely slow.

Compared to almost any java rendering backends, where I'd expect no more than 50ms response time/thread I see 200-300ms/instance of nodejs.

What are your experiences? I'm I just doing it wrong :-)

The author of this article directly addresses that common trope, so these comments are lazy. In fact, this article has a very nuanced but important rebuttal to that argument:

> no, you’re going to write an app instead of a framework.

The idea that frameworks restrict you seems like an XY problem. They block you from doing one thing, but that's because there's already a specific idiom for that. When you're really "thinking with frameworks" you don't even think of doing X. The framework becomes your language and you design everything in terms of it.

I would also argue programmers are not lazy, but they should be if they want to get stuff done. Programmers like to tinker with random stuff and take things apart to see how they work. They'll gladly do 2x the work for half the performance if it means a solution they understand.

- login

- registration

- db views / grids

- forms

- api invocation

- navigation

- menus

- tabs

- lightbox

- forum

- wiki

- ecommerce

etc, etc, etc... I'm leaving out probably about 50 things.

Yeah, not just a "widget zoo" or something similar.

The reference implementation should be pretty big. Annoyingly big. It shouldn't be easy. Don't foist your web framework and push it until you do the work to show how it does and does not work well. It should have four or five levels of complexity in menus, forms, grids, navigation, tabs, and the like.

Because at this point there are likely several thousand web frameworks. Java alone likely has 200 since the old days of Struts.

"loose" rhymes with "goose" and is the opposite of tight.

It uses two libs, 200 lines and 500 lines each:

This lib for components: https://github.com/wisercoder/uibuilder

And this one for routing (HTML5 history API): https://github.com/wisercoder/mvc-router

React is overrated in my opinion. If your UI is mostly read-only then React works well. If it has simple interactivity then React still works well. But if you have components that manage their own interactivity then React breaks down. That's because such interactive components have state. When a component has state, and you want to update props then FB recommends replacing the component by changing the key. At that point you lose all benefits of React, including preservation of selection, scroll position, focus, etc.

Just finished putting https://subzo.com.au up with pure Golang, vanilla jacascript and CSS. Works well with SEO, it’s fast, easy to debug and understand and doesn’t require me to touch node!

That said I've found that with every other project I've worked on. I still maintain a B2B sales site on PHP 5.4 with Zend 1.1. There is no hope of migrating that anytime soon. Ironically that has no J's framework. The front end is such a mess and will never get the funding to clean up.

I think building with tools that allow such a great developer experience might be worth it. However F# makes it hard to find developers to maintain it in the future.

I hate the lack of longevity in our industry. I work with 30 year old CNC machines that are still supported by their manufacturer. I can't wait until our field gets that mature.

1. Its “components” compile away to plain DOM operations, so it’s well suited for a gradual transition story: existing behavior can wrap and be wrapped by new/replacement components without a need to reconcile between them.

2. Its reactive state model fits the app’s requirements very well, particularly in terms of needing to maintain two related but quite different representations of the data in tandem.

Solid’s performance being about as near to vanilla JS as possible is just bonus points to me, but certainly will ease concerns on my team.

There is a lot of freedom, performance, and security you sacrifice when you need so much help that you need a third party to simply just do it for you.

Or they just want to get the actual job done and don't see the value in cobbling together a homebrew solution, instead of using a library maintained by skilled devs with excellent documentation, battle tested in thousands of applications with a huge community of users and articles for support.

Like: I have a compiler that can target wasm32-unknown-unknown, how can I write a hello world in a language that said compiler compiles? Instead I'm presented with a barrage of frameworks and magical "bundlers". Help!

The only effective salve for your JS-is-a-broken-ecosystem nightmares is to reduce scripting in the client-side environment to the absolute minimum.

Rails and Django are indeed web frameworks but you can easily have Rails with React or Django with Svelte.

So the article includes them in the list of frameworks and then moves on to discuss a FE solution.

If you want to replace Rails or Django with vanilla you need also backend API. Of course you can do that with vanilla Nodejs.

But I dare you implement proper security from scratch.

When I do, though, I use vanilla Javascript. I'd really love to do framework-less Typescript. In theory, you can, I guess. But it is all wrapped up in NPM. Which, for some reason, I just don't like.

NPM-less Typescript seems like it would be pretty cool.

- Constructing a House Using Only Wood Glue

- Removing That Appendix Yourself

- Boiling an Ocean with Two Sticks

- Granting Your Own Wishes Without a Genie

- Hosting Your Own Funeral

training means so many things but in general, if it’s not “how we do work here” then it’s lacking at most orgs i’ve seen

I recently came back to the project, having run it sideloaded for a few months, with lots of thoughts and finally some implementation time up my sleeve.

I had a lot of trouble dipping back in. My various solutions, CSS trickery, etc .. all heavily commented at the time .. suddenly seemed overly complex, opaque, and tightly coupled(!). Much of the code was difficult to repurpose or build on. As I didn't have a build process my 2 external dependencies had been downloaded and hand-optimised for local import, however both had since been updated. While looking at these external dependencies I realised I probably was only utilising a small amount of functionality out of the combined 44kb gzip payload (websocket database stuff). But I didn't have any easy way to tree shake without a reneg on my satisfying (yet painstaking) manual build process.

I decided to spend a couple of hours trialing vitejs on the scaffolding / build side. So my front-end vanilla milkshake is still on the menu, but it's served up by an automated build process with the most efficient mix of ingredients. It took about 3hrs of research, fiddling and tea breaks to get back to where I started. My external dependencies had dropped in size by more than half. Everything else worked as before, except now with hot reloading.

Jumping back into the actual extension I started to clean things up. I switched my long, rambling, trick-filled CSS for much simpler nested SCSS. 30 mins later my complex rules now seemed a lot more legible and straightforward.

Finally I had another look at my 'super simple' regex based templating engine, something I was quite proud of and which worked fine, but was causing all kinds of complexity within my module based system of imports, exports and storage-backed state. I gave myself another 2 hrs to try and solve it. At first I looked for other simple, drop-in templating solutions that worked well within a module setup. But everything seemed convoluted. Finally I just dropped in Vue, as a trial only ... the fact I'd been looking for an excuse to trial the v3 syntax helped the decision here. Again, it was surprisingly straightforward I had it refactored and up and running in another 2hrs.

I'll save judgement until I have chance to let things go cold again, but I'm optimistic. My build is smaller, my development process is dramatically simpler, and the project is more legible and easier to build upon, despite the underlying complexity having increased. I am cognisant that there may be minor front-end performance hits due to the framework, but I'm also not convinced that my brute force regex templating solution was as performant as I would have liked. I will note one noticeable downside is that my dev compute load has noticeably increased (file watching, dev environment, and build-on-save are all handy for an extension).

I've skipped a lot of detail here. Happy to fill in any blanks.