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.
> Normal javascript works fine these days for a sprinkling of front-end interactivity. jQuery is not even necessary anymore.
If you just need a sprinkling of front-end interactivity, you don't need a framework and you never needed it. If you're building a web application with lots of features, re-used components, complex data structures, etc., a framework helps you a lot. And the web today is full of complex web applications, since most of what used to be desktop applications 15 years ago are now web applications.
This is true. The question is whether it's necessary or good (for consumers, for businesses, for the software engineering profession, etc.).
The answer is subjective and lies within a spectrum, surely, but I tend toward the negative end of that spectrum. I don't believe the complexity in web applications is good (for anyone, except possibly browser makers, front-end developers and framework makers) and therefore it's not really necessary.
The browser today is mostly a terrible, inefficient, and limited functionality VM over the host OS, and that provides an inconsistent user experience across devices and even minor browser versions. What I've seen over the last 20 years of my lifetime has been an unfolding of a sort of tragedy of the commons in this context. We have a seeming endless supply of computational resources, "everyone" wants to exploit it in the most ruthless way possible, and it has lead to a deplorable state in the industry where bad practices and inefficiencies are not only tolerated but sought (for resume building, fast releases, whatever), and ultimately it results in terrible abuse/misuse of the resources we have.
We are re-implementing complex "excel apps" into web applications. Amount of money I have seen lost because people were using different versions of excel sheets that were not up to date is staggering.
Users expect full interactivity and instant calculations as they change values (just like in excel), doing it with "posting forms to back-end and recalculating" will not sell at all because it will be worse UX than excel. Having complex calculations over multiple fields require use of framework because making it with vanilla js is just pain with no MVVM and observables and two way bindings.
Then of course if you have web app you have one database all your employees are working on and all price items can be updated easily in some admin panel for every new customer.
> Amount of money I have seen lost because people were using different versions of excel sheets that were not up to date is staggering.
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.
Yes but as my experience shows process/structural problems are quite easily solved with software.
Then if someone has problem with process you tell them "it is software that requires it" and they comply.
Organizational problems are mostly problematic to translate to software and make projects die. Because if company is not organized, they won't have possibility to organize their requirements which will lead to problems.
> process/structural problems are quite easily solved with software.
My experience has been the opposite: the software is easy, but only if you already know what it needs to do. So you have to actually solve the problem first.
> Then if someone has problem with process you tell them "it is software that requires it" and they comply.
How incredibly user-hostile. If they have a legitimate concern, don't leave it unaddressed. If there's something important about the process they're missing, it's a mistake to use the current state of the software as an excuse.
I wonder how much money has been lost hiring software developers to implement something that Excel was handling fine. (snark snark, sorry, of course there are a lot of good reasons to move away from excel, but many projects fail or money might have been better spent elsewhere given how expensive it is to contract out for something new)
In my experience in being hired years ago for this kind of work, there is a significant cost to going “web app” but I’d also sell custom excel plugins. Usually these businesses were hitting the limits of excel’s capabilities when humans need to be involved (complex and hard to adjust formulas, copy/paste mistakes, etc). Most businesses don’t realize they can just have a custom excel plugin, and sometimes that is all they need. Sometimes a web app or custom software is the better solution.
interesting... whats that look like? I know of VB script that can manipulate tables... does that let you do custom GUIs too? Any API where a webform could interact with excel?
I might like to get into this field, solving business problems without building a whole app sounds great.
Just install the SDK when installing Visual Studio. I don’t see why you can’t have an embedded web view as long as you love Internet Explorer… it’s easier to just create a native UI though and call an API.
> Amount of money I have seen lost because people were using different versions of excel sheets that were not up to date is staggering.
Similar opportunity losses can be found through not keeping npm libraries up-to-date or through not doing full refactoring when there is a mainline change in a framework’s coding styles.
.NET, React, and Angular all suffer from that problem, to this day, in regular enterprise, and I’m sure Java does too.
People on different excel versions causing business errors is going to have an order of magnitude higher problem than libraries not being up to date. At least an old version of react will still work - and if it had an error, that error was acceptable at the time of shipping. Plus the developer is in charge of updating libraries, presumably with some forethought. A user updating their excel at their whim is uncontrollable and irreversible.
> People on different excel versions causing business errors is going to have an order of magnitude higher problem than libraries not being up to date.
Do you have a link to software engineering research that would corroborate that opinion?
Well not everyone is building websites on the web. Building an app for the web is not some horrible thing. Google docs, sheets, etc are all perfect examples of the kinds of apps suited to the web: ones that benefit from the ability to be accessed from anywhere on any device, and encourage collaboration.
We had this functionality before web apps were a thing. I'm not going to claim it was some golden era/glory days in a bug-free, seamless cross-device nirvana, but it's not like it was a wasteland, either. And for all the promise of cheaper, better apps that the webapp paradigm has been suggested to bring, we still pay a lot for armies of developers to write this stuff, and it's almost uniformly worse in both quality and feature completeness.
Yeah, this is the most damning thing. It’s clear that the web platform seems to resist being tamed with our current tooling. Adding more devs doesn’t fix it. As time goes on I become more skeptical that tooling can even fix it.
The impedance mismatch of a document viewer being made into a general app platform has yet to be truly overcome. All web apps try to eke out a living in the shadow of this.
That it seems to be everywhere these days is more a function of economics than anything else.
One established business and another startup I worked at absolutely thrived explicitly because we built web applications rather than native ones.
In the first case, we kept it narrowly tailored to two pages that absolutely needed that level of interactivity. In the second, requiring customers' employees to install an app on their phones would have been a non-starter during the sales process, and the lack of an app was a major selling point for others.
YMMV- oddly enough, both made use of the canvas element in critical parts (these were not simple CRUD websites).
That is my application that creates an OS GUI in the browser. Plenty of features with o framework.
* Code size (on the front-end) 2mb unminified.
* Load time in the browser (including state restoration) about 120ms.
* The first version took 15 days to write from scratch.
When people claim there MUST be a framework its clear they have no idea what they are talking about. It is clearly a case of Dunning-Kruger effect where they can compare their experience with frameworks on one hand... and they have nothing to compare it to, because its all they know.
> That being said, this project is not "0 framework". You built a framework from scratch to suit the application.
That depends on how you define framework. By this definition, any computer program has an inherent framework and the term loses it's meaning altogether.
This project does not include an opinionated methodology or ideology on how to design features. There is no template nor scaffolding to plan out commonly implemented features. There is no way to estimate work for new unique functionality. There is no framework here, afaict.
This is really nice! Congratulations! I am surprised that this isn't more famous.
One comment though: please have your video in Full HD format rather than 4k. Most people don't use 4K and so it is difficult to see your product demo.
And yes, I agree with you completely. There is really no need to use all of the fancy frameworks - plain vanilla js can give you quite a bit of power to build products like the one you made.
You are not the first to comment on the video resolution. I really must redo those.
Back in August the project was mostly working. Multi-file copy worked across the network and across the security model. At that time I did not have any encryption working (TLS, WSS). I am working on this now. Certificate management/deployment is something I am new to and its a bit more challenging in a fully decentralized application. There are three stages to this:
1) Certificate creation
2) Certificate installation into the OS trust store
3) Certificate exchange between agents
I can do a self-signed root server certificate with confidence. I would rather have a root certificate for user level of the security model and signed device certificates for increased security against device spoofing, but I am failing to get correct. I can make it work like a hammer in Windows, but its not correct and it won't work at all in Linux. I suspect certificate exchange will easily be part of the invitation process, but then I need to device a certificate challenge as an enforcement measure. This is a humbling experience reminding at every step that I don't really know what I am doing.
Also there was a catastrophic routing problem. You could perform all file operations except copy from one remote user/device to a different remote/user device. Everything is super simple when the network effect is two nodes (a request/destination and a source). When there is only two nodes you don't need any routing support. Even when the security model actually pushes the transmission to three modes, such that you are sending to a user's primary device and the transmission must relay to that remote user's secondary device the transmission is still simple as this is assume by the security model without additional work. When the transmission expands to three separate nodes (request, source, destination) you have to introduce routing. The routing is greatly complicated by the security model.
Now that I am working on routing file copy over the network is broken. Once I introduce encryption and routing I will ready the project for public beta and then resume work on audio/video calls.
No, you still don't need a web UI framework for rich front-end interactivity. That assumes however that your developers know how to write a callback function.
"You don't need a framework" assumes your developers will write code that operates with everyone else's code nicely, without accidently writing something that will be painful to remove in a year's time.
Frameworks generally enforce a pattern where things are quite well encapsulated, don't pollute global spaces, don't mess with prototypes, and manage callbacks well. Code written by one person, or a group of well-organised experts, also does that, but as soon as you have a less talented team, or a couple of juniors who aren't being overseen because the seniors are too busy, things creep in to the code that have the potential to blow up later. Frameworks help your team avoid those footguns (and introduce some different ones, but at least they're usually easier to manage).
Yes true! I once had the honour to work with a 'tech-lead' dev that rewrote a whole map application to AngularJS, which was the hype back then.
I remember him not being able to get a just slightly complicated chain of asynchronous stuff working in vanillaJS.
No problem, because he had AngularJS double binding now. No need to learn vanillaJS. Wicked stuff.
> 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.
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.
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.
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.
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".
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.
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.
> 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.
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.
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.
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.
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.
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.
>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...
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.
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.
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.
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.
> 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.
...not really, we're running high stake trading application (constellation of services) without framework and it works really well. Shallow/no-dependencies is great. We've been throwing complexity at it for 4 years+ and there is no fatigue, things are crafted to fit the purpose, it works, really, really well. I get personal satisfaction from removing code necessary to do the job.
> 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.
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.
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.
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.
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.
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.
I've seen projects like this in the past - either you have skilled people and use a strict CSP from the start, or the footguns of dynamiically crafting objects ultimately leads to a bunch of XSS that (probably) wouldn't have happened with mature frameworks
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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.
> 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.
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.
- 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 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!
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.
Throwing out frameworks is throwing out the baby with the bath water. Frameworks manage component lifecycle in a way the browser by itself doesn't.
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
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.
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.
> 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"?
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).
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.
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.
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.
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 :-)
> 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.
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.
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.
> 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.
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.
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.
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)?
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.
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.
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 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’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.
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]
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.
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?
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
206 comments
[ 1.2 ms ] story [ 314 ms ] thread"loose" rhymes with "goose" and is the opposite of tight.
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 think I'd argue that Phoenix LiveView is a frontend framework. Albeit a non-traditional one.
If you just need a sprinkling of front-end interactivity, you don't need a framework and you never needed it. If you're building a web application with lots of features, re-used components, complex data structures, etc., a framework helps you a lot. And the web today is full of complex web applications, since most of what used to be desktop applications 15 years ago are now web applications.
The answer is subjective and lies within a spectrum, surely, but I tend toward the negative end of that spectrum. I don't believe the complexity in web applications is good (for anyone, except possibly browser makers, front-end developers and framework makers) and therefore it's not really necessary.
The browser today is mostly a terrible, inefficient, and limited functionality VM over the host OS, and that provides an inconsistent user experience across devices and even minor browser versions. What I've seen over the last 20 years of my lifetime has been an unfolding of a sort of tragedy of the commons in this context. We have a seeming endless supply of computational resources, "everyone" wants to exploit it in the most ruthless way possible, and it has lead to a deplorable state in the industry where bad practices and inefficiencies are not only tolerated but sought (for resume building, fast releases, whatever), and ultimately it results in terrible abuse/misuse of the resources we have.
We are re-implementing complex "excel apps" into web applications. Amount of money I have seen lost because people were using different versions of excel sheets that were not up to date is staggering.
Users expect full interactivity and instant calculations as they change values (just like in excel), doing it with "posting forms to back-end and recalculating" will not sell at all because it will be worse UX than excel. Having complex calculations over multiple fields require use of framework because making it with vanilla js is just pain with no MVVM and observables and two way bindings.
Then of course if you have web app you have one database all your employees are working on and all price items can be updated easily in some admin panel for every new customer.
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.
Then if someone has problem with process you tell them "it is software that requires it" and they comply.
Organizational problems are mostly problematic to translate to software and make projects die. Because if company is not organized, they won't have possibility to organize their requirements which will lead to problems.
My experience has been the opposite: the software is easy, but only if you already know what it needs to do. So you have to actually solve the problem first.
> Then if someone has problem with process you tell them "it is software that requires it" and they comply.
How incredibly user-hostile. If they have a legitimate concern, don't leave it unaddressed. If there's something important about the process they're missing, it's a mistake to use the current state of the software as an excuse.
If I would write "I like fight sports" would you write "how incredibly hostile, don't punch people on the streets"?
It sounded to me like the suggestion was to appeal to the supposed inflexibility of software whenever a question about process is raised.
The software is entirely malleable. If the process can't change, explain why. But don't pretend that the software can't change.
I might like to get into this field, solving business problems without building a whole app sounds great.
Similar opportunity losses can be found through not keeping npm libraries up-to-date or through not doing full refactoring when there is a mainline change in a framework’s coding styles.
.NET, React, and Angular all suffer from that problem, to this day, in regular enterprise, and I’m sure Java does too.
Do you have a link to software engineering research that would corroborate that opinion?
The impedance mismatch of a document viewer being made into a general app platform has yet to be truly overcome. All web apps try to eke out a living in the shadow of this.
That it seems to be everywhere these days is more a function of economics than anything else.
In the first case, we kept it narrowly tailored to two pages that absolutely needed that level of interactivity. In the second, requiring customers' employees to install an app on their phones would have been a non-starter during the sales process, and the lack of an app was a major selling point for others.
YMMV- oddly enough, both made use of the canvas element in critical parts (these were not simple CRUD websites).
That is my application that creates an OS GUI in the browser. Plenty of features with o framework.
* Code size (on the front-end) 2mb unminified.
* Load time in the browser (including state restoration) about 120ms.
* The first version took 15 days to write from scratch.
When people claim there MUST be a framework its clear they have no idea what they are talking about. It is clearly a case of Dunning-Kruger effect where they can compare their experience with frameworks on one hand... and they have nothing to compare it to, because its all they know.
That being said, this project is not "0 framework". You built a framework from scratch to suit the application.
That depends on how you define framework. By this definition, any computer program has an inherent framework and the term loses it's meaning altogether.
This project does not include an opinionated methodology or ideology on how to design features. There is no template nor scaffolding to plan out commonly implemented features. There is no way to estimate work for new unique functionality. There is no framework here, afaict.
One comment though: please have your video in Full HD format rather than 4k. Most people don't use 4K and so it is difficult to see your product demo.
And yes, I agree with you completely. There is really no need to use all of the fancy frameworks - plain vanilla js can give you quite a bit of power to build products like the one you made.
Back in August the project was mostly working. Multi-file copy worked across the network and across the security model. At that time I did not have any encryption working (TLS, WSS). I am working on this now. Certificate management/deployment is something I am new to and its a bit more challenging in a fully decentralized application. There are three stages to this:
1) Certificate creation
2) Certificate installation into the OS trust store
3) Certificate exchange between agents
I can do a self-signed root server certificate with confidence. I would rather have a root certificate for user level of the security model and signed device certificates for increased security against device spoofing, but I am failing to get correct. I can make it work like a hammer in Windows, but its not correct and it won't work at all in Linux. I suspect certificate exchange will easily be part of the invitation process, but then I need to device a certificate challenge as an enforcement measure. This is a humbling experience reminding at every step that I don't really know what I am doing.
Also there was a catastrophic routing problem. You could perform all file operations except copy from one remote user/device to a different remote/user device. Everything is super simple when the network effect is two nodes (a request/destination and a source). When there is only two nodes you don't need any routing support. Even when the security model actually pushes the transmission to three modes, such that you are sending to a user's primary device and the transmission must relay to that remote user's secondary device the transmission is still simple as this is assume by the security model without additional work. When the transmission expands to three separate nodes (request, source, destination) you have to introduce routing. The routing is greatly complicated by the security model.
Now that I am working on routing file copy over the network is broken. Once I introduce encryption and routing I will ready the project for public beta and then resume work on audio/video calls.
Frameworks generally enforce a pattern where things are quite well encapsulated, don't pollute global spaces, don't mess with prototypes, and manage callbacks well. Code written by one person, or a group of well-organised experts, also does that, but as soon as you have a less talented team, or a couple of juniors who aren't being overseen because the seniors are too busy, things creep in to the code that have the potential to blow up later. Frameworks help your team avoid those footguns (and introduce some different ones, but at least they're usually easier to manage).
and that was a choice
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.
For large applications (or small ones that may grow large one day), you absolutely need a framework.
I have done a few projects using Knockout and Angular, and I've used Svelte a little too. My conclusion is that SPAs definitely have their place - but that place is in the minority, mostly for web apps with complex UI/UX.
In SSR (Server-Side Rendered) projects (typically ASP.NET Core for me nowadays, but I've used others too), things are just so much simpler, with fewer moving parts. A sprinkling of JavaScript is all that's needed, and even then a lot is reusable between projects. And now IE has finally died, jQuery is no longer needed, and browser support for ES6 is good, even writing JavaScript is less miserable than it used to be.
Of course SSR is simpler- request in, send / receive from a database, markup out. It isnt anything to do with SSR- your domain is simpler.
This echos my thinking whenever these framework/SSR/JavaScript debates come up. It's like everyone is talking past each other because there is no clarity around the complexity of what's being built.
So you're saying the domain is simpler while still satisfying the client's requirements? I think that's exactly the OP's point.
> My conclusion is that SPAs definitely have their place - but that place is in the minority, mostly for web apps with complex UI/UX.
Therefore, it follows that OP finds SSR is simpler, but only because OP only uses SSR for simple problems.
Users do not care about "immense developer productivity"
Implementing a form that autosubmits and updates an element takes very little 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.
No it sounds like the comments on every post on HN remotely related to JS.
> I've never bothered to learn Angular, React, NextJS, Svelte or any of the alphabet soup named frameworks
That makes your opinion definitionally uninformed. If you had bothered to learn any of them, you would see that they have many benefits. Nobody is saying that you need any of them, but they are very useful.
The single greatest advantage to using any of the frameworks, however, is that they provide a relatively definitive way of solving any of the problems that you will have to solve, building an SPA. Routing, caching, state management, reactivity, inputs...There is no way around solving these problems, so you're either going with what they've got, or reinventing the wheel. But by reinventing the wheel, you're probably going to do a worse job than the team that has spent years solving these problems, and more importantly, you're losing access to a definitive way of doing things that you (and others) can refer to.
And that's the real kicker, is working with others. I worked as a contractor for years, and I can tell you the ease of jumping on a project using a front end framework vs a home baked JQuery or vanilla solution was practically immeasurably vast. Even jumping on a project using a framework I'd never heard of, but still had documentation and an online community, would have me up and running within a day or two at most.
Now, saying that, there is something to be said for separating UI from the backend. Yes, it adds ( a great deal of) complexity compared to server-side applications, but the reactive programming model is quite powerful, and useful even if you could build the application entirely on the server.
And obviously if you do need an SPA (e.g. wrapping WebView for iOS/Android) then you don't have a choice, or if you do you'll be reinventing the wheel, poorly.
There are frameworks that don't deliver an SPA - Next, Nuxt, Remix, etc. They also do a lot of work to remove as much frontend JS as they can, and more effort is going in to that delivery architecture at the moment. The idea is that devs write React or Vue based pages, and the framework figures out what the page actually needs and delivers only that code to the user. Routing is done on the server. They work very well.
jQuery is very easy to understand and edit in notepad. It doesn't require getting the right npm version / maintaining dependencies of specific package versions that may be depreciated.
Routing is better handled in the backend.
Backend frameworks have been around longer. By treating them as an api only you end up reinventing the wheel. Caching, state management, reactivity have been handled in the backend for awhile.
I 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.
Take for example excel and if you change value in one cell you get all calculations in sheet updated automatically.
Implement something like that without a framework and only plain js with dozens of fields having dependencies on each other, good luck :)
Implement something like that with cute "recalculate" button on the bottom of 3 screen scroll and no one will use your solution.
I just implemented a complete spreadsheet solution inspired by Airtable (sticky header and columns, column resizing, virtual scrolling, row selection, cell selection, cell editing, a few cell types) in approximately 500 lines of vanilla JS. No virtual DOM, no reactive data library, no framework. Just direct DOM manipulations. It performs great and is pretty easy to understand and extend.
For now, the reactive "field dependency" problem is just solved by re-rendering the entire spreadsheet when a cell is updated (really just re-rendering the visible rows, because of virtual scrolling). The state management is just not that complicated.
I suggest this sort of project as an exercise if you've found yourself engrossed by this or that front-end framework. My go-to front-end frameworks for the past few years have been Mithril.js and Vue, but they really would have been a major hindrance in this case. I can't imagine Svelte or Solid.js or whatever being any better...
Re implementing custom app with its business rules that was buried in excel sheet is a different thing. People don't want to buy excel in a browser, because they can have that already, they want their custom logic and in a way it works in excel.
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...
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.
Sure, if you choose to buy in to a backend framework.
I'm not knocking Phoenix, but it's a tradeoff. I'd rather be able to write the backend without a framework and use the framework where I want to spend the least amount of time figuring things out, which is usually on the frontend/GUI. But everyone is different.
I feel the same way about both front-end and back-end frameworks - or at least the sorts of things that call themselves frameworks. Struts was kind of useful in its time, but in the end didn’t save you much effort as code. Usually when people talk about Java server side frameworks these days, they mean Spring, which is worse than useless, because it actively makes development harder.
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
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.
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.
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.
What did we end up with? A custom build framework.
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.)
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.
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.
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!
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 is a de-jure library, but a de-facto framework.
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.
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.
- 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
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
Like: I have a compiler that can target wasm32-unknown-unknown, how can I write a hello world in a language that said compiler compiles? Instead I'm presented with a barrage of frameworks and magical "bundlers". Help!
The 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
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.
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'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 :)
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.
Yes. But it's a baby snake.
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"?
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).
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.
- 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.
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.
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.
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 :-)
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.
Which brings me to the next topic: profiling nodejs apps... Any tips there?
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.
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.
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.
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.
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.
[1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
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.
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] hackerfromthefu ↗ I wish this comment was pinned to the top of every Javascript discussion thread! ericsilly ↗ Great write up!
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
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