Yes and no. What are those apps really doing that's fundamentally so much more complicated ? Obviously there's a lot more to their UI's and you'd need to be careful about doing full re-renders. I suspect anything that affects global page layout could become problematic. But I think it should be possible to predetermine the page layout (unless the viewport size changes, then you'd need to re-render everything, but that should be uncommon) and only re-render within div's of preset size.
> I looked at your code and you had to write your own render loop to accomplish this which would break down if you had interactive stuff that you were rendering out
You mean like generating forms/controls ?
I have some other code I'm working on that does that and also doesn't seem particularly hard. For example I'm working on a chrome extension with an options page that updates another page and the local storage as soon as a user changes an option setting.
They have more views, more data, more data that needs to be kept in sync across multiple views. You cannot rerender (and inject/replace) every time the underlying data changes. It works up to a point but once you cross that rubicon it because very painful. I don't know how better to say this or explain it. I write webapps professionally and for side-projects, maintaining any of them in vanilla js would be a non-starter. I have even tried that for "smaller" webapps that "don't need a build step", it doesn't work. SCSS is vastly superior to CSS, TS is superior to JS, and templates that support things like `v-for="item of items"` or `v-if="condition"` or `@click="doTheThing"` are superior to HTML templates with event handlers, loops spitting out html, and conditional rendering of blocks.
> You mean like generating forms/controls ?
Yes. Those things make this all more complicated. I've built exactly what you have in the past and at a certain point it falls down hard. There is a noticeable lag when you change data and go to re-render. If the user is focused on an input and you re-render they lose focus unless you make sure to reset the focus after the render. If you wanted to do something like "As the user types re-render an element to show what they typed" (think example/preview, or even something like putting the name you are typing into the UI as a header) it gets really gross really fast. So you might start having smaller render areas "I'll just re-render this 1 part" but that also gets complicated very quickly and at the end of the day you are just building a worse framework without the benefit of the community.
Now it's so much better/easier to use Vue, or react or even Svelte or the smaller similar stacks like alpine, htmx, etc that at least make state management easier than it ever was dealing with jQuery. the only thing jQuery had going for it was the ease of using selectors, honestly I think a jquery lite package that just has all the selector stuff would be nice, I sometimes forget all the document.getElementById stuff, but $('#id') is a much (imho) better syntax anyways. There probably already exists something like that - haven't looked but maybe I will later now that my interest is piqued.
The html syntax as a matter of taste is horrible, but that doesn't need a whole turing complete language to fix
OK, so how do the frameworks do it then ?
There are lighter-weight shadow dom frameworks out there (than Vue/React/Angular) so why would you want to write one yourself?
You can even avoid a shadow DOM or vDOM entirely and differentially render using the DOM itself:
https://github.com/WebReflection/domdiff
https://github.com/WebReflection/uhtml
The JS framework benchmark shows these two are among the top performers.
Mainly because I prefer working with my own code to working with other people's. Another advantage is reducing the amount of new information I have to learn (which with the whole vanilla HTML5 stack is already vast), but maybe I'm hopelessly out of date.
Thanks for the insights though, I wasn't aware they were doing all of that.
The problem here is - if you need to bring in other developers. Finding react/vue devs, or devs w/ htmx, alpinejs, etc - it's going to be super easy to onboard, a custom framework you built yourself - not so much. Maybe it's easy, maybe it isn't but you will have to train new devs who work on your stuff, where otherwise you could save time/money by not having to train on things, plus is your framework well tested using jest or other testing frameworks? There could be lots of bugs that some of the bigger more established frameworks have already worked out, and especially security issues.
Right now my favorite stack is laravel + alpinejs + livewire + filamentphp (admin dashboard) -- i can prottype in a week what used to take 3 months.
Writing my own, or better yet, staying away from JS altogether, has resulted in more stable, maintainable and profitable software.
Then this happened in multiple places. Or hackers didn't like how something worked so they came up with their own spin. I believe React came out of or is strongly influenced by FB, which makes sense - a Single Page App is the design and progressively loading more ads, ahh I mean content.
And here we are building client/server apps with a technology invented for document sharing.
There are 2 frameworks solving the "keep track of state" problem on the server and allowing for dynamic/reactive UI via web sockets instead of XHR: Ruby/Rails 7 and Elixir/Phoenix LiveView. They still use JS but you can limit it to client-side things and maintain state and validations on server.
It's funny to see how responses in this thread jump immediately to reactivity or "skills you can reuse across projects" but without making the case: why?
Facebook is pretty complicated already, once you factor in: * infinite scroll
* different sorting algorithms (top vs new, do they even still have that?)
* real-time commenting and post updates, with responses, reactions, edits, deletions
* dynamic image uploads, resizes, rotations, captions, etc.
* auth
* multi-device sync
* real-time customizable notifications
* real-time sharing
And then it gets even more complicated when you throw in other features like:
* ad management, posting, analytics, event tracking
* chat
* marketplace
* page management and all the permissions and delegations that involves
There's nothing really "static" about Facebook. And even it was designed as a mix of PHP and clientside JS, probably due to its history... if they started from scratch today, who knows what architecture they'd use, but probably not vanilla JS and HTML...
I think the "why" should be aimed more at vanilla, as in "why would you want to reinvent the wheel when there are so many battle-tested solutions to choose from, each made by a team hundreds of times more resourced than you"
Right tool for the job is hard to know before you've done a similar job, so I can relate to wanting to start with the most robust hammer.
I don't think it's a matter of React or not, but how much clientside interactivity & loading you want. If you want more than trivial interactivity -- immediately or in the future -- then a framework makes it a lot easier. Even something like jQuery existed because the DOM was so hard to work with, and thankfully ECMAScript has absorbed some of jQuery's features. React and node are doing something similar, forcing the standardization of ES6 Modules and Web Components, for example. They come up with ideas, implement them, see them adopted, and THEN the standards bodies absorb them.
Nothing stops you from using vanilla JS across your whole project if you want to; many devs just consider it an unnecessary pain that prioritizes purity of ideology over real-world concerns. I disagree that there aren't many moving parts in a typical web UI. Everything today from basic ecommerce to dashboards to maps to search to comments use clientside JS to enhance interactivity and AJAX loading. If you're building something simpler, there's probably no reason to code your own site anymore vs using Wordpress/Shopify/Bootstrap/whatever.
For the more complex cases that full-time devs actually get paid to build, using a framework and dealing with its performance/bundle size considerations is usually easier than using vanilla JS and dealing with its shortcomings, or you end up having to invent a lightweight framework yourself.
That's especially true when you have (or want) a team larger than one person. With a conventions-based framework, any new dev can be pretty quickly onboarded by observing your usage of common patterns in that framework. See a "useState" and "useContext" and they know its intent immediately. If you roll your own system in vanilla JS, without any standard patterns or naming conventions or directory hierarchies, even the most trivial change requires teaching or a deep investigation -- especially once you get into sharing state across more than one component/page.
I mean, this isn't even a hypothetical... the web evolved from basic DHTML-era JS to jQuery to Angular to React and its peers because more and more people saw a need for these frameworks. Nobody forced it on the web community, we just saw how they helped solve problems we had. Many jobs had me rewriting old PHP + JS apps into modern frameworks because, well, it just works better and is easier to maintain afterward.
Facebook itself is an example of that progression. If you remember Facebook when it first launched, it was pretty limited and much slower (in terms of interactivity). (It was also a lot cleaner and not so ad-ridden and toxic, sadly). I think they invented React out of real needs, not "how do we add more overkill to our app".
Sorry... I guess that's just a longwinded way of saying I disagree that there aren't moving parts in a typical web UI anymore, at least in the space of full-time jobs. Small local businesses and whatever, well, they can just use any of the DIY frameworks (Wix, SquareSpace, Square, etc.). But for those of us actually building SaaS or similar products, vanilla just doesn't cut it. Really the only time I can see vanilla JS paying off is simple one-off blogs or lone marketing pages, etc. And most paying dev jobs aren't doing such simple things anymore...
For example, my bank now has an online banking written in React. It's more buggy than the previous version (e.g., the back button does not work; the payment UI is quite chaotic), but they can boast that they use a modern technology. I doubt that a single page application provides any benefit for this task. Their competitor still uses HTML forms and they work perfectly.
This also reminds me of VB6 era. Back then, many programs were distributed with the runtime and/or an installer that was larger than the actual executable. The history repeats now with the bloated web frameworks.
For the last few projects I worked on, we first built super basic prototypes in different frameworks (React, Next, Vue, Svelte, Drupal, Wordpress, jQuery, Symfony, Angular back in the day, etc.) before choosing one to settle on, trying to balance concerns like DX, hireability, UX, hosting & infra costs, whatever.
If I were instead just forced to use a certain framework without doing due diligence, I'd be pretty annoyed too.
Undoubtedly there are people chasing the "new fancy", but also, by now React is considered pretty old and mature and (probably) kinda lame to anyone really wanting the newest edgy framework.
To your point, though, the SPA routing system (and how it interacts with browser history and URLs) is a pain indeed. React Router, in particular, handles it pretty terribly, IMO (it's much better in a system like Next).
html is on the representation layer, not a programming language. Modern web apps go much deeper and are using js as as a programming language for web programming that can go much deeper. As an extreme example, Quake Live implements an entire transfer protocol over TCP/IP. In the standard OSI model, there are a few layers between this and that. But there is a reason that purely representative documents still prefer PDF.
For a small demo like this vanilla JS might make sense but scaling this up does not work (once your rendered HTML reaches a certain size it's jarring when it re-renders, same deal if you have interactive UI that you are rendering out) and if you need to make 10x of these demo sites you are copy/pasting a bunch of code versus leveraging a framework that handles that stuff for you. Yes, frameworks raise your "floor" of code-size but they provide an excellent foundation to build on and skills you can reuse across projects instead of them all being one-off or having to copy/paste a bunch of code.