> Normal javascript works fine these days for a sprinkling of front-end interactivity. jQuery is not even necessary anymore.
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.
This is true. The question is whether it's necessary or good (for consumers, for businesses, for the software engineering profession, etc.).
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.
> Amount of money I have seen lost because people were using different versions of excel sheets that were not up to date is staggering.
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.
People on different excel versions causing business errors is going to have an order of magnitude higher problem than libraries not being up to date. At least an old version of react will still work - and if it had an error, that error was acceptable at the time of shipping. Plus the developer is in charge of updating libraries, presumably with some forethought. A user updating their excel at their whim is uncontrollable and irreversible.
> People on different excel versions causing business errors is going to have an order of magnitude higher problem than libraries not being up to date.
Do you have a link to software engineering research that would corroborate that opinion?
> Amount of money I have seen lost because people were using different versions of excel sheets that were not up to date is staggering.
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.
I wonder how much money has been lost hiring software developers to implement something that Excel was handling fine. (snark snark, sorry, of course there are a lot of good reasons to move away from excel, but many projects fail or money might have been better spent elsewhere given how expensive it is to contract out for something new)
In my experience in being hired years ago for this kind of work, there is a significant cost to going “web app” but I’d also sell custom excel plugins. Usually these businesses were hitting the limits of excel’s capabilities when humans need to be involved (complex and hard to adjust formulas, copy/paste mistakes, etc). Most businesses don’t realize they can just have a custom excel plugin, and sometimes that is all they need. Sometimes a web app or custom software is the better solution.
interesting... whats that look like? I know of VB script that can manipulate tables... does that let you do custom GUIs too? Any API where a webform could interact with excel?
I might like to get into this field, solving business problems without building a whole app sounds great.
Just install the SDK when installing Visual Studio. I don’t see why you can’t have an embedded web view as long as you love Internet Explorer… it’s easier to just create a native UI though and call an API.
Yes but as my experience shows process/structural problems are quite easily solved with software.
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.
> process/structural problems are quite easily solved with software.
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.
Well not everyone is building websites on the web. Building an app for the web is not some horrible thing. Google docs, sheets, etc are all perfect examples of the kinds of apps suited to the web: ones that benefit from the ability to be accessed from anywhere on any device, and encourage collaboration.
We had this functionality before web apps were a thing. I'm not going to claim it was some golden era/glory days in a bug-free, seamless cross-device nirvana, but it's not like it was a wasteland, either. And for all the promise of cheaper, better apps that the webapp paradigm has been suggested to bring, we still pay a lot for armies of developers to write this stuff, and it's almost uniformly worse in both quality and feature completeness.
Yeah, this is the most damning thing. It’s clear that the web platform seems to resist being tamed with our current tooling. Adding more devs doesn’t fix it. As time goes on I become more skeptical that tooling can even fix it.
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.
One established business and another startup I worked at absolutely thrived explicitly because we built web applications rather than native ones.
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.
This is really nice! Congratulations! I am surprised that this isn't more famous.
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.
You are not the first to comment on the video resolution. I really must redo those.
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.
No, you still don't need a web UI framework for rich front-end interactivity. That assumes however that your developers know how to write a callback function.
"You don't need a framework" assumes your developers will write code that operates with everyone else's code nicely, without accidently writing something that will be painful to remove in a year's time.
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).
Yes true! I once had the honour to work with a 'tech-lead' dev that rewrote a whole map application to AngularJS, which was the hype back then.
I remember him not being able to get a just slightly complicated chain of asynchronous stuff working in vanillaJS.
No problem, because he had AngularJS double binding now. No need to learn vanillaJS. Wicked stuff.
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.