If you just need a sprinkling of front-end interactivity, you don't need a framework and you never needed it. If you're building a web application with lots of features, re-used components, complex data structures, etc., a framework helps you a lot. And the web today is full of complex web applications, since most of what used to be desktop applications 15 years ago are now web applications.

The answer is subjective and lies within a spectrum, surely, but I tend toward the negative end of that spectrum. I don't believe the complexity in web applications is good (for anyone, except possibly browser makers, front-end developers and framework makers) and therefore it's not really necessary.

The browser today is mostly a terrible, inefficient, and limited functionality VM over the host OS, and that provides an inconsistent user experience across devices and even minor browser versions. What I've seen over the last 20 years of my lifetime has been an unfolding of a sort of tragedy of the commons in this context. We have a seeming endless supply of computational resources, "everyone" wants to exploit it in the most ruthless way possible, and it has lead to a deplorable state in the industry where bad practices and inefficiencies are not only tolerated but sought (for resume building, fast releases, whatever), and ultimately it results in terrible abuse/misuse of the resources we have.

We are re-implementing complex "excel apps" into web applications. Amount of money I have seen lost because people were using different versions of excel sheets that were not up to date is staggering.

Users expect full interactivity and instant calculations as they change values (just like in excel), doing it with "posting forms to back-end and recalculating" will not sell at all because it will be worse UX than excel. Having complex calculations over multiple fields require use of framework because making it with vanilla js is just pain with no MVVM and observables and two way bindings.

Then of course if you have web app you have one database all your employees are working on and all price items can be updated easily in some admin panel for every new customer.

Similar opportunity losses can be found through not keeping npm libraries up-to-date or through not doing full refactoring when there is a mainline change in a framework’s coding styles.

.NET, React, and Angular all suffer from that problem, to this day, in regular enterprise, and I’m sure Java does too.

Do you have a link to software engineering research that would corroborate that opinion?

Isn't that a processual problem? An organizational and structural problem?

I have seen the same with Google Sheets as with Excel. I know Excel isn't liked in a lot of tech circles but I personally think MS came a long way with it.

But yes - it can't solve organisational problems.

I might like to get into this field, solving business problems without building a whole app sounds great.

Then if someone has problem with process you tell them "it is software that requires it" and they comply.

Organizational problems are mostly problematic to translate to software and make projects die. Because if company is not organized, they won't have possibility to organize their requirements which will lead to problems.

My experience has been the opposite: the software is easy, but only if you already know what it needs to do. So you have to actually solve the problem first.

> Then if someone has problem with process you tell them "it is software that requires it" and they comply.

How incredibly user-hostile. If they have a legitimate concern, don't leave it unaddressed. If there's something important about the process they're missing, it's a mistake to use the current state of the software as an excuse.

If I would write "I like fight sports" would you write "how incredibly hostile, don't punch people on the streets"?

It sounded to me like the suggestion was to appeal to the supposed inflexibility of software whenever a question about process is raised.

The software is entirely malleable. If the process can't change, explain why. But don't pretend that the software can't change.

The impedance mismatch of a document viewer being made into a general app platform has yet to be truly overcome. All web apps try to eke out a living in the shadow of this.

That it seems to be everywhere these days is more a function of economics than anything else.

In the first case, we kept it narrowly tailored to two pages that absolutely needed that level of interactivity. In the second, requiring customers' employees to install an app on their phones would have been a non-starter during the sales process, and the lack of an app was a major selling point for others.

YMMV- oddly enough, both made use of the canvas element in critical parts (these were not simple CRUD websites).

That is my application that creates an OS GUI in the browser. Plenty of features with o framework.

* Code size (on the front-end) 2mb unminified.

* Load time in the browser (including state restoration) about 120ms.

* The first version took 15 days to write from scratch.

When people claim there MUST be a framework its clear they have no idea what they are talking about. It is clearly a case of Dunning-Kruger effect where they can compare their experience with frameworks on one hand... and they have nothing to compare it to, because its all they know.

That being said, this project is not "0 framework". You built a framework from scratch to suit the application.

That depends on how you define framework. By this definition, any computer program has an inherent framework and the term loses it's meaning altogether.

This project does not include an opinionated methodology or ideology on how to design features. There is no template nor scaffolding to plan out commonly implemented features. There is no way to estimate work for new unique functionality. There is no framework here, afaict.

One comment though: please have your video in Full HD format rather than 4k. Most people don't use 4K and so it is difficult to see your product demo.

And yes, I agree with you completely. There is really no need to use all of the fancy frameworks - plain vanilla js can give you quite a bit of power to build products like the one you made.

Back in August the project was mostly working. Multi-file copy worked across the network and across the security model. At that time I did not have any encryption working (TLS, WSS). I am working on this now. Certificate management/deployment is something I am new to and its a bit more challenging in a fully decentralized application. There are three stages to this:

1) Certificate creation

2) Certificate installation into the OS trust store

3) Certificate exchange between agents

I can do a self-signed root server certificate with confidence. I would rather have a root certificate for user level of the security model and signed device certificates for increased security against device spoofing, but I am failing to get correct. I can make it work like a hammer in Windows, but its not correct and it won't work at all in Linux. I suspect certificate exchange will easily be part of the invitation process, but then I need to device a certificate challenge as an enforcement measure. This is a humbling experience reminding at every step that I don't really know what I am doing.

Also there was a catastrophic routing problem. You could perform all file operations except copy from one remote user/device to a different remote/user device. Everything is super simple when the network effect is two nodes (a request/destination and a source). When there is only two nodes you don't need any routing support. Even when the security model actually pushes the transmission to three modes, such that you are sending to a user's primary device and the transmission must relay to that remote user's secondary device the transmission is still simple as this is assume by the security model without additional work. When the transmission expands to three separate nodes (request, source, destination) you have to introduce routing. The routing is greatly complicated by the security model.

Now that I am working on routing file copy over the network is broken. Once I introduce encryption and routing I will ready the project for public beta and then resume work on audio/video calls.

Frameworks generally enforce a pattern where things are quite well encapsulated, don't pollute global spaces, don't mess with prototypes, and manage callbacks well. Code written by one person, or a group of well-organised experts, also does that, but as soon as you have a less talented team, or a couple of juniors who aren't being overseen because the seniors are too busy, things creep in to the code that have the potential to blow up later. Frameworks help your team avoid those footguns (and introduce some different ones, but at least they're usually easier to manage).

and that was a choice

No it sounds like the comments on every post on HN remotely related to JS.

> I've never bothered to learn Angular, React, NextJS, Svelte or any of the alphabet soup named frameworks

That makes your opinion definitionally uninformed. If you had bothered to learn any of them, you would see that they have many benefits. Nobody is saying that you need any of them, but they are very useful.

The single greatest advantage to using any of the frameworks, however, is that they provide a relatively definitive way of solving any of the problems that you will have to solve, building an SPA. Routing, caching, state management, reactivity, inputs...There is no way around solving these problems, so you're either going with what they've got, or reinventing the wheel. But by reinventing the wheel, you're probably going to do a worse job than the team that has spent years solving these problems, and more importantly, you're losing access to a definitive way of doing things that you (and others) can refer to.

And that's the real kicker, is working with others. I worked as a contractor for years, and I can tell you the ease of jumping on a project using a front end framework vs a home baked JQuery or vanilla solution was practically immeasurably vast. Even jumping on a project using a framework I'd never heard of, but still had documentation and an online community, would have me up and running within a day or two at most.

Now, saying that, there is something to be said for separating UI from the backend. Yes, it adds ( a great deal of) complexity compared to server-side applications, but the reactive programming model is quite powerful, and useful even if you could build the application entirely on the server.

And obviously if you do need an SPA (e.g. wrapping WebView for iOS/Android) then you don't have a choice, or if you do you'll be reinventing the wheel, poorly.

There are frameworks that don't deliver an SPA - Next, Nuxt, Remix, etc. They also do a lot of work to remove as much frontend JS as they can, and more effort is going in to that delivery architecture at the moment. The idea is that devs write React or Vue based pages, and the framework figures out what the page actually needs and delivers only that code to the user. Routing is done on the server. They work very well.

I have found that, using simple JS classes and a small library for example lit.js, makes the project much more understandable and agile after years of code.

Regular fetch and promises, no rx.js and other abstractions on top of it.

jQuery is very easy to understand and edit in notepad. It doesn't require getting the right npm version / maintaining dependencies of specific package versions that may be depreciated.

Routing is better handled in the backend.

Backend frameworks have been around longer. By treating them as an api only you end up reinventing the wheel. Caching, state management, reactivity have been handled in the backend for awhile.

I think I'd argue that Phoenix LiveView is a frontend framework. Albeit a non-traditional one.

I have done a few projects using Knockout and Angular, and I've used Svelte a little too. My conclusion is that SPAs definitely have their place - but that place is in the minority, mostly for web apps with complex UI/UX.

In SSR (Server-Side Rendered) projects (typically ASP.NET Core for me nowadays, but I've used others too), things are just so much simpler, with fewer moving parts. A sprinkling of JavaScript is all that's needed, and even then a lot is reusable between projects. And now IE has finally died, jQuery is no longer needed, and browser support for ES6 is good, even writing JavaScript is less miserable than it used to be.

Of course SSR is simpler- request in, send / receive from a database, markup out. It isnt anything to do with SSR- your domain is simpler.

This echos my thinking whenever these framework/SSR/JavaScript debates come up. It's like everyone is talking past each other because there is no clarity around the complexity of what's being built.

So you're saying the domain is simpler while still satisfying the client's requirements? I think that's exactly the OP's point.

> My conclusion is that SPAs definitely have their place - but that place is in the minority, mostly for web apps with complex UI/UX.

Therefore, it follows that OP finds SSR is simpler, but only because OP only uses SSR for simple problems.

Users do not care about "immense developer productivity"

But a full page reload also clears out memory "leaks", old state accidentally kept around in caches, clinging to DOM nodes discarded long ago, but themselves still referenced by an old copy of a data structure, etc. If you go for a SPA, or even something in between, suddenly being careful about your data structures becomes a major concern to long-term app use, carrying a whole new category of debugging.

Implementing a form that autosubmits and updates an element takes very little js.

I remember what it was like to be faced with the task of building a new website from zero, and the temptation to reach out and consume other peoples' components/code/ideas. I don't know that you could actually master the art of vanilla web dev without first taking a ride on someone else's rollercoaster a few times.

> Frameworks are mostly necessary on the backend.

Sounds like I might be a double-heretic now...

For large applications (or small ones that may grow large one day), you absolutely need a framework.

Probably true if you look at it in a vacuum. I think if there's a big team a framework is certainly helpful to keep thing's organized and the borders a bit more defined. You also benefit from a community, best practises and documentation about how things should be structured and work.

Often not even there!

If you use something like BaseX[1] or eXist-db[2], both XML database and XQuery[3] implementations (they also have ways to act as SQL clients), you get REST-, user-, and database-management as native part of the programming language (XQuery).

For REST it must implement the RESTXQ[4] module standard, which both the named products do. Since XQuery understands XML natively, you get full templating, database queries, REST routing and much more.

[1] https://basex.org

[2] https://exist-db.org

[3] https://en.wikipedia.org/wiki/XQuery

[4] https://www.google.com/search?q=restxq

  Frameworks are mostly necessary on the backend. 

Sure, if you choose to buy in to a backend framework.

I'm not knocking Phoenix, but it's a tradeoff. I'd rather be able to write the backend without a framework and use the framework where I want to spend the least amount of time figuring things out, which is usually on the frontend/GUI. But everyone is different.

I feel the same way about both front-end and back-end frameworks - or at least the sorts of things that call themselves frameworks. Struts was kind of useful in its time, but in the end didn’t save you much effort as code. Usually when people talk about Java server side frameworks these days, they mean Spring, which is worse than useless, because it actively makes development harder.

Take for example excel and if you change value in one cell you get all calculations in sheet updated automatically.

Implement something like that without a framework and only plain js with dozens of fields having dependencies on each other, good luck :)

Implement something like that with cute "recalculate" button on the bottom of 3 screen scroll and no one will use your solution.

I just implemented a complete spreadsheet solution inspired by Airtable (sticky header and columns, column resizing, virtual scrolling, row selection, cell selection, cell editing, a few cell types) in approximately 500 lines of vanilla JS. No virtual DOM, no reactive data library, no framework. Just direct DOM manipulations. It performs great and is pretty easy to understand and extend.

For now, the reactive "field dependency" problem is just solved by re-rendering the entire spreadsheet when a cell is updated (really just re-rendering the visible rows, because of virtual scrolling). The state management is just not that complicated.

I suggest this sort of project as an exercise if you've found yourself engrossed by this or that front-end framework. My go-to front-end frameworks for the past few years have been Mithril.js and Vue, but they really would have been a major hindrance in this case. I can't imagine Svelte or Solid.js or whatever being any better...

Re implementing custom app with its business rules that was buried in excel sheet is a different thing. People don't want to buy excel in a browser, because they can have that already, they want their custom logic and in a way it works in excel.

Using the power of modern JS I fail to see the value of things like React. Maybe it has for the orgs of FB size but I do not operate at that level.

My backends are semi-stateful C++ servers with no frameworks either. Just some libs and std.