Building a web app with no framework(javarome.medium.com)
javarome.medium.com
Building a web app with no framework
https://javarome.medium.com/design-noframework-bbc00a02d9b3
206 comments
Unless the framework backports fixes (both bugs and CVEs) to the major version line you're using, you're forced to upgrade the framework to a newer major version line for the framework's sake, not the "build tools". And that upgrade will bring in all the other API changes that have happened in the new major version line.
The ExtJS codebase suffered from this problem, and this was solved by patching the ExtJS version ourselves to fix bugs as they were found (security issues and browser bugs). At first we would do minor upgrades of ExtJS and bring the patch file along to the new version, stripping out the fixes no longer needed, but when ExtJS 3 stopped getting new releases we just kept fixing the last 3.x version.
Of course, it would be better if this were solved at the framework level by having them ship LTS releases that could keep getting fixes at the framework level for many years and had no build tool dependencies. But this is not a hard requirement to going this route.
Of course, it would be better if this were solved at the framework level by having them ship LTS releases that could keep getting fixes at the framework level for many years and had no build tool dependencies. But this is not a hard requirement to going this route.
Are there CVEs in web UI frameworks?
Of course.
Angularjs https://www.cvedetails.com/product/73080/Angularjs-Angular.j...
react https://www.cvedetails.com/product/61450/Facebook-React.html
vue can't find
svelte https://www.cvedetails.com/product/82269/Svelte-Svelte.html
extjs https://www.cvedetails.com/product/62034/Sencha-Ext-Js.html
react https://www.cvedetails.com/product/61450/Facebook-React.html
vue can't find
svelte https://www.cvedetails.com/product/82269/Svelte-Svelte.html
extjs https://www.cvedetails.com/product/62034/Sencha-Ext-Js.html
>vue can't find
React's CVE-2018-6341 also affected Vue.
It'd be quite unusual for any big UI library to not have an XSS issue at some point in its life :)
React's CVE-2018-6341 also affected Vue.
It'd be quite unusual for any big UI library to not have an XSS issue at some point in its life :)
>Throwing out frameworks is throwing out the baby with the bath water.
Yes. But it's a baby snake.
Yes. But it's a baby snake.
> Frameworks manage component lifecycle in a way the browser by itself doesn't.
Which raises the question, what the heck has browser been doing after all these years? To replace jQuery we now have querySelector, but what's preventing browser's native support of "component lifecycle"?
Which raises the question, what the heck has browser been doing after all these years? To replace jQuery we now have querySelector, but what's preventing browser's native support of "component lifecycle"?
Anytime you have multiple independent companies who are competitive with each other collaborating on a shared standard, progress is going to be slow.
This is especially exacerbated in web browsers when a participant with a large market share intentionally stalls progress for competitive reasons (Safari, when web browser functionality gets too close to native apps).
This is especially exacerbated in web browsers when a participant with a large market share intentionally stalls progress for competitive reasons (Safari, when web browser functionality gets too close to native apps).
I love ExtJs. In my opinion, their framework and backward compatibility is something other frameworks should strive to achieve. Currently, React, Vue, Svelte etc. are still at what I consider to be at ExtJs 3 level, where each component was defined in a single file. I wish they would open source their framework and really only on support subscriptions rather than the ridiculous license that they have, although I think that ship has long sailed. I just wish there was something even somewhat close to ExtJs in the open source world. Sadly, hardly any front end developers are even aware of it.
It has been a long time since I looked at it, but (price aside) I seem to recall not being too interested in it because the actually complicated components (tables and such) had too many design and functionality constraints.
Partly, this was due to designers living in their own dream worlds prior to development, partly to functionality limitations.
When you have a green field to play in, buying into Extjs felt like sitting in a tiny pen, even if the grass was very nice.
Partly, this was due to designers living in their own dream worlds prior to development, partly to functionality limitations.
When you have a green field to play in, buying into Extjs felt like sitting in a tiny pen, even if the grass was very nice.
I use a framework even when it’s not 100% necessary because it’s easier to collaborate with other developers. The framework documentation and best practices helps a lot. What’s more, 5 years ago I started a simple app that didn’t require a framework. Then it grew and grew and grew. Today I would need to rewrite it in a framework but it would be a huge job.
The only framework people need is standards at the browser level, javascript and the DOM (shadow dom now). Same with on the backend .NET/Java/Node, there is already a framework.
Now for teams maybe you need to have a web framework but to say that makes things easier to understand is largely unproven, every project/product gets hairy over time, I have seen it more actually on Angular/React/Vue/Svelte etc sites than vanilla js.
Long term, maintaining a web framework, especially after the hype is gone, is always seen as more verbose and bloat as well as a maintenance nightmare. One day your web framework that made it "simple" will be a complexity spot and maintenance area you will see as a chore where other devs don't want to deal with it and the true complexity will show. Maintaining a javascript only site long term is much, much easier than a framework. In many cases javascript is supported much longer than frameworks that had their hype cycle fade.
In the meantime the abstraction of the complexifying web framework took you away from learning the actual simpler standards and framework, web standards, javascript and the parts of that actual framework.
React for instance jumped ahead and front ran WebComponents and ShadowDOM, those are both part of the browser and standards now. The killer feature phase of React is over.
Now for teams maybe you need to have a web framework but to say that makes things easier to understand is largely unproven, every project/product gets hairy over time, I have seen it more actually on Angular/React/Vue/Svelte etc sites than vanilla js.
Long term, maintaining a web framework, especially after the hype is gone, is always seen as more verbose and bloat as well as a maintenance nightmare. One day your web framework that made it "simple" will be a complexity spot and maintenance area you will see as a chore where other devs don't want to deal with it and the true complexity will show. Maintaining a javascript only site long term is much, much easier than a framework. In many cases javascript is supported much longer than frameworks that had their hype cycle fade.
In the meantime the abstraction of the complexifying web framework took you away from learning the actual simpler standards and framework, web standards, javascript and the parts of that actual framework.
React for instance jumped ahead and front ran WebComponents and ShadowDOM, those are both part of the browser and standards now. The killer feature phase of React is over.
> Today I would need to rewrite it in a framework but it would be a huge job.
If it's been 5 years, you'd have to rewrite it anyway to use whatever the framework of the week is. I'm only half joking. The shelf life of a lot of these frameworks seems to be 5 yeas.
If it's been 5 years, you'd have to rewrite it anyway to use whatever the framework of the week is. I'm only half joking. The shelf life of a lot of these frameworks seems to be 5 yeas.
5 years if you keep up with the framework bizarre churn of adding and changing things. If you did not, there is a fair chance that you run an update in a year and things are broken or unsupported or at least deprecated/unused by other developers.
Completely agree. If the project needs to be done quickly and using a popular framework is a great choice.
It speeds up development and increases the ease of adding new developers.
If you’re being paid, it makes sense to not waste your time solving the problems that frameworks would solve for you.
It speeds up development and increases the ease of adding new developers.
If you’re being paid, it makes sense to not waste your time solving the problems that frameworks would solve for you.
[deleted]
I’ve been working on an SPA built with no frameworks, a lot of WebComponents, and almost zero 3rd party code, and it’s fantastic. Package managers and frameworks have a lot of holdover momentum from an era when they were far more necessary, and I think a lot of teams and individuals have unacknowledged PTSD that prevents them from stripping out these legacy comfort & safety nets. Plus, it’s likely also a comfort for managers to believe a team is working within some sort of opinionated 3rd party-supplied guardrails.
How did you go about establishing structure and patterns that are typically enforced by frameworks? Was Web Components a big piece of that or were there also other major patterns you incorporated?
Great question. WC doesn’t provide any architectural structure beyond code encapsulation for your UI widgets. But this alone gets you per-feature sandboxing, even more strictly if you use the shadowdom to get runtime isolation as well (I typically don’t, but it’s a good fit for many solutions). This allows you to move ahead pretty quickly, knowing you can tear out and replace these elements easily if you got it wrong or the needs change, without core changes to the app. Yes, you still need foundational services like data access & caching, personalization, etc, which sit outside of WC, but the “best way” for those things is typically very tied to what you’re trying to build. So for those, I typically just start with a functional “sketch” of each service with a lot of code separation, and let the architecture emerge through iterations of refactoring as I start to understand what I need. The biggest refactor problems tend to have to do with precedence of rules and order of code execution, with the biggest issues at initial load as arrival scenarios get more complicated. But no framework is going to solve those problems optimally for your app, and more likely, the frameworks create more obstacles to doing it well. And then there’s always the problem that your devs need to be really knowledgeable in the framework to not apply it badly.
>How did you go about establishing structure and patterns that are typically enforced by frameworks?
I know PHP gets a lot of flak, but I think this is an excellent example of how that can be accomplished from a backend perspective using proven libraries.
https://github.com/PatrickLouys/no-framework-tutorial
I know PHP gets a lot of flak, but I think this is an excellent example of how that can be accomplished from a backend perspective using proven libraries.
https://github.com/PatrickLouys/no-framework-tutorial
In the example, the developer uses a library for most of the main features e.g. flip/whoops and FastRoute. By pulling together these libraries, in effect, they have created their own framework have they not?
here are a few resources:
video survey with a lot of nuance, especially relative to React: https://youtu.be/9FB0GSOAESo?list=PLNM_ABHoF7B0qDu0GI09eCXim...
https://developers.google.com/web/fundamentals/web-component...
https://developer.mozilla.org/en-US/docs/Web/Web_Components
https://lit.dev/docs/#next-steps https://lit.dev/docs/composition/overview/ https://lit.dev/docs/components/overview/
generally I do this: * make components that take responsibility for a bucket of concerns: like the app (track the app state--user, etc); then views (generic pages, more complex main-section things, etc); then more granular composable stuff like a highly specialized button (arbitrary example); * communicate state changes up via events, for global or highly generalized coordination between anything just handle that on the window/self (setup/undo on the component lifecycle methods); send/intercept/capture these messages on the event.detail (use composition and bubbling); * stick to first-principles: KISS, YAGNI; don't over-engineer your stuff, use encapsulation, if you don't need a shadowRoot it's not required, or use slotting..., use global styles where that's appropriate, use shadow encapsulation of styles where that's separately appropriate--keep those concerns separate and use common sense about appropriate separation of concerns; * don't automate or use external libraries or anything fancy unless it has a clear self-apparent business case (for my work or the customer or the business); forget all the assumptions of the frontend community--it's mostly noise
an example, it's very rough and I'm working through a starting point for myself: https://github.com/sourdough/starter
https://developers.google.com/web/fundamentals/web-component...
https://developer.mozilla.org/en-US/docs/Web/Web_Components
https://lit.dev/docs/#next-steps https://lit.dev/docs/composition/overview/ https://lit.dev/docs/components/overview/
generally I do this: * make components that take responsibility for a bucket of concerns: like the app (track the app state--user, etc); then views (generic pages, more complex main-section things, etc); then more granular composable stuff like a highly specialized button (arbitrary example); * communicate state changes up via events, for global or highly generalized coordination between anything just handle that on the window/self (setup/undo on the component lifecycle methods); send/intercept/capture these messages on the event.detail (use composition and bubbling); * stick to first-principles: KISS, YAGNI; don't over-engineer your stuff, use encapsulation, if you don't need a shadowRoot it's not required, or use slotting..., use global styles where that's appropriate, use shadow encapsulation of styles where that's separately appropriate--keep those concerns separate and use common sense about appropriate separation of concerns; * don't automate or use external libraries or anything fancy unless it has a clear self-apparent business case (for my work or the customer or the business); forget all the assumptions of the frontend community--it's mostly noise
an example, it's very rough and I'm working through a starting point for myself: https://github.com/sourdough/starter
The biggest crimes of web frameworks is they take you away into abstraction land away from the actual standards and they complexify simplicity, all of that under the guise of being more "standard" and more "simple". It is one of the greatest lies ever sold.
I remember how .NET WebForms and lots of Java boilerplate frameworks did that early on, or browsers breaking standards, they wanted developer lock-in just like web frameworks of today. They wanted to keep developers dumb by being "simple" as long as you stay in their walled garden where they handle the standards. No thanks...
I have been developing javascript for decades and I actually liked the original less Java like boilerplate of the previous iterations, and you can still do that. The people that push frameworks aren't always trying to make things more simple, they want control, lock-in and domain ownership. The last tool to really simplify in javascript was jquery and most of that is browser level now including selection the killer feature of jquery across all those document.all/document.layer days of pain. Those days are over, simplicity is being complexified now.
Tools like jquery and even Flash or other plugins were platform pushers that got the web to the place we have now which is better than ever for web standards, yet we have all these bloated frameworks on top now. In a way it is a bit like the xkcd comic with so many standards, just to not do javascript people built thousands of frameworks on top to "simplify" the standards that are simple now.
While web frameworks may have been needed for a time, and in certain team based scenarios, they are a crutch, a maintenance problem long term, they take actual standards out of experience and the worst is they make the simple complex. Web frameworks have become the DLL hell or dependency deepend that used to be used to attack other platforms. .NET and Java have less bloat now and are moving more standard, while javascript web frameworks only pretend to.
The web standards of today are amazing and take away the nee for frameworks today: from templating to html templates [1], vanilla javascript with classes [2] and async [3] and better api access like fetch [4] and browser support for vdom with shadow dom [5], components with WebComponents [6][7], css now with lots of additions like variables [8] transitions[9]/animations[10], flex and media queries, canvas/svg/etc for interactivity, and so much more. There is little need to use frameworks except to sell books and conferences and keep developers locked in.
As developers/engineers, the job is taking complexity and simplifying, ask yourself if your framework abstraction is doing that above actual standards that is a pain long term to maintain. Web frameworks were supposed to work together, they are now behemoth monoliths that limit dynamic and fluid systems that scripting are supposed to bring. People went out and made a scripting language for glue into Java boilerplate...
In areas like targeting a certain javascript ECMA version or polyfills, those are still worthy, the other pile of verbose bloat abstraction that is there is just that, a pile of "verbloat". "Verbloat" is a new word to define frameworks of today sold in as small helpers to replace jquery, that have grown to the size of dev lock-in tar pits. No developer in their right mind would use this for products/projects they control unless they have to at this point.
Basically this video summarizes the absolute unnecessary adventure of web frameworks and provides some comic relief to the absurdity of it all. [11]
[1] https://caniuse.com/template
[2] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
[3] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
[4] https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/U...
[5] https://caniuse.com/shadowdomv1
[6] https://caniuse.com/custom-elementsv1
[7] https://developer.mozilla.org/en-US/docs/Web/Web_Components
[8] https://developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_c...
[9] https://developer.mozilla.org/en-US/docs/Web/CSS/transition
[10] https://developer.mozilla.org/en-US/docs/Web/CSS/animation
[11] https://www.youtube.com/watch?v=Uo3cL4nrGOk
I remember how .NET WebForms and lots of Java boilerplate frameworks did that early on, or browsers breaking standards, they wanted developer lock-in just like web frameworks of today. They wanted to keep developers dumb by being "simple" as long as you stay in their walled garden where they handle the standards. No thanks...
I have been developing javascript for decades and I actually liked the original less Java like boilerplate of the previous iterations, and you can still do that. The people that push frameworks aren't always trying to make things more simple, they want control, lock-in and domain ownership. The last tool to really simplify in javascript was jquery and most of that is browser level now including selection the killer feature of jquery across all those document.all/document.layer days of pain. Those days are over, simplicity is being complexified now.
Tools like jquery and even Flash or other plugins were platform pushers that got the web to the place we have now which is better than ever for web standards, yet we have all these bloated frameworks on top now. In a way it is a bit like the xkcd comic with so many standards, just to not do javascript people built thousands of frameworks on top to "simplify" the standards that are simple now.
While web frameworks may have been needed for a time, and in certain team based scenarios, they are a crutch, a maintenance problem long term, they take actual standards out of experience and the worst is they make the simple complex. Web frameworks have become the DLL hell or dependency deepend that used to be used to attack other platforms. .NET and Java have less bloat now and are moving more standard, while javascript web frameworks only pretend to.
The web standards of today are amazing and take away the nee for frameworks today: from templating to html templates [1], vanilla javascript with classes [2] and async [3] and better api access like fetch [4] and browser support for vdom with shadow dom [5], components with WebComponents [6][7], css now with lots of additions like variables [8] transitions[9]/animations[10], flex and media queries, canvas/svg/etc for interactivity, and so much more. There is little need to use frameworks except to sell books and conferences and keep developers locked in.
As developers/engineers, the job is taking complexity and simplifying, ask yourself if your framework abstraction is doing that above actual standards that is a pain long term to maintain. Web frameworks were supposed to work together, they are now behemoth monoliths that limit dynamic and fluid systems that scripting are supposed to bring. People went out and made a scripting language for glue into Java boilerplate...
In areas like targeting a certain javascript ECMA version or polyfills, those are still worthy, the other pile of verbose bloat abstraction that is there is just that, a pile of "verbloat". "Verbloat" is a new word to define frameworks of today sold in as small helpers to replace jquery, that have grown to the size of dev lock-in tar pits. No developer in their right mind would use this for products/projects they control unless they have to at this point.
Basically this video summarizes the absolute unnecessary adventure of web frameworks and provides some comic relief to the absurdity of it all. [11]
[1] https://caniuse.com/template
[2] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
[3] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
[4] https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/U...
[5] https://caniuse.com/shadowdomv1
[6] https://caniuse.com/custom-elementsv1
[7] https://developer.mozilla.org/en-US/docs/Web/Web_Components
[8] https://developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_c...
[9] https://developer.mozilla.org/en-US/docs/Web/CSS/transition
[10] https://developer.mozilla.org/en-US/docs/Web/CSS/animation
[11] https://www.youtube.com/watch?v=Uo3cL4nrGOk
I wish this comment was pinned to the top of every Javascript discussion thread!
Great write up!
Any one saying they are not using a framework is not being honest with themselves.
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.
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.
Yup back in the day when I first started doing frontend work in ~2009. Everything was vanilla JS / jQuery.
What did we end up with? A custom build framework.
What did we end up with? A custom build framework.
Yup^2. It has ever been thus.
I started in the early ‘80s and of course built up a personal collection of BASIC routines to solve the common problems and get a quick start on the games I made. LOL, I still have to stop myself from calling the symbol to reference the upper left of a drawing surface “L”.
I got to pick the brains of my Mother (RIP), who got her start in the ‘50s, and it was the same. So between us we have three long generations.
I don’t really have illusions about these common frameworks. They are so full of drawbacks and unnecessary complexities, and you need to understand them pretty well to use them effectively in production for even slightly successful projects.
But they solve many of the problems you’d have to solve anyway, and in a way that may already be documented and maybe even well understood by others. Unless you’re really going for something bespoke/unique/different, the advantages are so large it’s usually worth it.
I’m starting a project for a client now, and I’m using a popular framework of today… because it’s a popular framework of today. E.g., if it’s successful, I don’t want to be making tweaks to this 5 or 7 or 10 years from now, and if I’m using a popular framework, maybe I won’t have to. (And if it’s not successful, it doesn’t matter what I used.)
I started in the early ‘80s and of course built up a personal collection of BASIC routines to solve the common problems and get a quick start on the games I made. LOL, I still have to stop myself from calling the symbol to reference the upper left of a drawing surface “L”.
I got to pick the brains of my Mother (RIP), who got her start in the ‘50s, and it was the same. So between us we have three long generations.
I don’t really have illusions about these common frameworks. They are so full of drawbacks and unnecessary complexities, and you need to understand them pretty well to use them effectively in production for even slightly successful projects.
But they solve many of the problems you’d have to solve anyway, and in a way that may already be documented and maybe even well understood by others. Unless you’re really going for something bespoke/unique/different, the advantages are so large it’s usually worth it.
I’m starting a project for a client now, and I’m using a popular framework of today… because it’s a popular framework of today. E.g., if it’s successful, I don’t want to be making tweaks to this 5 or 7 or 10 years from now, and if I’m using a popular framework, maybe I won’t have to. (And if it’s not successful, it doesn’t matter what I used.)
Yeah, vanilla js for large projects only makes sense if you don't agree with with the way existing frameworks are doing things, because you are going end up creating a framework for the project anyway.
Wow. The author is speaking about Javascript front-end frameworks.
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.
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.
> 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.
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.
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.
It is necessary and good.
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.
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.
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?
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.
But yes - it can't solve organisational problems.
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 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.
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.
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.
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.
I wonder why people so often are picking least charitable interpretation and go with it.
If I would write "I like fight sports" would you write "how incredibly hostile, don't punch people on the streets"?
If I would write "I like fight sports" would you write "how incredibly hostile, don't punch people on the streets"?
Can you help me see the more charitable interpretation here?
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.
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.
VB6 was better at this use case for 1/8 the resources, and had a much easier learning curve.
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.
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.
Winner!!
[deleted]
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).
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).
https://github.com/prettydiff/share-file-systems
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 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.
First of all, this is awesome!
That being said, this project is not "0 framework". You built a framework from scratch to suit the application.
That being said, this project is not "0 framework". You built a framework from scratch to suit the application.
> 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.
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.
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.
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).
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).
Maybe the idea of throwing a bunch of junior devs at something is suspect to begin with?
but then the juniors never become the experts
They become managers long before that happens.
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.
> most of what used to be desktop applications 15 years ago are now web applications.
and that was a choice
and that was a choice
That was a choice that very few of us made but we all have to live with. Such is life.
I feel the same about single-page applications. Give me good old fashion static HTML and CRUD database calls on a single production server with a back-up server, development server and live-test mirror server and using 1995 hardware it could handle 250K simultaneous users easy. Things have gotten insanely bloated and big-tech dependent with a huge price tag to build and maintain.
This is true. I wonder how servers used to scale very well in the past.
> I've rarely seen a need for a front-end framework. I know that sounds like heresy.
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.
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.
Your entire argument is predicated on building an SPA; if you don't need an SPA then you de facto do not need a frontend framework (which is what the OP is implicitly saying, do as much as possible server-side).
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.
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.
Your entire argument is predicated on building an SPA
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.
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 am also working as a contractor and 3-4 year old Angular projects usually are a total mess, there are tons of plugins for simple things and when you want to update npm packages, you basically break the project.
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.
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.
The ease of working with a react version from 2015 vs jquery?
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.
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.
> And with more recent technologies like Phoenix LiveView, there is very little need to use any of those front-end frameworks.
I think I'd argue that Phoenix LiveView is a frontend framework. Albeit a non-traditional one.
I think I'd argue that Phoenix LiveView is a frontend framework. Albeit a non-traditional one.
Another old'ish guy here, and I feel the same way.
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.
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.
Is it not simpler because the applications themselves are simpler? I mean, when you say that client frameworks like angular and svelte have their place with complex UX/UI interactions.
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.
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.
> 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.
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.
I use miro and figma as examples of products that would be extremely hard to build as a traditional SSR app.
> your domain is simpler.
So you're saying the domain is simpler while still satisfying the client's requirements? I think that's exactly the OP's point.
So you're saying the domain is simpler while still satisfying the client's requirements? I think that's exactly the OP's point.
OP said:
> 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.
> 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.
Non-complex UI/UX != Simple problems. Also, most problems people have don't need complex UI/UX.
[deleted]
Having to refresh the page every time you make a change or open a modal is a terrible user experience.
Watching widgets/components freeze after an interaction because of a poorly-handled race condition in the JavaScript, dropped or mis-handled/scheduled async requests, and inconsistent cross-component state management isn't any better. It's arguably worse, because now the user has to guess as to whether something is wrong with the application or not and then refresh anyway.
Users don't really know what they want, and I'd wager that most are willing to accept a page refresh if they understood the immense productivity gains that developers like achieve, for a worse "user experience".
> Users don't really know what they want
Users do not care about "immense developer productivity"
Users do not care about "immense developer productivity"
You can replace a chunk of innerHTML faster than a full page reload, using a near-trivial piece of vanilla JS.
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.
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.
https://sr.ht/ is faster than most SPAs I know and it refreshes the page a lot
It's not faster despite being in WiFi
This is a false-dichotomy/straw man. The conversation is about a javascript-heavy approach being overkill. I haven’t seen many arguing for noscript here.
Implementing a form that autosubmits and updates an element takes very little js.
Implementing a form that autosubmits and updates an element takes very little js.
This is trivial with a sprinkling of JavaScript - our pages do update as required after form POSTs, for example.
What makes it a terrible user experience?
Nonsense :)
I find deep joy in constraining my web development toolset these days.
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...
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...
I think a huge part of the value frameworks bring is a common vocabulary. Whether or not it makes it easier to write code might be debatable, but it absolutely help scales communication and decision-making. Everyone in your org building UI components knows what the expectation is. And new joiners can be onboarded quickly if they have experience. Using a framework and a strict linter is probably a tax on productivity when it comes to churning out code, but it's a major booster to the time it takes to understand code written by someone else.
Modern frameworks help to separate state from code. And also to reduce the amount of work in case of a state update.
For large applications (or small ones that may grow large one day), you absolutely need a framework.
For large applications (or small ones that may grow large one day), you absolutely need a framework.
Yeah, it’s not like anything ever got done before heavyweight front end frameworks /s
> Count me as old-fashioned, but very few apps really need those kinds of frameworks. They could mostly do without them.
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.
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.
Frameworks are more valuable if you have to work with junior developers.
> Frameworks are mostly necessary on the backend.
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
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
This sounds like giving the client direct access to the database. Sounds like a great way to facilitate data exfiltration attacks.
Frameworks are mostly necessary on the backend.
> And with more recent technologies like Phoenix LiveView, there is very little need to use any of those front-end frameworks.
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.
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’ve rarely seen a need for a front-end framework
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.
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.
My favorite front-end framework is [VanillaJs](http://vanilla-js.com/).
While I agree, I always use vanilla (never used jquery either) but I don't do opinions about things I'm not familiar with. No doubt all the framework research produced useful abstractions that we now have in js or should have.
[deleted]
[deleted]
Frameworks van be useful in any large dev project. It can bring structure. Things like routers, http request processors, object binding, ui components and many more.
Sveltekit deployed to vercel and you might need no back end at all, much less a framework, and come away with a fast single page app with fast dev iteration speed.
[deleted]
There’s a growing school of thought of the exact opposite: end users expect the UX that frameworks deliver and the back-end is simply an API in front of a DB.
I don't know if it is growing thought of school. I think it is just obvious direction.
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.
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.
>Implement something like that without a framework and only plain js with dozens of fields having dependencies on each other, good luck :)
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...
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...
That is not what I am implementing.
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.
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.
This tactic of sending me a custom client in JS that exchanges blobs of JSON and drives the display I generally dislike when I'm in the browser. It is, however, nicer to reverse engineer than in the old days, where I'd have to parse data from HTML.
[deleted]
Hear hear. We have zero problems not using web frameworks for our SPAs. Just a couple of libs and we write web components here and there to solve particular tasks when needed.
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.
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.
It continues to boggle my mind how difficult it is to set up a simple crud app with user reg/logins, record creation, record search and list of records (ie, 90% of apps).
Totally! Have been 23 years in tech now (specifically in enterprise software) and am still amazed that we keep reinventing the wheel over and over again. Then again that is the only way software can keep demanding a premium. Standardize and you are racing it down to being a commodity. This is the natural cycle in any industry but software adamantly keeps it self in the handicraft stage.
I'd say that it depends on what you're building and if you work in a team - there's so many components that would require a lot of work to create in vanilla if used together in the same app.
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.
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.
I feel like people severely over-estimate the level of abstraction some frontend tools give you.
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.
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.
One think I'm missing in vanilla JavaScript is reactivity. What's the simplest way to make it so that the page will always display the current value of a variable (or something calculated from the current value)?
This is why I just love Sveltekit. There is just not that much to even learn beyond vanilla JS.
I once tried to learn Svelte, expecting to be able to write a simple webpage in HTML and JS and having Svelte make it interactive, but it asked me to clone a whole template repo. No, thanks.
Proxy [1] is one way to do it using vanilla JavaScript.
[1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
[1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
Something like the observer pattern:
https://en.wikipedia.org/wiki/Observer_pattern#JavaScript
If you look at it from another angle, you might see that `setState` could take a function oldState => newState instead of a raw value. Then you have a `reducer` in the sense of redux.
You could also just make the list of observers functions, instead of objects with the signal method.
All easily done in about 20 LOC.
https://en.wikipedia.org/wiki/Observer_pattern#JavaScript
If you look at it from another angle, you might see that `setState` could take a function oldState => newState instead of a raw value. Then you have a `reducer` in the sense of redux.
You could also just make the list of observers functions, instead of objects with the signal method.
All easily done in about 20 LOC.
How do the frameworks you use do it?
If the value is remote, I assume a websocket or regular AJAX poll. If the value is local, simply binding an event emitter to the DOM should do it. Both would be lower load and compute than most frameworks.
If the value is remote, I assume a websocket or regular AJAX poll. If the value is local, simply binding an event emitter to the DOM should do it. Both would be lower load and compute than most frameworks.
https://github.com/zserge/q, an experimental minimalistic clone of Vue, uses object.defineProperty. (There has been an attempt to use Proxy instead, but there's a problem with it: https://github.com/zserge/q/issues/1) I don't think I could make it any lighter if I wanted to.
How do you manage the lifecycle of objects with the observer pattern? I saw an example of the pattern below that is crucially missing a 'remove' function to unsubscribe from the subject. Like when using events at the app/controller level, I have found a layer/glue starts to form associated with the adding and removing of subscription handlers, and it is this subscription management layer where the majority of complexity and bugs lie. Being inspired by immediate mode renderers, this is what makes React so great - it basically eliminates this entire layer. I might have PTSD working with observers and events from my AS3 days, but if I were building a single page app I wouldn't use the observer pattern over React unless there was a robust way to manage the subscriptions. Perhaps I am overcomplicating something that is actually pretty simple, but I imagine using the observer pattern by itself doesn't really scale beyond the component level?
Yeah that's an interesting problem. I mean the simple answer is you just make an unsubscribe method. But that doesn't solve the layer of adding and removing subscription handlers.
Using a subtree, childlist MutationObserver, you can implement a disconnectedCallback for non-custom elements. In the callback, you can clean-up any event handlers that you have added to the element yourself.
The simple answer from FrTime is to use weak references.
On personal projects, hell yes, this is my favorite way to work.
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.
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.
I think we should find a balance between on using frameworks. Here's my experience with mobile, but the same idea applies:
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.
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.
> Now I use React [Native] because it gets my work easier, faster, and is super popular.
In what way was it easier and faster than what you had, though? Like, you didn't explain that part.
My experience is that the systems I develop "stand the test of time" in that even a decade after I develop them I still enjoy working with them, and I "get them" as I built them, myself, from nothing. If they don't do something, it is easy for me to add that functionality, as I know how to extend what I built. Meanwhile, if I discover I did something wrong--and we all do something wrong--I can just fix it, no matter how much skew that might cause, as I am in charge of the entire codebase.
However, when I work with other peoples' code, none of this is true. If it doesn't do something I need, I am generally stuck hoping someone else is willing to add the functionality, or I am probably going to just have to do without. Sometimes I can add it myself, but then I am maintaining a fork of someone else's project, and they have no reason to not break what I dis constantly. The other peoples' code of course also has mistakes--as we all make mistakes--but those mistakes tend to never get fixed as they are afraid of breaking other peoples' projects that rely on them: the sheer amount of broken bullshit I put up with to use Flutter is insane.
Meanwhile, I used to think that the people who built libraries would at least tackle "the hard parts" such as building world-class security into their frameworks and ensure backwards-compatibility support for as many old platforms and browsers as was feasible.
Only, then I became a security expert and discovered that these frameworks are littered with serious systemic issues that they merely "mitigate" and then re-introduce the same kinds of mistakes over and over again. In my projects, once I learn about a class of bug, I go to whatever lengths possible to re-design my APIs to prevent that kind of bug going forward, and I also have then personally "learned" about the class of bug and--because it is just me writing the code--I can even just trust myself to not re-introduce an issue. I have never seen a framework project that cared enough to break all users every time they learned about a new class of issue to truly prevent it going forward, and they have "too many cooks" to trust any of their developers to not keep doing dumb shit over and over again.
I also had to learn time and time again that framework developers are in fact the LAZIEST developers I have ever had the misfortune of interacting with, and they will happily drop support for random platforms even when there are non-negligible numbers of people still using them: as a brutal example (but one of many many many) when virtually all of my educational users were bit by a bug in jQuery--which of course isn't even a framework and frankly the ONLY thing it supposedly does is provide a browser abstraction--that crashed (like the whole browser would die) Safari 1.x, and I talked to my friend who worked on jQuery core about it and he told me "no one uses Safari 1.x anymore" even though everyone except me living in my apartment was even still using it, I realized that I should have just kept using my own jQuery-like stuff (which was frankly better anyway: I switched as I figured "jQuery is popular and documented and other people will understand it"... and our big release demo day crashed and burned because of that incorrect mental model).
So I just don't get it: why is using React better than what you had? How much effort would it really have taken you to just get your code to the point where you could have avoided React? What is really the goal of running on the framework treadmill to chase "popular" frameworks rather than just building something you trust and using it... potentially for the rest of your life? Because I am now 40, and if I could go back in time and NOT use every framework I ever used, going back to when I was a kid programming (as I have been programming since I was like 6 or 7)--and yet still have all of the jaded and cynical lessons I learned from using it (so I know to avoid them going forward)--I would, as I am sure I'd have managed to build every project that touched one easier and faster.
In what way was it easier and faster than what you had, though? Like, you didn't explain that part.
My experience is that the systems I develop "stand the test of time" in that even a decade after I develop them I still enjoy working with them, and I "get them" as I built them, myself, from nothing. If they don't do something, it is easy for me to add that functionality, as I know how to extend what I built. Meanwhile, if I discover I did something wrong--and we all do something wrong--I can just fix it, no matter how much skew that might cause, as I am in charge of the entire codebase.
However, when I work with other peoples' code, none of this is true. If it doesn't do something I need, I am generally stuck hoping someone else is willing to add the functionality, or I am probably going to just have to do without. Sometimes I can add it myself, but then I am maintaining a fork of someone else's project, and they have no reason to not break what I dis constantly. The other peoples' code of course also has mistakes--as we all make mistakes--but those mistakes tend to never get fixed as they are afraid of breaking other peoples' projects that rely on them: the sheer amount of broken bullshit I put up with to use Flutter is insane.
Meanwhile, I used to think that the people who built libraries would at least tackle "the hard parts" such as building world-class security into their frameworks and ensure backwards-compatibility support for as many old platforms and browsers as was feasible.
Only, then I became a security expert and discovered that these frameworks are littered with serious systemic issues that they merely "mitigate" and then re-introduce the same kinds of mistakes over and over again. In my projects, once I learn about a class of bug, I go to whatever lengths possible to re-design my APIs to prevent that kind of bug going forward, and I also have then personally "learned" about the class of bug and--because it is just me writing the code--I can even just trust myself to not re-introduce an issue. I have never seen a framework project that cared enough to break all users every time they learned about a new class of issue to truly prevent it going forward, and they have "too many cooks" to trust any of their developers to not keep doing dumb shit over and over again.
I also had to learn time and time again that framework developers are in fact the LAZIEST developers I have ever had the misfortune of interacting with, and they will happily drop support for random platforms even when there are non-negligible numbers of people still using them: as a brutal example (but one of many many many) when virtually all of my educational users were bit by a bug in jQuery--which of course isn't even a framework and frankly the ONLY thing it supposedly does is provide a browser abstraction--that crashed (like the whole browser would die) Safari 1.x, and I talked to my friend who worked on jQuery core about it and he told me "no one uses Safari 1.x anymore" even though everyone except me living in my apartment was even still using it, I realized that I should have just kept using my own jQuery-like stuff (which was frankly better anyway: I switched as I figured "jQuery is popular and documented and other people will understand it"... and our big release demo day crashed and burned because of that incorrect mental model).
So I just don't get it: why is using React better than what you had? How much effort would it really have taken you to just get your code to the point where you could have avoided React? What is really the goal of running on the framework treadmill to chase "popular" frameworks rather than just building something you trust and using it... potentially for the rest of your life? Because I am now 40, and if I could go back in time and NOT use every framework I ever used, going back to when I was a kid programming (as I have been programming since I was like 6 or 7)--and yet still have all of the jaded and cynical lessons I learned from using it (so I know to avoid them going forward)--I would, as I am sure I'd have managed to build every project that touched one easier and faster.
It's mostly collaboration-related: I work in several projects with other people. What I have built for my project might indeed be better than React for that particular set of needs, but I'm much more likely to find people who know React (or any other popular framework, React's just an example here) and start working with them, which would be impossible with my custom framework. Actually exactly this happened: even though my code was super-clean (for me, at least) it took me days to show how it worked to a collaborator. In the end he gave up because no matter how I explained him, he wasn't learning it, he was memorizing it (maybe my fault for not being clear, maybe his fault for not focusing enough to understand), and we gave up and because of business constraints I let him go his way, messing up the whole project with spaghetti code.
On the other hand I joined a React Native team, and day #1 I was productive, writing actual working code, because we spoke the same language: after a brief one-hour intro to the project by the people who wrote it, I knew the hierarchy, how reducers and actions were organized, queries were dispatched etc.
I hear you, and what you do is actually what I personally love doing too. Sometimes I try to reinvent the wheel and that's not necessarily bad: it teaches me A LOT about why some frameworks/libraries are the way they are (just like my own code before I knew about React and how the idea was similar) but if I'm going to collaborate with others I'd still use React or whatever suits as the common denominator of all devs for the sake of throughput and maintainability. It's not that I don't trust my code, it's more that I just have trouble teaching it (or lose a lot of time doing it while I have tight deadline constraints).
On the other hand I joined a React Native team, and day #1 I was productive, writing actual working code, because we spoke the same language: after a brief one-hour intro to the project by the people who wrote it, I knew the hierarchy, how reducers and actions were organized, queries were dispatched etc.
I hear you, and what you do is actually what I personally love doing too. Sometimes I try to reinvent the wheel and that's not necessarily bad: it teaches me A LOT about why some frameworks/libraries are the way they are (just like my own code before I knew about React and how the idea was similar) but if I'm going to collaborate with others I'd still use React or whatever suits as the common denominator of all devs for the sake of throughput and maintainability. It's not that I don't trust my code, it's more that I just have trouble teaching it (or lose a lot of time doing it while I have tight deadline constraints).
That's a lot of words to extol building your own framework for each project you start. I know the articles ends with saying this isn't what is being suggested... but it looks like it.
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.
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.
I agree with all points in comment and would add:
- frameworks forcing updates is good, your custom code still having that XSS for 20 years you don't even know is liability not a "saving of money"
- frameworks are bringing XSS protections, navigation fixes, do a lot of things better than would be done by random devs from scratch
- loosing skills is just Plato saying "if kids start writing things down, their memory will deteriorate" or people who pride in writing SQL by hand that ORMs are bad and I saw enough of "proud SQL writers" making more problems for the project than helping and I still know how to write SQL and the same I could use JavaScript browser API by reading some documentation if I need to
- frameworks forcing updates is good, your custom code still having that XSS for 20 years you don't even know is liability not a "saving of money"
- frameworks are bringing XSS protections, navigation fixes, do a lot of things better than would be done by random devs from scratch
- loosing skills is just Plato saying "if kids start writing things down, their memory will deteriorate" or people who pride in writing SQL by hand that ORMs are bad and I saw enough of "proud SQL writers" making more problems for the project than helping and I still know how to write SQL and the same I could use JavaScript browser API by reading some documentation if I need to
I wouldn’t call React a framework personally. To me it’s a library like moment.js or ramda.
I know the React team like to claim that it's a library, not a framework, but I don't buy that at all.
My definition of a framework is code which defines the architecture of the rest of your application.
React as practiced in the real world absolutely does this. Theoretically you could plug it in as just the library that does the templating, but I've never seen a real-world codebase for which that appears to be true.
I'm ready to be convinced otherwise!
My definition of a framework is code which defines the architecture of the rest of your application.
React as practiced in the real world absolutely does this. Theoretically you could plug it in as just the library that does the templating, but I've never seen a real-world codebase for which that appears to be true.
I'm ready to be convinced otherwise!
I was on team “React is a Library” but for the most part that changed when the hooks and context API were added. The addition of those, relatively simple, tools made it possible to not need the additional state management libraries like Redux/MobX etc that, up until then, were necessary add-ons to manage state and data. This made React more of a full Framework in my opinion.
That being said React can still be dropped into a relatively static page to add small bits of interactivity.
So at this point React seems to span both Framework and Library depending on the use case.
That being said React can still be dropped into a relatively static page to add small bits of interactivity.
So at this point React seems to span both Framework and Library depending on the use case.
React defines the shape of most of the code in your code base in a way that neither moment.js or Ramda does. You can call it a library, but it sure quacks like a framework.
In every react project I've worked on, the majority of the business logic was written inside components (the old "code behind" anti-pattern from WinForms days), and about half the files had the extension "jsx" or "tsx". It also required the use of a react specific browser extension to debug effectively.
React is a de-jure library, but a de-facto framework.
React is a de-jure library, but a de-facto framework.
I’d call it both. There’s the use case of adding small react components sprinkled through an application, in this case it’s a library.
Then there’s the use case of having everything be a react component, and you use lots of react specific libraries, and a react router, react form handler, etc etc. that’s react the framework.
Then there’s the use case of having everything be a react component, and you use lots of react specific libraries, and a react router, react form handler, etc etc. that’s react the framework.
React is a sort-of-library that exposes an API to plug in the missing pieces to produce a framework. OP of the article would probably actually like it. Want to write your own routing or state management? by all means go ahead.
React is a framework, not a library.
> 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.
it does seem that way. i’d add that even with established technologies, a company should have a set way to do stuff that is trained internally. frameworks et al frequently have multiple strategies or you want to extend a framework primitive.
it does seem that way. i’d add that even with established technologies, a company should have a set way to do stuff that is trained internally. frameworks et al frequently have multiple strategies or you want to extend a framework primitive.
You overestimate knowledge retention.
At one point there is a new hire who instead of learning why and how stuff was done starts overdoing everything because "previous people were shitty developers".
You will have easier time hiring people with standard stack as well, no one wants to work on hodgepodge of code where some dev 2 years ago did something and left never to be found again. Developers don't want to invest in some magic stack because it will be easier for them to switch jobs if they keep doing Angular/React.
If someone would be claiming he was building web apps without frameworks I assume he was not working in teams or at least not in teams of big companies. Which would be a red flag for me.
At one point there is a new hire who instead of learning why and how stuff was done starts overdoing everything because "previous people were shitty developers".
You will have easier time hiring people with standard stack as well, no one wants to work on hodgepodge of code where some dev 2 years ago did something and left never to be found again. Developers don't want to invest in some magic stack because it will be easier for them to switch jobs if they keep doing Angular/React.
If someone would be claiming he was building web apps without frameworks I assume he was not working in teams or at least not in teams of big companies. Which would be a red flag for me.
i don’t think building your own framework is a good idea. react still has plenty of possible patterns to decide between even after making the decision to use it. a team should have decided upon ways to do stuff even inside of a framework/technology/language.
I've also written a framework while trying to not use a framework.
This is the “drop the mic” comment of the thread.
I guess I'm the rare oldie that don't agree that the frontend/html was/is better without modern js frameworks / spa apps.
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 :-)
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 :-)
> 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.
Have not had this experience. Our apps average about 40ms in typical traffic and 70ms under heavy load using SSR with react 16.8, and this is for a full render - in many cases we can serve static or interleaved cached components using ESI to SSR pages in ~20ms.
Have not had this experience. Our apps average about 40ms in typical traffic and 70ms under heavy load using SSR with react 16.8, and this is for a full render - in many cases we can serve static or interleaved cached components using ESI to SSR pages in ~20ms.
Thanks, in gonna have to do some digging :-)
Which brings me to the next topic: profiling nodejs apps... Any tips there?
Which brings me to the next topic: profiling nodejs apps... Any tips there?
Node has some basic but decent profiling tools built in, but where I work we use newrelic (enterprise performance monitoring solution) which gives us lots of fine detail about performance bottlenecks in our live systems.
fastify.io is supposed to be pretty fast. They do it by minimizing memory allocation. If you're not careful it's very easy to create tons of objects in javascript a common source of slowdowns.
There's about 4-5 very predictable comments already that boil down to: "you’ll end up building a framework"
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 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.
Most of these disadvantages are actually not a big deal. If your app is so simple that this is a reasonable choice, it's probably trivially easy to do with 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.
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.
You know what should be practically illegal? Foisting yet another web framework without a standardized reference implementation. A sort of rosetta stone or PLEAC for web frameworks.
- 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.
- 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.
*lose
"loose" rhymes with "goose" and is the opposite of tight.
"loose" rhymes with "goose" and is the opposite of tight.
Here's an example of an application written without using heavy frameworks:
https://github.com/wisercoder/eureka
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.
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.
Every time I decide to build a site, frameworks just get in my way and piss me off with their shortsighted design decisions.
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!
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's great but I'd argue you're not working a site that could benefit from the abstraction that a framework offers. Different tools for different jobs.
I'm investing in the F# safe stack. So far it's amazing how quickly I can build something. It's also amazing how clean and readable I can get the code. But I feel like there is a horrible mess of complexity just under the hood. If any of the amazing maintainers choose to stop my app has it's legs cut off.
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.
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.
We also use F# end to end (Fable + .NET). 3 years in I could not be happier.
Funny enough, just yesterday I did a spike into introducing one of the mentioned frameworks (SolidJS) into a no-framework legacy app, and I’m almost certain it’s the right move. The app is over a decade old, with a variety of different approaches and the tangled data flow that you’d probably expect of that… despite effectively having evolved an informal framework internally. Solid is a perfect fit for a couple reasons:
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.
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.
The framework argument is purely superficial and boils down to two camps: those who can write applications and those who need some (maybe a lot) help.
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.
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.
The web is the framework, documented at https://developer.mozilla.org/docs/Web
it's odd seeing comments related to a lack of browser lifecycle management, encapsulation, basically everything core to the notion of frameworks is provided by the platform these days (across all contemporary browsers) https://developer.mozilla.org/docs/Web/Web_Components/Using_...
The article links to writing your own router in less than 100 lines of javascript. This is based on outdated code supporting old browsers like IE11. For modern browsers, I was able to reduce it to less than 50.
I agree! Why would you use OTS tools in any DIY project? I'm going to make my own hammers, nails, drills etc - and anyone who does use store-bought tools probably doesn't know the first thing about building.
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.
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.
I code solely for the CLI. Python, C, C++, Rust. Recently I thought I'd learn some web programming, especially since it's no longer tied to writing JS. I gave up when it seemed there's seemingly not a single text that describes how to start simple!
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!
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!
Yeah, count me out. This is the world we used to live in when all we had was jQuery. It was miserable and no medium blog will ever convince me to pine for those days.
[deleted]
I write vanilla JS too, but I'm not this naive. JavaScript, HTML and CSS are a framework as well, and they have the same litany of issues the article uses to dismiss the usual overweight culprits and the transpiled alternatives. Presenting otherwise seems like a major category error.
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.
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.
I really wish people will stop putting equally between Rails/Django and React or Svelte.
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.
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.
[deleted]
When I'm writing web stuff "for fun", I try to avoid frameworks. It seems a lot more enjoyable.
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.
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.
People who write web apps without frameworks often end up creating their own. The reason is reuse of code. I'm working on my own web framework: https://nexusdev.tools/. This is intended mainly for Flutter at the moment, rendered server-side.
This is such a tired old topic on HN. Back in the day, compilers were evil. Real programmers used assembly. And then libraries were evil. And today, web frameworks were evil. Give it a rest.
Totally get it, huge not-a-fan of the endless JS framework race. _However._
- 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
- 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
It's funny (not really) that this was written on a platform that requires accepting the site's 'privacy policy, including cookie policy'
How many developers here have ever build a large front-end app without a framework like React and its clones, Vue or Angular?
I did back in 2016-17 when v1 web component support came to Chrome. Overall it's an approachable problem and takes quite a bit of time and attention to detail. The two significant problems I found are depth of familiarity with Web APIs and the nuance and attention to detail for complete problem solving. The time cost in doing this isn't trivial so it competes with delivering a product on short timelines--which means your MVP delivery might be slower and you might spend less time on design (I have a design background). The most significant secondary observation I've made is how entrenched the community is in these proprietary solutions, and the cost associated with their maintenance over time. The time cost of knowledge and productivity for React, Vue and Angular are similar so in the end the long life of native web api knowledge is the better investment. Since making the product (it automated antibody analysis for routine compatibility profiling in transplant medicine) Lit (LitElement, lit-html) became available and they're so lightweight I use these as often as the native web component mix. It's probably more accurate to say I use them equally because that's just how it works.
The problem of not using a framework, however, is that as the web app scales, you’ll end up needing to build a framework.
Picture writing this entire article not realizing you could have just used React / Nextjs
the benefits of vanilla implementation fix the problems that come with lack of training. like not understanding the low level api
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
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
He compared Nest, Next, and Nuxt … Nest.js has nothing to do with front end
[deleted]
A few months ago I started building a web extension in spare time. My first run, a working prototype built over a couple of nights, was module based, byo templating, plain CSS, with no build process. It worked well, was performant and had no strings attached. Vanilla all the way. I employed a bunch of CSS trickery to get effects and functionality that you might otherwise roll out with a line of frameworked JS. In my head the codebase had become a bit of a humble brag in itself.
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.
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.
[deleted]
Bishuadarsh(1)
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