The key reason web frameworks dominate these days is that it's very hard to keep the UI in sync with state.

That's it - that's the problem they solve. People started writing vanilla HTML/CSS/JS and struggling to make "reactivity" (hence React) work well when web applications got complex with a lot of state to manage. So we started building frameworks on frameworks and abstractions on abstractions and ended up where we are today.

It's gone a bit far but the overall purpose is a valid one.

(From someone who has used React professionally but uses vanilla HTML/CSS/JS for his personal website)

>The key reason web frameworks dominate these days is that it's very hard to keep the UI in sync with state.

This isn't wrong, but going one level down, this is how it bites you:

- The imperative DOM api just suuuucks. Please try it for yourself to see. Even if you're writing a very limited bit of reactivity in your app, you will be forced to invent your own declarative framework very soon.

- Very hard to make reusable components (at least before webcomponents, which I haven't used personally)

If you want to stay close to vanilla, I recommend one of the following solutions:

1) https://htmx.org/ 2) https://github.com/hyperhype/hyperscript 3) https://github.com/vuejs/petite-vue

Working on a project right now with htmx, hyperscript, tailwindcss (all new to me) and it's impressive how low the cognitive load is in a lot of cases.

htmx and tailwindcss are great but hyperscript looks crazy evil. I hate mixing html and js though, even jsx rubs me wrong.

This looks like pug/slim and other templating to remove xml from pages but instead of just something like

    body
      p
        |
          This is a test of the text block.

you get something like:

    var h = require('hyperscript')
     h('p', "This is a test of the text block")

and I want to know why would you want the entire page in JS objects?

personally I like the way htmx, vue, alpinejs do things with basically embedding actions/events on the existing xml structures. It's more an abstraction over existing html, than totally redoing or replacing html. That seems like a case of 'we knew we could do it, but never stopped to ask ourselves if we should' ...

Turbolinks + stimulusjs is also another great stack for mini-frontend frameworks. Also super fast.. turbolinks can go well w/ anything though including htmx or alpinejs, but there's a lot of tutorials on stimulus+turbolinks.

Hyperscript (https://github.com/hyperhype/hyperscript) is actually quite nice when you get used to it, and I actually prefer it over JSX. Pair it with something like microh[0], and it gets even better.

[0] https://github.com/fuzetsu/microh

When I first saw hyperscript in the HTMX docs (they're made by the same person), it also struck me as an unholy abomination. But in practice, it's been pretty nifty. It provides a concise way to perform common actions that adheres to the idea of locality of behavior that HTMX and Tailwind both offer as well. I still think I might come to regret it, but it doesn't seem like it would be hard to rip it out and replace it with plain JS. For example, I'm mostly using it to do stuff like:

on click toggle .hidden on .modal

I believe you are talking about this hyperscript: https://hyperscript.org/

Whereas the parent post is talking about: https://github.com/hyperhype/hyperscript

Unfortunately, the creator of https://hyperscript.org/ hijacked the name even when the term "hyperscript" is still used to refer to dominictarr's project and the `h('p', 'hello world') API of declaring templates in JavaScript (as seen in React, Preact, Mithril, etc.).

I'm still learning modern web development but here's a simple demo app that I wrote using only plan vanilla HTML/CSS/JS: https://tgflynn.github.io/AlgoVis/ (github link: https://github.com/tgflynn/AlgoVis).

The fact that this works, didn't take long to write (though I'm very much still learning this stuff) and is very fast leads me to question your statement that "The imperative DOM api just sucks".

Ok, but surely you see the difference between this very simple/straightforward "demo app" and a real webapp? Something like Zillow, Facebook, Doordash, Spotify, etc. 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 (I know, I've done this before). As it stands your interactions ("New Data", "Run", "Step", "Reset") are completely separate from the rendered data. Once you start combining those it gets harder. It's still possible but you are reinventing the wheel.

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.

> Ok, but surely you see the difference between this very simple/straightforward "demo app" and a real webapp? Something like Zillow, Facebook, Doordash, Spotify, etc.

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.

> Yes and no. What are those apps really doing that's fundamentally so much more complicated ?

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.

I remember trying to do this with jQuery and localstorage, and was amazed it work, but so frustrated the many times it broke or caused issues. Built an entire shopping cart w/ a team in jQuery and localStorage as the store with some handlebar templates. In retrospect it was horrible code. This was in 2015 though, so react/vue were less wide spread and I was much more junior.

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.

I never used jquery since I never got very seriously into web development until recently but document.querySelector() seems to be about a nice a function for querying DOM elements as you could want.

> items"` or `v-if="condition"` or `@click="doTheThing"` are superior to HTML templates

The html syntax as a matter of taste is horrible, but that doesn't need a whole turing complete language to fix

> You cannot rerender (and inject/replace) every time the underlying data changes.

OK, so how do the frameworks do it then ?

They do pathing/differential rendering. They don't all do it the same way but one example is they build the DOM "in memory", render it out, and then when they re-render they compare they old/new html and inject only the diff. They also have built in things to make sure you don't lose focus when you add an attribute to the input (or change it in some way).

There are lighter-weight shadow dom frameworks out there (than Vue/React/Angular) so why would you want to write one yourself?

> 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.

> There are lighter-weight shadow dom frameworks out there (than Vue/React/Angular) so why would you want to write one yourself?

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.

> 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.

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.

> I prefer working with my own code... Every programmer prefers to work with their own code. This is the biggest dilemma, it boils down to a lot of "make/buy" decisions. Rule of thumb after 20+ years of experience : do not reinvent frameworks. The framework you are thinking of already exists, and, even when not perfect, solves a lot of problems you hadn't even thought of.

I disagree vehemently. Every time I reach for a JS framework, my fans spin and I get concerned that my notebook is going to take off to the moon.

Writing my own, or better yet, staying away from JS altogether, has resulted in more stable, maintainable and profitable software.

Then you exist as a very skilled and rare software developer. Or what's more likely is that your lens of software development and software maintenance is quite different to the majority of web developers.

Think about it, are you the one that maintains said code? If so, can you really call that maintainable (as in, reusable, expandable by others while you are on vacation)? If not, you are a very skilled framework maker. Then other people are using your framework and hence, not reinventing the wheel, which is my point.

This is a good start:

https://reactjs.org/docs/faq-internals.html

https://reactjs.org/docs/reconciliation.html

Thanks.

I suspect some of the JS frameworks started with a set of JS functions, etc. to do things dynamically on a page. And it grew. And then someone comes by and says "hey we're building a new app, mind if we use that?". And it was cloned and morphed. And it grew. Maybe that repeated a bit, and then someone created a framework of generic tools.

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.

Why what?

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"

Why go vanilla? Because it's less complex, often smaller over the wire, nearly SEO ready, etc. Of course if you can anticipate needing a lot of interactivity which cannot wait for separate page loads then consider the FE frameworks. Maybe even go hybrid if only one or two pages need app-like components.

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.

The thing is, most web sites are not Facebook. React is usually an overkill; you don't have so many moving parts in a typical web UI.

Well, Facebook was the example provided, and I was just saying that there's a lot of nuance to what (at first) might just look like a static list of posts but really isn't.

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...

From my experience as a developer, they rewrite frontends in React because it's cool or because their boss said them to do so. Nobody asks if React is really needed in this project and what would be the best solution.

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.

That sucks. I'm sorry you had that experience =/

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).

This is still besides the point entirely. Somebody looking to learn web programming is not going to start running a bank.

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.

> simple demo app

I don't think you can judge if the DOM api sucks if you are using a "simple demo app" as your baseline, though.

All software is built from simple primitives. If the fundamentals are solid scaling up should be just a matter of managing complexity in your own code. I'm aware that performance problems that I don't have direct control over could occur at some point, but would that be the fault of the DOM API itself ?

If the DOM api is not expressive enough, you end up having to wrap it with your own custom abstractions. At that point, is it not better to use a battle-proven abstraction?

Only if they're clearly better than the abstractions I would come up with. Which is rarely the case, especially if most of these frameworks were developed in an ad hoc manner without deep consideration of what the fundamental problems are that need solving, and even more so if they had to incorporate workarounds for browser issues that are no longer very relevant in 2022.

sounds like someone has a bad case of not-invented-here

Sounds like someone had a bad case of framework chasing and hype driven development. I support the original poster as developing your own is always better than reusing, no exceptions.

I've worked on codebases like your's before, where in-house 'we can do it better' reigned. In my experience it never was better, and when the grand wizard holding it all together got hit by a bus, everyone was blocked.

Frameworks are a common understanding that people can plug and play into. And yes, that's a critical part of maintainable code, the ability for a person to quickly get up to speed and fix things.

Do you work alone though? Do all people in your team agree with your technical decisions? If you left the team, would someone be able to maintain and improve your hand-rolled framework?

This from someone who can’t comprehend why government mandated hard hat safety standards might be good. It all fits.

so, yes, you are not wrong. the issue here is the differential of 'managing complexity' with regards to time.

as the functionality of the app progresses beyond a certain complexity (admittedly, this is nebulously defined), increasing changes to complexity require more time to effect.

beyond a certain point of functionality, the need for a a framework to manage these things becomes emergent. at that point, a single coder can resume making more complex changes with the aide of the framework, than she could do without it.

you're not wrong, you just are not considering a big enough scope over which to evaluate what the manual manipulation of software primitives is worth.

in the end, frameworks aide results beyond the ability of a single coder to implement on their own.

I'm always amused at people who spend like a month learning something new and all of a sudden have opinions on the entire state of software development.

They are of course the valid opinions of a neophyte but don't expect anyone to take you seriously.

Being a neophyte at HTML5 web development doesn't make me a neophyte at software development, I've been doing that for well over 20 years.

I'm always amused at people who make assumptions about who they're talking to online.

Well done! Much better than any framework already. A few suggestions!

Look how slow the text renders when you hit reload.

The content of the <code id="code-container"></code> is not going to change. Just put it inline:

   <code id="code-container">
   <li>async function n2sort( data, view )  {</li>
   <li>    const n = data.length;</li>
   <li>    for( let i = 0; i &lt; n; ++i )  {</li>
   <li>        for( let j = 0; j &lt; n; ++j )  {</li>
   <li>            if( data[i] &lt; data[j] )  {</li>
   <li>                swap( data, i, j );</li>
   <li>            }</li><li>        }</li>
   <li>        await view.addRow( data, `Step ${i + 1}` );</li>
   <li>    }</li>
   <li>}</li>
   </code>

(As a joke you could put the actual <script> tag there and style it like script{white-space:pre;display:block} )

The external <link rel="stylesheet" type="text/css" href="style.css"> can also be pasted inline between <style></style> tags.

Same for the script at the end of the page, just put the content between <script></script> tags.

All the way at the top a document type would be useful <!DOCTYPE html>

If you want the steps could be replaced by rendering the entire table and hide each line with css. Pressing step only has to reveal the next line.

I personally consider it a good habit to have the buttons update the location.search part of the url then listen for url changes with window.addEventListener('locationchange', function) and modify the page accordingly. It's not particularly useful for this app but its nice to have an url that represents the state of the application.

https://tgflynn.github.io/AlgoVis/?step=2&array=1-2-3-4-5

I have a suspicion that your entire comment was intended as some kind of joke, but I'll address your points as if you are being serious.

> Much better than any framework already.

I doubt that. If my first attempt at a dynamic web app in like 10 years is better than the current frameworks than the state of web development must be much worse than I realized.

> Look how slow the text renders when you hit reload.

You're right, there is a noticeable rendering glitch that I hadn't noticed before, thanks. Maybe this is already an early indication of the limitations of the approach I used here, or at least one of the trade-offs.

> The content of the <code id="code-container"></code> is not going to change. Just put it inline:

One of my goals with this demo was to display the exact same code in the blurb on the left as was being run on the right. Another goal was to minimize the amount of change needed to the basic algorithm implementation to update the display. I was able to get it down to one extra line, but maybe there's a way to avoid that entirely.

> All the way at the top a document type would be useful <!DOCTYPE html>

It's there, you must have missed it (in chrome "view page source" colors that line with very low contrast).

Your other comments about inlining go against most advice I've seen on best practices (with which I happen to agree). For one thing it's much nicer to edit files that are written in one language than in 2 or 3.

> I personally consider it a good habit to have the buttons update the location.search part of the url

Interesting, I'll have to give that one some thought.

> > Much better than any framework already.

> I doubt that. If my first attempt at a dynamic web app in like 10 years is better than the current frameworks than the state of web development must be much worse than I realized.

The state of webdev is indeed terrible, there is progress being made but its hard to tell where and if it is real progress. There was a fun article the other day onhere that explained why React became popular and how that no longer necessarily applies but the popularity persists because it is well known. I cant objectively tell how true that is. What is the better stuff is like... peoples opinion? Frameworks are there because html/css and js have their shortcomings (what those are is more opinions) but I much prefer working with those over hiding them. An abstraction on top of something bad doesn't make it great.

People can glue code fantastic things really fast nowadays but when it stops working it takes a wizard to fix things. With many components of your thing getting updated it is easier for conflicts to arise.

Perhaps the question is: How much performance and stability can you exchange for fast development? Guessing how much performance you are going to lose is not easy to guess, it might be completely irrelevant for the use case, it might be horrific. Will you be around to fix things in the future? Will others have to work on your code? A reasonably sane standard way of doing something is going to be a huge advantage there.

> Your other comments about inlining go against most advice I've seen on best practices (with which I happen to agree). For one thing it's much nicer to edit files that are written in one language than in 2 or 3.

Nah, its all the same. You are gaining nothing. You could ask : how much editing files are you going to do vs how many times are people going to load the page? A http request takes time, the browser doesn't know it has to load a css file and 2 scripts until it receives and parses the html, a new request is made which takes time again. Depending where the user and the server are located a request may take a long time.

I find it quite silly how we need a gaming pc to parse websites nowadays. The user is also in some remote corner of some remote country on ancient hardware.

You should absolutely have external css and js if the user is likely to browse multiple pages. Inline they would have to load it for every page view.

People may also block external js and css files. Add blockers may get rid of your code section and if your app is many files spread out over many folders it is much more likely to break than a single file that contains everything.

The single file will either load and work or the server is not working.

In an ideal world we could have things inline on the front page and tie it to an url so that it can be cached and used on other pages.

I would never accept poor code organization as a trade-off for performance. If using linked resources becomes a performance issue I would probably use a server side bundler, or write my own.

HTMX is incredible, I adore it. Typically, my stack for a web app is a Golang webserver using Fiber[0], HTMX, SCSS, my own (experimental) templating engine [1] and SQLite. It's a sufficiently hype-free stack, in my opinion, and one that's been fairly well battle tested (bar the templates) and is pretty simple. It's a joy to use!

[0]: https://github.com/gofiber/fiber

[1]: https://github.com/codemicro/go-neon

Goneon looks interesting.

Is it trying to provide compatibility with quick templates etc or aim to reach jinja level features parity ?

The aim is to be just as functionally similar to QuickTemplate, though not compatible.

I like the idea of QuickTemplate a lot but the I find it lacking and annoying to use in various ways. For example, I find its syntax is annoying to write, I don't like having to re-declare the types of my variables whenever I use them and it's error reporting is near useless.

Currently, Neon is just barely at MVP. I'm dogfooding it and adding to it as I find I need things.

Try to release boiler plate template that uses these tech, if possible and convenient.

Good idea! I'll remember that for when Neon is suitable for people other than myself to use, thanks :)

We developed El to be as minimal as possible, while still solving the problem of keeping state and interface in sync:

https://github.com/frameable/el

It's just ~150 lines / 2kb, and leverages existing browser functionality to accomplish most of the hard parts. Has observability, reactive templates, scoped CSS, no need for a build process, etc.

I have been reading into it for some time now, since I do not want to dive into a big framework with a huge learning curve for a side project that I have.

I just feel afraid to run into a problem that has already been solved in a big framework and get stuck.

Interesting - looks pretty similar to Framework7 components

https://framework7.io/docs/router-component

This looks very interesting, I'll give it a go

If you like hyperscript, it's worth checking out mithril.

https://mithril.js.org

What about adamant? I heard that is the next level above mithril.

This sequence of comments is the JS ecosystem in a nutshell.

Hear about something new, then immediately hear about its multiple successors/replacements.

Lol, to prove you're point even harder, your comment is not even the at the end of the list of successors/replacements.

Mithril uses hyperscript as its foundation, it builds upon it as opposed to replacing/succeeding it :)

Check it out, it's the kind of framework you pick and stick with for 20+ years. Zero bullshit compared to its peers.

And in a month or two the new hotness’ll be something else built on top of Mithril, or something “like Mithril but a bit different”.

Good frameworks are good, and I love a good hobby project in some new hotness, but ecosystems, developer tooling, backward compatibility guarantees, large corporate backing, developer conferences, and community are what makes frameworks adoptable are what makes them stick.

Mithril has been around for 7 years. How old does it need to be before it's not "the new hotness"? Just because you haven't heard of something doesn't mean it's new, and it would behoove you to not immediately dismiss things that are new to you as things that are new in general.

Your heuristic that a large ecosystem is what makes a framework good precludes you from ever again touching any new project. It's a short-sighted approach.

At some point, you have to grow up as a developer and try to understand the real world problems that modern declarative web frameworks have solved. I stated that mithril will be my tool of choice for hopefully 20+ years, so your framing this as me getting lost in the new hotness doesn't even hold up. This is about real tools, which are useful today and tomorrow, and which have slow API churn to facilitate longevity. It's just a bonus that mithril is also faster and far more terse than React and friends.

Nah. orichalcum.js is the hot new thing. It's a fork of adamant with support for monads, generics, and native blockchain integration.

For anyone wondering what are these new JS frameworks:

- mithril.js is an actual web framework. I’ve not tried it myself. - the next comment referenced adamant as being better. There is an MMORPG called RuneScape in which weapons and armour can be smithed of various metals, and treats adamant as 1 tier better than mithril. - similarly orichalcum is a couple of tiers above mithril.

Don't give anyone any ideas!

https://unpoly.com/ is a good choice - it's description is true:

"The unobtrusive JavaScript framework for server-side web applications Unpoly enables fast and flexible frontends for server-rendered HTML views. It has no dependencies and plays nice with existing code."

On top of these options, with modern browsers, it's quite easy to make reactive components in plain vanilla ( https://benoitessiambre.com/vanilla.html ). I find this approach very usable for smaller simpler projects where you don't need a full framework.

Vue is right in the sweet spot for me doing solo stuff. Get all the reactive stuff with minimal additional complexity.

I was about to use Vue for a new project but got pulled by the siren call of svelte. The other popular frameworks look ugly as hell by comparison.

How is svelte? Heard someone give a talk about it a few years back, sounded like it was pared down/elegant. I wrote a project in Angular back when I was using it in my day job and shudder now looking back at the code. It's so bloated by default!

It appears as just another framework but once you dig in and start using it the elegance is ridiculous and addicting.

wow thanks for this, I'm fullstack with tons of vue exp but have been 90% backend for the past 6 months or had my head in a hole or something -- this is the first i've heard of petite-vue. Looks pretty cool, maybe somewhat akin to alpinejs, which I have been using more lately also. I'd also put that on the list as it's a nice framework with a bit less footprint than vue/react etc.

I guess the original issue is that HTML/CSS is desgined for creating documents and standard forms not apps.

I'll throw in https://caldom.org/

I sometimes use an even closer to vanilla option based on just the Lit templating engine: https://benoitessiambre.com/vanilla.html

Or https://github.com/WebReflection/uhtml

> keep the UI in sync with state

This is absolutely true, however there are some newer tools that are appearing that make this much easer with vanilla html - htmx, hyperscript, alpine.js for example (links below).

These newer tools are all made possible due to the “new”(ish) MutationObserver api, it allows you to intercept new dom elements being placed into the document. These libraries let you simple decorate your “real” html with extra attributes enabling easer client side state management. No build step required.

My hope is that a combination of these type of tools, js modules and web components will result in dropping all js build tools. With http2/3 we don’t really need bundling. In many ways it the bundling and transpiling process that has contributed the most to the friction with JS development.

My other observation would be that as js frameworks have evolved they have become more “enterprise” ready, adding tooling (complex central state management, strict typing) to make working in large teams on very large codebases easer. Much of this isn’t really necessary for the majority of we development.

https://htmx.org/

https://hyperscript.org/

https://alpinejs.dev/

To that list I'd add Hotwire (especially Stimulus: https://stimulus.hotwired.dev). I use with Rails, but it's framework/backend agnostic.

It's crazy that we posted almost the exact same thing at the same time: https://news.ycombinator.com/item?id=32781674

Both your comments are very helpful, so I’m glad you did :)

But if you’re going to use a framework like HTMX and the others you mentioned, why not just use React? Vanilla JS is great because it’s universally available, if you’re choosing to drop that advantage I would just go with React.

With react you need a build / transpile stage and have to handle webpack / babel / whatever. You can just use plain tags in html to use htmx and alpine, you just have to include them

because `react-dom` is bloat [minified]

- hyperscript@2.0.2 [3.7 kB]

- htmx.org@1.8.0 [36.5 kB]

- alpinejs@3.10.3 [38.1 kB]

- react-dom@18.2.0 [130.5 kB]

Right now my whole (everything js) really complex application is 150 kB minified. Imagine adding React .. urghh unreasonable.

Just try Preact

Preact is good except it tries to be in React league. The author has greater knowledge, enough to left React behind.

I hope these succeed, but we still need transpilation/bundling:

- TypeScript needs transpilation and it’s very popular

- Bundling is still beneficial with H2/H3, if only so that compression can work well

Please add https://unpoly.com/ to your list.

Thanks for these links! They look like the next logical step for HTML/CSS developers instead of React (or similar) which are overkill.

I'm in web development since 2000s, at that time there was pretty good web authoring tools like Macromedia Dreamweaver. Everything got complicated because a fundamental limitation of the HTML document model: having dynamic pages. Imagine creating and maintaining a catalog by having a single .html file for each item in the catalog.

I believe with Dreamweaver MX you could have sort of a template and generate the static pages.

I think this solution wasn't massively adopted because you had to rely on Macromedia server side ( Cold Fusion ).

That was when PHP and ASP entered the scene allowing you to have dynamic pages in a linux or windows server.

At that time, javascript implementations and rendering engines had massive discrepancies, Internet Explorer, Mozilla .., and to solve that emerge the first (that I recall) massively adopted javascript libraries, jQuery & Motools.

Then Ajax[1] became popular because it made posible to interact with the server without refreshing the page, and that's when managing state became a problem in the browser as SPA started to become more and more complex.

It's amusing seeing how we went full circle when SPAs have gotten so heavy and slow that now static page generation it's sold as a killer feature in Nextjs.

When we could do this in 99's version of Dreamweaver with a nice UI. Maybe it's not a fair comparison, but you get my point, >20 years and see where we are.

$DIVINITY, how I miss Dreamweaver and Fireworks. Dreamweaver was good, but the way Fireworks let you edit images in both bitmap and vector mode and saved it all as extended info in PNG files you were always able to view everywhere…

So sad that Adobe killed them off. I would still be using Fireworks today if I could.

I am still using Fireworks, it's the main reason I'm hanging back on Mac OS Mojave on my personal machine (Catalina drops support along w/ all the 32 bit apps). And I'm waffling between getting a hold of the Windows version and using that indefinitely or just learning something else that has raster / vector combined.

Fireworks lives on but Adobe has like 90 products and I forget which one it became

Well explained, thank you.

When did "data binding" become "reactivity" (why the need to create a whole new lexicon for the same ol' thing)? A lot of this confusion (as per the OP) could have simply been explained away by saying we needed frameworks to bind HTML (visual components) to data. Two-way binding existed in many desktop frameworks before SPAs were even thought of.

React is intentionally not two-way binding.

And yet, after all these years, Svelte is a response precisely to that design philosophy: taking us back to accepting that two-way binding is nothing to be scared of. The endless loop of thinking in the JS community is expensive.

Re >> From someone who has used React professionally but uses vanilla HTML/CSS/JS for his personal website"

What a refreshing perspective. My personal site is also vanilla HTML/CSS/JS on a self hosted server. I constantly catch flak from all of my software engineering friends for it too, and I'm a little burned out on it.

Edit: I'm a bit burned out on the flak and defending my position; not burned out on the approach :-)

Please don't burn out for this. Vanilla HTML/CSS/JS is just a very right way of building a website. I don't know how we ended up having to even debate about this.

Don't worry, just enjoy the simplicity, the zen and the lightness of this.

(from a professional web developer, if it even matters - but the web, especially JS, was not targeted at professional web developers, which is the reason why JS is so "forgiving" - or was intended as such, but that failed miserably if you ask me)

Yes. Some things should be designed as simple as possible so they can last.

https://jeffhuang.com/designed_to_last

I've updated my comment to reflect that I'm burned out on catching the flak, but not the work itself. Personally, I love basking in the zen of the simplicity! I used to be a professional web developer in a former life, but these days I'm more medical-device and embedded focused. I moved out of the web space around the time that AngularJS was becoming the hot-new-thing, for better or worse.

I got burned out by all the frameworks. It's one of the main reasons I left web development. I love the web, and I still do personal web projects, even though I don't do them for work anymore. I just exclusively use vanilla JS, and make sure the scope doesn't get big enough that I need to construct a giant mech suit of frameworks and libraries and climb into it every time I want to make an app!

For a website the vanilla tools are exactly right—it's what they were designed for and they still do a really good job at it.

The frameworks are only really worth their weight if you have a web app. I'd only consider a web framework if there's going to be >2x as much JS as markup.

I'm amazed at how many developers need ridiculous complexity to feel like they've accomplished something. I feel that too many people are focused on building resume keywords than solving problems.

If you can solve it in 20 lines of CSS / JS then do it.

You don't get hired for, say, a role that requires Svelte / React expertise by pointing out "I did it in vanilla JS!" - so you are correct, industry sets the rules and your CV if you want a job from them, needs to reflect this.

There are also software engineering (not programming) reasons, mostly because they set standards for stuff like state management, for why they're useful - helps with future maintenance, documentation etc. when you don't have to interpret a custom self-made framework and teach it to hires.

Yep my thoughts as well. It’s great to use vanilla js for a personal website (I do) but if one is seeking employment knowing a popular framework (both backend and front end) is also critical.

It also seems worthwhile from an Org standpoint because then they can target “react” or “vue” developers in job postings who can presumably hit the ground running productivity wise.

(This is basically just echoing everything parent comment was saying)

Poll

- Job market sucks

- Industry sucks

- JS framework sucks

- Developer sucks

Those are some strange friends. Who cares what you use on your own website?

A good engineer knows which tools are right for the job.

Wow, what an interesting response. If someone told me they were trying different approaches to similar problems on their own time I'd say "Sounds like you'll probably learn something someone using the same approaches or not solving the problems on their own time wouldn't".

Those engineers sound like the kind I don't like to work with. Giving you gaff for wanting to tinker on your own time is downright haughty.

I remember reading a similar HN thread in the past where someone didn’t understand how you build a html form without React, and that it seemed wild that someone would consider it.

Framework, no framework, whatever works. I’m a fan of your approach. But it’s interesting to see how abstractions like react have created a class of web developers that may not know their HTML / DOM fundamentals.

I once interviewed a guy for a clearly vanilla JS position and he only could work with React. He literally could not declare a variable in vanilla and display it in a hello world html element.

I completely understand his approach, was someone breaking into web dev and people demand frameworks and not vanilla, but definitely felt weird to me.

Then they make modules using modules and others use their modules to make modules too! Each module has little snippets copied from stack overflow because you inevitably have to have code that does things eventually.

Yep, and honestly this is why people don't see as many vanilla sites. Fear of flak, or being labeled a cowboy from the pro-framework, declarative is better, crowd.

I stopped talking to other developers. Does wonders for your mental health.

> The key reason web frameworks dominate these days is that it's very hard to keep the UI in sync with state.

I think that's it. I wonder how far we could go with vanilla js + a dead simple central store implementation that would help update the UI at different places when a value changes.

You might end up re-inventing Svelte by attempting this though.

Someone posted this here a while back: https://github.com/1Marc/todomvc-vanillajs-2022/tree/main/js - i bookmarked it because i thought it was well done

Very interesting indeed. That's some food for thought.

Though I should note that if this code has a "store.js" file, this is not the kind of store that I had in mind. More like the Svelte store [1], or Redux (which I find awfully complex).

I didn't know the "storage" event on Window [2] (which, for the record, triggers when localStorage is modified from another page. Does not trigger when modified from the same page, which makes localStorage not sufficient as-is to build the kind of store I'm referring to).

[1] https://svelte.dev/tutorial/writable-stores

[2] https://developer.mozilla.org/en-US/docs/Web/API/Window/stor...

>> Does not trigger when modified from the same page

I'm thinking that's the purpose of https://github.com/1Marc/todomvc-vanillajs-2022/blob/main/js... - without dispatching that custom save event, there wouldn't be a way to react at any other locations on the same page to the store updating.

In a recent project, I wrote my own template class that works kind of like Lithtml but without any kind of magic reactivity. It just rerenders when properties are updated through the "set()" method.

https://github.com/numtel/democratic-capital/blob/master/src...

An example template:

https://github.com/numtel/democratic-capital/blob/master/src...

> You might end up re-inventing Svelte by attempting this though

And then in the next breath make some joke about the proliferation of so many different js frameworks.

And Svelte is a “reinvention” of Knockout, just requiring a precompile. (Not complaining at all, thank goodness we have such choices.)

Indeed you will re-invent React/Vue/Svelte.

That's how it starts... React/Vue/Svelte are too big/bloated for what I want to accomplish...

1000 hours later and 200k lines of code... I just built the next React/Vue/Svelte, now there's even more options to choose from, with same amount of bloat,just different because 'my way' is better than 'their way' - maybe.

Redux is a simple, framework-free pattern for achieving this synchronization. You can use a library that implements, but the pattern is simple enough that you can (and probably should) implement it yourself.

https://egghead.io/courses/fundamentals-of-redux-course-from...

> that it's very hard to keep the UI in sync with state

I don't think that's the hard part, component reusability and templating is what makes me use a UI framework (also the extra goodies that come with it like accessability, sensible design frameworks, etc.).

Personally, I find it easier and faster and more flexible doing it vanilla style. However, you still have to come up with your own abstractions (those you actually need), meaning, you have to own the stack. This may be a good thing, but is it is also challenging regarding human resources.

As I see it, frameworks are really about making code accessible, while owning as little as possible of it, by this favouring sharing and the interchangeability of work force. Also, they establish a code policy and the kind of general approach, which is again favourable with regard to human resources. (Now you can have multiple phases of development, where neither team knows anything of the other, which would be hardly possible, if you had to own and maintain the stack. In the old paradigm of art versus engineering, it's a massive shift towards the latter. Which certainly is in line with the general trend.)

I think it’s a great exercise to come up with declarative abstractions over the DOM API. I had quite a bit of fun doing this. It only took a few hundred lines of JS to make a core for a useful web app.

Moreover, `Object.handleEvent()` allows you to handle any events centralised inside an object and in its specific context since the days of Netscape 4.0.

(Which is something many frameworks try to fix, ignoring that it's already in the core language. Admittedly, IE didn't support this before IE6, but by now this is really cargo cult. If there is `addEventListener`, there's also `handleEvent` and no need for extra bindings.)

Hits the nail on the head.

Client side frameworks are still missing it, however, when it comes to: 1. Supporting persistent client side state 2. Syncing local state to the server and back 3. Variation of (2) but collaborative state

Aside -- Reactivity could be straightforward in vanilla js with some tweaks to event handling and in-browser support for dom diffing. I made this reactive vanilla js todomvc in ~200 sloc to explore the idea: https://tantaman.com/2021-02-12-Todo-MVC.html

okay, sure you did it.. congrats... but I could do in much less work/lines of code the same:

see: https://jsfiddle.net/patrickcurl/zoastuLr/11/

html: 104 lines css: 39 lines js: 62 lines.

The major difference is I can easily 'read' and understand and 'grok' what my code is doing, yours needs more brain power to tie everything together. The majority is layout, css, etc.

Sure vue/react are overkill but alpinejs, etc makes closer to vanilla options viable that still at least have some eye-candy/syntactical-sugar that makes coding sweeter. But, I hate ugly code - I'll abstract away ugly code just to have code that's self-documenting and easy to understand.

> to make "reactivity" (hence React)

You put it in quotes but some might be missing the point you're making which is that React is not reactive.

See this quote from the docs:

> There is an internal joke in the team that React should have been called “Schedule” because React does not want to be fully “reactive”.

https://reactjs.org/docs/design-principles.html#scheduling

Another point I'd like to make is that you don't really need reactivity.

Frameworks like Mithril or Imba are not reactive, at all, and they work just fine for many use cases. The advantage is that state can be just vanilla JS. No need for any abstraction.

For example Mithril re-renders everything to the VDOM after a user event (click, etc) automatically. You can also tell Mithril to redraw [0] eg if you have a WS handler or something state change not related to user input.

I think Imba works very similarly but I don't have much experience with it.

It's a super simple mental model which I like a lot more than anything else. I'm mainly using Svelte now though for other reasons.

[0] https://mithril.js.org/redraw.html

> it's very hard to keep the UI in sync with state

says who??? UIKit used properly is beyond complete. React just introduces more problems. it's funny because it was invented because people just dont understand how to write code. UI is literally the same as model code. it's all views.

> The key reason web frameworks dominate these days is that it's very hard to keep the UI in sync with state.

That's a very interesting comment, but it is rather abstract. I think it would be very helpful if you (or someone else) could provide a simple example that illustrates the problem.

If you load an HTML page and modify it over and over with Javascript, eventually the code and page will disagree with each other as to what is what. To the point where only a refresh of the page will get it back to the starting point. Remember doing that a lot 10+ years ago?

This happens often with pages meant to be an app, rather than a page. When they grow beyond a certain size or complexity, it becomes a given.

In a UI, you usually apply some sort of MVC pattern (Model-View-Controller), which means that you have a Model (your data, which usually comes from a server, or can be created by the user interacting with the UI), and the View, which is implemented with some HTML / DOM elements and reflects what the user sees. Then you have some sort of components (playing the role of Controllers) that are responsible (amongst other things) of syncing the Model and the View both ways (when the users interacts, with the view, it might update the data, but also, when the data changes for some reason, it might update the view).

The strength of the frameworks (React, View, Angular), is to provide a way to create well-scoped (local/small) components that take care of the Model (the data), the View (generally what is called a template), and have a built-in reactive capability that facilites the sync of the Model and the View. That reactivity is extremely powerful because it "watches" all changes of the Model and knows when a change is impactful for the View. It then refreshes the view automatically so that the user instantly sees the impact of its action or any state change in the application.

When you don't have reactivity, it is of course possible to build a UI, however, you will have to rigorously and explicitly update the view yourself. You can use an observer pattern to do so (btw, under the hood, reactivity is provided by an implicit and automated observer pattern, so that all data of the model become "observable"). In any case, when you don't have reactivity, it gets more complicated and you have to really know what you are doing because your UI code can become a big mess really easily.

You asked for an example. Imagine you have a UI with the check box and when the user checks it, it shows an input so that the user can enter some text to precise some data. In general, you can implement that behavior really easily with a reactive framework. Here is the pseudo code (not meant to be compiled).

The view: <input type="check" model="checkvalue" /><IF condition="checkvalue"><input type="text" model="textvalue" /></IF>

The model: { checkvalue: false, textvalue: undefined}

The important here is the IF tag, which depends on the checkvalue of the model. When this value is false, the text input does not show and vice-versa. It is fully automatic thanks to reactivity. If you don't have reactivity, you need to refresh the view manually when checkvalue changes, and you can imagine it can become quite messy when the view and the model get bigger :)

All that being said, reactivity, if employed poorly, can also become a mess and tigger a lot of unnecessary updates of the views. That's probably why some people complain about framework performances. Of course the role of the framework is also to give you a "frame of work"... if you go out of the frame, that's usually quite bad...

And finally, you can completely develop a small UI with no reactivity applying a MVC pattern with explicit update. That would just make the code more verbose, but IMO, it is doable if you know what you are doing. And it can probably be more efficient in some cases because you don't rely on the framework magic (you can decide in your program when to update the view).

This perfectly explains why, incredibly smart engineers at ThoughtWorks and the like are using React components to build stateless documentation sites

Perfectly reasonable isn't it?

Browsers do nothing to help us manage state outside of individual elements.

That’s actually all I use for state management. Elements pass data to children through attributes and bubble data up through events. It’s worked well for us on a complex front-end using native web components.

That's basically a home-made React (& co.) duplicate (which is great). This simplifies development considerably, because you break the original problem into a) updating the state and b) translating the state into UI elements, and the framework (hopefully) automatically updates UI as needed.

This is called prop drilling. It technically works for any size or complexity of app if you're willing to make every intermediate component have knowledge about every possible piece of state that might be wanted by a component lower in the tree. It's extremely cumbersome though.

Back in my day we could search for child elements with specific attributes without needing the intermediate elements to know anything about it.

What REALLY happened is the shadow DOM. People decided it was too slow and created an intermediate representation. That then created all kinds of OTHER problems that started resulting in solutions that wouldn't have been necessary without the shadow DOM.

A shadow DOM is basically a cache, with all the problems that entails.

> Note that the shadow DOM is not a new thing by any means — browsers have used it for a long time to encapsulate the inner structure of an element.

https://developer.mozilla.org/en-US/docs/Web/Web_Components/...

And for even longer than that, it was a term describing the technique of keeping a tree-like structure that would gather updates so you could eventually update the actual DOM all in one go because updating the DOM piecemeal was slow.

The term was popularized long before "web components" was a thing, and in fact, that's where they got the name.

Do you mean virtual DOM?

Which state are you referring to? I feel parent poster is talking about different state than what you have in mind.

The state that matters to users. All the rest is lies we tell ourselves.

There's a reason developers are constantly inventing ways to remove state from their code. Managing state is messy. Frameworks simply move it around.

Most react apps would be better off written in PHP, html, and progressively enhanced JS.

This is coming from a react developer. Most of what I do is bullshit work someone else invented for me.

But it pays well so ohwell.

Honestly, I'm turned off by these frameworks. Javascript is an easy language, and these frameworks raise the bar to entry. Many will say they make things 'easier' but that's not my personal experience. Some context: I wrote a lot of JS in the early/late 2000s (Anyone remember WebFX by Erik Arvidsson?). His follow-up gig became WebOS[0]

Back then it was called DHTML or Dynamic HTML and then evolved into the HTML5 standard later on. The syntax of React & Vue is just too weird for me. Frankly I've reached a framework fatigue after learning jQuery inside out which was a hard-won battle, and then having to learn React/Vue/Svelte just to stay 'in the game' is too much for me. Excuse me if I'm biased here.

[0] https://newmedia.fandom.com/wiki/Web_Operating_System

I hear you...another level is that building javascript files has gotten so obfuscated with build processes such as webpack, babel, and typescript, that it adds a layer of confusion just to output code that you know is valid code, but all these darn build processes may give you problems under the hood....then you gotta research all that nonsense and find that some packages weren't updated.

THAT is the fatigue part to me. I don't really mind learning new frameworks, cuz let's be honest, most of them are all doing CRUD operations and repainting the browser with new html. However, under the hood stuff that potentially arises with misaligned, packages, or configs...ughhhhh

Webpack specialist became a position recently. I miss these good times when you could simply %.o: %.c $(CC) -c $(CFLAGS) $(CPPFLAGS) -o $@ $< and feel great for the rest of the day.

I find this interesting because the string you just provided you feel is something so ubiquitous that everyone knows what you're talking about.

It may as well be a foreign language to me, but webpack? Webpack is easy... To me.

I think the parent commenter’s script was posted with tongue in cheek.

I don’t think so — there was never a time when C/C++ build specialist was a position.

And yes, it used to be easier. We didn’t have the speed and convenience of deploying code to the web, but we delivered software that worked, and with nicely-written end user documentation.

Have you ever tried compiling 20 million lines of code? Probably gonna want a build specialist to distribute that over as much cpu power your org has available. Unless thats something you want to do in addition to everything else

Roles that specifically deal with build tooling/improvements are totally a thing in various places.

That's looking at history through rosy glasses. Now edit the contents of a transitively included header file, run make and feel unhappy for the rest of the day while debugging why your executable did not get rebuilt.

Every environment of its time goes through a phase of build-specialist position, required for big projects. Webpack must be one of the worst so far though, it's in this uncanny valley of being unopinionated yet still requiring special operators and plugins for everything. It feels like a black box where you just can't be creative and compose things yourself, you always have to copy a template and find the magic justMakeItWork-option. No surprise really, since it's in a rather difficult position, integrating 3 major legacy technologies (css/html/js) that were not meant for it to begin with, add pre-processors like sass, typescript and static asset generation to the mix and you have more than 6 stacks to spaghetti together.

Hahah, I'm not surprised. Them config files have created a niche FE DevOps Specialist role.

To be fair, while the hours of painful medium articles and gists research, the knowledge gained has given me a better understanding of Webpack, and I do feel more confident when taking on various tutorials which all have different approaches to fit the config to my needs. But still, as a newcomer to JS or someone in OP's position, the build game is certainly a lot more complicated than your command!

....btw, I have no idea what your command does/says :D. Linux (Ubuntu) CLI syntax has been something I've tried to improve on over the years.

Yep, the blogspam only adds to the complexity because you can not be certain of an author's level of knowledge until you become an old sailor yourself.

This command is a Makefile rule for building .o out of .c source files. It is var-heavy, but results in something like:

  gcc -c -std=c99 -Wall -I/path/to/headers -o file.o file.c

I have no idea what my usual webpack config results into and how to debug that mess.

Spotted a non front end developer.

I'm being honest here -- there are things you need to learn. You may not like them at a beginner or someone new to the stack, but they are here as industry standards for good reasons (which I won't go into here).

By the way, JavaScript is not necessary a language as "easy" as you think is. I have seen plenty of bad code written by professional software engineers. Seriously, you need to put a lot of effort into becoming a good front end developer.

Some of the very best websites I've had the pleasure of visiting and interacting with use vanilla (like https://ciechanow.ski/ for example). Using React for every frontend solution is like using K8s for every cloud solution. Great if you know it, but a huge complexity headache for literally everyone else.

React is orders of magnitudes simpler than K8s. You can write your own React in a day probably.

Or you can avoid frontend work

Javascript is an easy language only for trivial use cases. Once you start having to deal with real-time async state across multiple components, it becomes very much not so easy.

These frameworks aren't meant to do what basic DHTML did back in the day. Those use cases are still served just fine by basic scripting or serverside interactivity.

What these frameworks allow are entirely new classes of featureful client-side applications (think Google Workspace, Maps, Earth, dashboards, games, sketching programs, photo editors, etc.) that would be HELL to write in vanilla JS.

If you're not building something like that, nobody is forcing you to use those frameworks. But at a certain level of complexity, those frameworks are worth their tradeoffs. Beyond that, at an even higher level of complexity, they become necessary... or you end up writing your own framework.

The reason these see such adoption isn't because devs are getting easier, but web apps are getting orders of magnitude more complex than back in the day.

I don't think the bar to entry to has necessarily gotten much higher; rather, the skill ceiling has increased a thousandfold... you can still be a basic JS dev to add a basic form validation and submission or whatever, and you don't need React for that. These days vanilla is plenty powerful for simpler use cases. But you can't easily scale that up to the level of modern web app interactivity. Or if you can, well, build it and show people and see if you succeed in convincing them "this is better than Vue/Svelte/React/Angular". People are always saying that, but I've yet to see a complex web app NOT written in some sort of abstracted framework. If you manage to do it, it would be very impressive and way more convincing than just saying "frameworks are unnecessary" -- because as far I can tell, along with thousands of others of web devs, they are not.

> Back then it was called DHTML or Dynamic HTML

Well that was rather during the 90s, no? Like a decade before HTML5.

That was what it was called when I first started using JS in the late 90s with IE3 or 4 IIRC.

Same here as a backend engineer.

I went into js/ts because I wanted to create something that I can interact with graphically, I don't really care about DOM.

Worked out for me mostly:

https://aperocky.com/cellular-automata

https://prehistoric.tech

These are built with typescript and compiled to js, with HTTP/CSS being static. And basically no framework usage. All of the complexity are essentially the simulation themselves.

I second this. I started writing HTML/Javascript since before CSS existed. Nowadays I mainly do backend, but keep doing JS/CSS/HTML for some small pages.

I recently started to work in React for some work stuff, and I just hate it. Actually, both the "class oriented" and the newer "hook oriented" versions just suck. They amount of abstraction crap that get over a website is amazing. And Redux with the dispatch state change ... Angular is a bit more sane but still similarly bloated.

That is just because you worked for long time with backend. Angular looks better for you - because it was developed to be easy adoptable by backend devs. But React is great, it just use different paradigm than is used for backend development. PS.I have also stared from those web early times.

I can relate to that. I got "lucky" that I had to learn React in a few weeks, and while I grumbled a lot in the beginning, I came to love it (not js packages ecosystem though, that simply sucks). Huge thanks to my coworkers at the time who took me through the speed course!

You need to look at ES6 as a completely new language, almost completely unrelated to JS. Once you learn it, React is easy - and genius in its simplicity. I can't imagine building even a medium sized webapp without some way of building UI declaratively. Maintaining a classical jQuery / native JS webapp is a nightmare, while these frameworks break up the problem into manageable pieces.

Highly recommend biting the bullet and learning one of them, it really is worth it (not necessarily React, there are lots of others too).

You'd dig Joystick: https://github.com/cheatcode/joystick.

I designed it to be a natural transition from learning the fundamentals of HTML, CSS, and JavaScript into full-blown, component-driven UI development. Dirt simple API, no syntax tricks, no specialized knowledge. Just plain ol' HTML, CSS, and JavaScript organized into a system that's more productive than standalone files.

It works on its own in the browser or as a part of a full-stack framework.

You are not alone. I've done exactly what you have and have faced 7 months of job searching headwinds this year just because (at least it feels like this to me) my employer didn't put me in front of enough React code (because they put me in front of other legacy code that needed more attention!!).

You may like notemplate¹ O:)

1) https://github.com/stefanhaustein/notemplate

The web was originally created to share documents, so interactivity and extra functionality was an afterthought. As the web became more popular, websites started to add more functionality similar to traditional software programs.

Eventually, the original guideline of HTML for structure, CSS for styling, and JavaScript for interactivity started to not really make sense anymore for many websites, because as pages became more interactive, the lines became blurred. If you look at a site like GMail, where does the page structure end and interactivity begin?

With large parts of a page being interactive, it becomes difficult to manage all the state involved, especially if it’s a “live” page that updates in real time and may have several people viewing it.

Frameworks were introduced as a way to manage state and allow websites to re-render efficiently without hard page refreshes.

I think you've got the building blocks, but to really capture the "sometimes evolution is stupid" feel, you have to mention stuff like Javascript was created in ten days under some stupid deadline, with a stupid insistence that it have "Java" in the title. Or CSS being -- if not orthogonal to, at least wildly unparallel with -- against the grain of basic design principles like Contrast, Repetition, Alignment, and Proximity, then that awkwardness causing generations of table-based alignment solutions. And demands unforeseen, like piping video over HTTP. Take a step back for a second and think about that: we've got all of this stuff layered atop what was originally just a handful of specs on how to push barebones scientific papers around. Let's give a nod to Ports 80 and 443 uber alles, because of convenience, for video. And then the reaction -- well, how do we throttle this properly? We'll have to inspect, when before we just throttled the video ports for whatever video protocol we were working with.

It's a history of one decision after another, made hastily, often in anger, and it's how we got ... here.

IMO this is the best answer. A clear, history-contextualized summary of the reasons why vanilla is often not enough for some use cases.

For some use cases, sure.

But most sites aren't GMail. Frameworks and typescript should still be the exception, and the rule should still be independent, modular libraries like JQuery.

> But most sites aren't GMail. Frameworks and typescript should still be the exception, and the rule should still be independent, modular libraries like JQuery.

People always say this but it's so hollow. Most sites aren't Gmail, but we're not building most sites. We're building applications that work in similar fashion to Gmail, thus need similar stuff like all these frameworks provide.

"Oh but everyone's using React to build their blogs instead of writing new posts for them and that's overkill"

Let me stop you before we get to this point. People use their personal blogs as a way to test new concepts they want to learn, so of course it's gonna be over engineered to hell.

So what about when product management starts demanding even more interactivity on a marketing site built without React?

I pushed back hard on introducing React when the site already had jQuery. Another developer said they could do what was needed with React.

The marketing site started shipping both jQuery and React.

I hate the JavaScript/React ecosystem so damn much for its complexity.

You hate a valuable ecosystem because your company product managers listened to someone else?

I hope you find a new job. That's like saying you hate bananas because someone asked for a pie and you said you'd make an apple pie and they said they'd make a banana pie and they decided to choose the banana pie instead of your apple pie.

You're being uncharitable for no good reason. If you're not sure if your interpretation of what GP said is true, ask for clarification and stop at that. Your first paragraph is ok, the second was uncalled for.

Uncalled for? I was explaining in a metaphor how I interpreted OP's reason for not liking React/JavaScript.

I don't like PHP/Laravel ecosystem because I recommended we use vanilla PHP and my co-worker recommended we use Laravel and my manager decided to use Laravel.

I don't like Python/Django ecosystem because I recommended we use vanilla Python and my co-worker recommended we use Django and my manager decided to use Django.

Swap it with literally any framework in any language vs using vanilla-<lang here>. It all sounds just as ridiculous.

> I was explaining in a metaphor how I interpreted OP's reason for not liking React/JavaScript.

Yes, but you failed to note it's just your interpretation, not what the GP said himself. And you continued by assuming your interpretation is correct, suggesting that the GP should get fired because of it.

In reality, your interpretation is most likely not what the GP meant, and you clinging to your uncharitable interpretation in the context of GP comment was what I called "uncalled for". Please review the HN guidelines, this situation is addressed there explicitly (argue against the strongest interpretation of what others say, not the weakest; argue against what was said, not a person who said it). It's worth revisiting the guidelines from time to time, even if you're a long-time user.

In this case, the more sensible interpretation would be something like this: the ecosystem where you have to include two completely different frameworks to get things done is overly complex, and the complexity is what the GP hates. It's perfectly valid position, too.

> And you continued by assuming your interpretation is correct, suggesting that the GP should get fired because of it.

Uh, where did I say GP should be fired for it? I said "I hope you find a new job" because he sounds unhappy at his current place.

...it seems I also jumped to conclusions, I shouldn't have assumed the negative meaning of that phrase. My mistake, sorry about that.

I hate the complexity of the ecosystem. The benefits that make it valuable are obvious to us all. You do understand the downsides of shipping both jQuery and React on the same site, right?

Recreating everything in React when you just need a few JS lines of code for marketing is absolutely "bananas"

There's not enough information about the task for you to claim that "you just need a few JS lines of code"

I know marketing sites that were just static and I know marketing sites that had highly interactive examples and needed to have React on the page.

> typescript should still be the exception

And JS shouldn't be exceptionally bad but here we are, and people use TypeScript as alternative to stay sane.

I agree that modern web development comes with far too much complexity on average, but people started adopting those frameworks for a reason. The web is kept backwards compatible with obsolete standards which have been created in a different time for different purposes, and at some point it becomes easier to build abstractions over that. For example TailwindCSS adds another "compilation" step and configuration file but in return makes styling much more tolerable than standard CSS. Is it necessary? No, but when you build a large website all those little things add up.

Agree here. TypeScript is a bit of a Godsend even when using the vanilla DOM API because (a) the DOM API uses so many different abstraction patterns that it's easy to lose track of which one you're using (and passing the wrong arguments with no static typechecking is a runtime error) and (b) JavaScript itself has so much wat (https://www.destroyallsoftware.com/talks/wat) in its implicit value coercions that it's invaluable to have types narrowly-scoped in code so you have any hope of predicting what the output of operations will be.

Python is strongly typed so doesn't suffer from coercion errors like js. Pyflakes has been a thing for a decade or two. Type checking is now well supported.

Pyflakes is better than nothing, but it is the nature of Python itself, IIUC, that it can't guard against variable typos because the mutable nature of the various contexts is such that the code under evaluation can't know if a variable name is referencing something that wasn't monkey-patched into scope via code in another module.

There's just no way to know that `if foo:` doesn't reference a foo that's supposed to be on the global scope.

(Contrast JavaScript, where `use strict` was added to force explicit reference to non-local scope).

While theoretically possible, this doesn’t happen unless you’ve put effort into destabilizing the code on purpose. Folks monkeypatch to fix problems, not create them.

You can explicitly mark a nonlocal or global as well.

Now if your project needs to be impervious to malicious actors, additional safeguards will be needed. But I’ve never encountered this situation in a long career.

It's not about the why, it's about the fact that because it's possible, the language has to allow for it.

Unless I'm mistaken (and please correct me if I am), no Python linter can address the fact that

`y = myVoriable + 3`

... is valid Python code because there's no way to know a-priori that `myVoriable` isn't a valid global variable, even though human inspection makes it obvious that it's a typo on `myVariable`. For that reason, there's a practical limit on how much static error checking Python allows as per the design of the language.

Has this been changed in the past decade? If so, I should give this language another chance.

No, pyflakes will catch that and always would to my knowledge. It did have a bug or three where it would miss an occasional issue but they were bugs (not impossible to detect) and fixed years ago.

The error message is slightly obtuse, says something like "variable only used once." But is clear after inspection the first time.

As someone who’s become most comfortable with strictly typed languages (primarily Swift and Kotlin), I find that TypeScript makes my dabbling in web dev much more tolerable and even somewhat enjoyable, even for simple projects with zero dependencies. Plain JS becomes frustrating quickly as project complexity ramps.

Lots of hammers, when few actually need one.

> Eventually, the original guideline of HTML for structure, CSS for styling, and JavaScript for interactivity started to not really make sense anymore for many websites

My emphasis added.

There are still absolutely tons of sites for which the classical model works fine, and indeed works better than React at al, because pages load faster and behave more normally.

Some of those sites are now built with React et al anyway, for some bad reason (cargo culting, resumé-driven development, etc). But still, most are not, i suspect. Classical web development is still a very useful skill.

However, i suspect that although a majority of web sites don't involve React et al, a majority of web development jobs do - because the fraction of sites that are complex enough to need React et al also need a lot more developers!

(a fact i think is fun: a majority of stars are in binary or multiple star systems, even though such systems are a minority of star systems)

> If you look at a site like GMail,

Ouch! As a google mail theft victim, "right in the heart" :(

> efficiently without hard page refreshes.

And completely destroying the "Back-forward-refresh" functionality.

The thing I've found about working with React (and the web frameworks like Vue and Svelte), is that once you embrace a component-centered model, it makes virtually all web development easier, even relatively simple projects.

There certainly is a decent subset of web development work where HTML/CSS/JS is still reasonable and viable, but it tends to be less complex, and low-code/no-code tools like Wix or Retool are quickly taking over that space.

But you also get yourself dependent on fw devs. And they most certainly don't care about you, your needs and your customers. Wix? That Wix that broke support for all old browsers and devices? Lost views and customers? Thanks, but NO, THANKS. And you, as a site owner, can do NOTHING. You rely on what you're offered. They break it - you're screwed.

If you mean framework devs, I disagree that they don't care about you. Frameworks are generally free and open-source, so creating a valuable product for the community is arguably all they care about. Maybe meeting the specific domain needs of an individual user is not compatible with their implementation or roadmap, but it's not because the devs don't care.

I was not recommending Wix, and obviously there are plenty of downsides to using something like it. The fact remains that it has captured a lot of the market that would have used vanilla HTML/CSS in the past. That is what the OP was asking about.

Doesn't the browser now have native web components and this will replace React as time continues?

React is about a whole lot more than just web components. It's also a strategy for state management, life cycle, etc. I don't expect web components will ever replace react, but I think it's possible we'll see a new generation of react-like competitors that use web components under the hood.

> It's also a strategy for state management, life cycle, etc.

As a backend dev who can do a bit of traditional style frontend, I fail to see the need for all this complexity. Most apps are running same database queries and displaying it on a webpage.

Ya, but you gotta roll your own process for the stuff React and co. provide easy methods to do. It's just a lot of boilerplate for small projects. I don't know if web components will really be a "library killer" in the same way browser APIs have done with jQuery.

https://github.com/mdn/web-components-examples/blob/main/pop...

SSR always supported components.

I don’t understand your comment completely. The “traditional” SSR frameworks (PHP, Rails, Express) didn’t make it easy to componentize things, instead trying to divide logic by broad category (MVC, etc.). I don’t know whether it’s orthogonal to Web development or caused by its complexity, but the emergence of components as a primary unit of abstraction is meaningful IMHO.

The traditional frameworks like JSP tag libraries, JSF, ASP, ASP.NET Web Forms, Cold Fusion, Zope, AOLServer, our own Safelayer, live from components.

PHP was always a anything goes, Rails never impressed me having used AOLServer and being part of a team that created a similar architecture with TCL (Safelayer mention above, the founder of that startup created Outsystems), express is basically a servlet engine in terms of features.

The purpose of a React component is more than just rendering HTML nodes. Furthermore SSR can only do so once per page load

Just like SSR frameworks have been doing for 20 years, including JavaScript integration.

https://www.primefaces.org/showcase/index.xhtml

What I originally meant by the "component-centered model" of React is not that it gives you a prefab list of elements to include on a page. I meant that it gives a framework for organizing custom logic to coordinate the behavior of some DOM subtree.

Also the library you linked can hardly be considered vanilla HTML/CSS/JS

Just like JSF was doing 20 years ago.

It surely is more vanilla, as originally it was designed to work with JavaScript disabled, if so desired.

If JSF has abstractions that encapsulate arbitrary units of logic running on the client, then it is a frontend framework, by definition of frontend framework. If it doesn't, then we aren't talking about the same thing.

Also vanilla HTML/JS does not mean html that works if JS is disabled. It means you are literally writing out the document that is delivered to the user without transformations or a huge runtime library included.

This JSF is not vanilla HTML: <p:commandButton value="Update event2" update="@obs(event2)" icon="pi pi-check"/>

You are using the old syntax, there is also the HTML 5 one with data attributes, just like all those lovely SPAs.

Still the point holds, component frameworks exist for 20 years, it isn't an invention of cool kids JS SPAs, and they work without JS if needed.

hush now, that's supposed to be a secret they only learn once they start working outside of node.

You're right. :)

I build the frontend of all my projects with plain HTML/CSS/JS.

Every time I talk to developers who use frontend frameworks, I challenge them and say: Let's sit down and build the same application. You build it with React or whatever, I build it with plain JS. Let's see which one is leaner and more logical.

Every time the answer is the same: The benefit of a frontend framework will not become visible in a small app. Only in a big app.

Then I ask: Ok, where is the cut off? What is the smallest app, where React will shine? And I never get an answer.

When I see React examples like this calculator ...

https://github.com/ahfarmer/calculator

... which use 70 files (without dependencies!) to build something one could do in a single HTML file, I am afraid that those "big" apps the React proponents talk about will be very big when implemented with React.

> Let's see which one is leaner and more logical.

Leaner, yeah, I'm certain a vanilla app will produce less KBs. What about dev time? I've been writing JS since the late 90s and I'd never use vanilla for anything other than trivial projects, quick tests, etc.

More logical, that is 100% subjective.

> Ok, where is the cut off? What is the smallest app, where React will shine? And I never get an answer.

Of course you won't. It's an impossible question. Could you say with certainty at which point it's better to use or not use a framework? (any framework with any language) You can't.

Once you're deep into the swamp you may realize you should have used a framework... but it's often not obvious a priori.

> which use 70 files (without dependencies!)

Honestly that's kinda ridiculous. You could build a calculator with a single file and a couple of components. This is not a problem with using React or any other of the modern libs but with that particular programmer.

> Honestly that's kinda ridiculous. You could build a calculator with a single file and a couple of components. This is not a problem with using React or any other of the modern libs but with that particular programmer.

Yeah I'm trying to figure out how someone could possibly reach this number of files if you're not counting dependencies...

If I make the app with the explicit goal of having as many files as possible I can think of:

~6 config files and dotfiles. Maybe make it TypeScript so we have a tsconfig.json as well and maybe we'll have a README and LICENSE as well for good measure

In our public folder we'll have the index.html, a _redirects, robots.txt, a favicon, logos of different sizes, a manifest just in case, a sitemap because why not. Maybe a dozen files in total?

But for the actual source files? index.tsx and App.tsx (I usually make these two the same file). Maybe we're keeping our jsx and css in different files so let's just double the number of components by 2. I'm struggling to think of why this might have to be more than one component but let's just say it's 2. So 4 files in total. Let's even say there's a custom hook for some reason so that gives us another file.

That's like 7 files for the source code if we really stretch things out. Maybe you're one of those people that likes to have separate files for your routing or maybe you have some Layout.tsx business going on. Still can't imagine it stretching passed 10 files.

I'm up to 28 with a ton of rounding up...

I use both frameworks and non frameworks on different sites, some extremely large and some small. You can shoot yourself in the foot with either and I wouldn't make a blanket statement that one way is better than the other.

I don't like the trend of using React to build a brochure level website with near zero ui interactions or api calls, it usually ends up bloated and a pain to try to split code, reduce bundle size, etc. for no real gains.

On the other hand, when I work on a complex stock brokerage dashboard with tons of data, tons of fancy ui that needs frequent updating, and a massive internal state with tons of user data and stock data (also being frequently updated), React is a pretty good choice.

One of my other sites is a legacy property with all UI powered by a single 6000 line jQuery and javascript file. It's very easy to break something without realizing trying to make changes there, so people keep adding new stuff at the bottom to minimize potential breaking changes. Definitely not the ideal vanilla JS setup but it isn't a good fit for the organization's needs.

At the end of the day, react is javascript and you can make any react site with plain javascript... but it is sometimes a useful abstraction for highly complex environments with many people working on them.

In my day job I work with frameworks, and do vanilla development for all of my personal projects. But then I realize that in the end I'm just building my own frameworks (DB, states, UI), that I might use or fragment and reuse in other projects, because it all becomes boilerplate, and the top level logic is what's different and actually matters.

The benefit of React is that it’s declarative. Vanilla JS is imperative/procedural.

If you build anything semi-complicated, you’ll build your own declarative framework.

*Imagine that the biggest body of water you’ve ever seen is a dinky little pond and you think, “Yep, that’s about as much water as there can be! There’s nothing deeper or wider than this. Seeing water that stretches onward to the horizon, water that can turn into tidal waves, water that hides giant whales and creatures that have never seen the sun, that’s just a bunch of tall tales.”

And maybe you can be happy sitting next to your pond, so long as you never see an ocean. Maybe when you meet people who tell you about the magnificent oceans they’ve seen, you figure they’re just exaggerating what it’s like to see a pond. “Ah yes, I remember seeing my first pond,” you chuckle. But somewhere deep in your brain, there’s a little twinge of doubt.*

Can you build Microsoft word or google maps or any of the 100s of other moderately complex web apps without a framework?

The top complex component in Word is the text editor while the tricky component in Maps is the map. Neither of those can be made with the frameworks we're dealing with here, so that is a go. We can make the traditional UI with a simple view library like lit-html [1] and we'll want to keep some state around, but most state managers can be rigged to Vanilla. I'd totally prefer Web Components to any popular framework for the particular apps you suggest.

[1] https://lit.dev/docs/libraries/standalone-templates/

Obviously not Microsoft word but I built my resume builder using vanilla JS, html and css:

https://resumetopdf.com/

That's a nice looking project

Funny thing is the two should be built with vanilla js and canvas. No popular framework is going to do better.

The inaccessible to non-sighted users, non-computer interpretable canvas? The one where we’d need to reinvent text flowing, resizability, the box model, etc? That’s what you think we should use to build our Web apps?

Yes, in order to be best it needs to re-invent those wheels. Otherwise, vanilla js with DOM nodes is in the same league as ReactDOM.

parent has already essentially admitted that the answer is no. they asked "where is the cut-off?"

Yes it's possible, the problem is dev time.

Of course some sort of framework will naturally occur as a project grows.

Another way to ask the question is how small are your projects? How many engineering-years do you put in each of them?

If the cutoff is something like 10 years, what would your response be?

Parent poster is aiming at calculator app as "something people do in react and should be complex" - calculator app is still graduate level thing of limited scope and quite well defined. I assume he have not seen any project that grows for 5+ years has 20 dev working on it (20 because of team rotation maybe 3-5 working at the same time).

Regular non-ui programming is different from ui one.

In a regular straightforward program you apply a change and read it back only when it is needed. Even if that change is cached/computed/transformed/etc, there is only need to observe it when your program execution comes to that part.

In a ui program after doing a change you have to somehow update all the relevant elements/controls that are currently visible on a screen, i.e. replicate the whole state of a program into a graphical context at once (regardless if html or not). This process has associated costs and is pretty error-prone if not addressed systemically. All these frameworks spin around some idea of optimization of it. Since it can't be done without tradeoffs, they invent new ways of thinking about a problem, offloading parts of it via methodological contracts to a developer, who pays their half of the price. Different developers have different opinions on how high the price should be and which trade-offs they should take.

Is it worth it? Sometimes yes, sometimes not really. In my opinion, ideas behind some frameworks are useful by themselves, but in general all this tends to become more religious rather than technical. E.g. if you weigh what "cost" is or how error-prone the straightforward approach is, you may find that for some cases it doesn't really matter.

We do 100% vanilla web development for our B2B product now. Our roadmap went something like:

(Client Authoritative State) Angular 2.x/??? => RiotJS/Bootstrap =>

(Server Authoritative State) Blazor/Bootstrap => Custom/Vanilla

The Angular and Riot apps were a nightmare to maintain long-term. We sign contracts with our customers that are 5+ years long, so having autonomy over this sort of stuff is critical. The rate of change with these frameworks was too much to deal with, especially at our scale of <10 employees.The big solve moving to Blazor from RiotJS was keeping the state on the server and being able to reuse existing C# codebase to manage UI. This continues to be very productive for us. Server-authoritative state is the answer for keeping complex UIs on rails.

We still have quite a few interfaces on top of Blazor, but those aren't really a pain point for us (at least until Microsoft does what they usually do in a few major versions...). The biggest catalyst for moving from Blazor/Bootstrap to Vanilla was 2-fold: On one hand, the power of modern web APIs, such as CSS Grid, eliminates a large reason why you need a 3rd party layout system in the first place. On the other, we realized that dynamically updating the DOM using a 2-way web socket setup is actually not that complicated or scary, assuming you have well-scoped requirements and aren't afraid of javascript.

For hand-rolled vanilla, the way we sync the DOM is with a simple 2-way web socket protocol where the server has a dictionary of elements per active client, and hashes of state are used to detect required updates after client events are processed. No shadow DOM or any of that crap. We just blow it all out and redraw on update. None of our UIs has enough elements to justify all that extra complexity right now. We could easily iterate into several directions if we needed to over time. The key point is that we understand 100% of our stack. Every line of code makes sense to us. At no point do we have to worry about someone pulling support or shifting their framework in an adverse direction.

Finally, we also have major security concerns with vendoring out anything, since our product is used - in part - for in-branch banking. The hottest PII you can imagine flows through our web app every day. Being able to tell various CTOs that there is no supply chain risk with our web UI is a very fun hat trick for me.

I have a mini-rant about that. When a company decides to use Angular (for example), they're also deciding to jump on the rat-wheel that is constant upgrades to the next version.

Meanwhile, that vanilla app will just keep working in perpetuity.

A company can just stick to one version of Angular in perpetuity if it wants to. The code in some Angular X.X.X release will always be the same, and the Angular org can't magically break your code by releasing a new version of it.

But if your framework of choice is big, you’ll have trouble extending/modifying it and be locked in.

And if your hand-rolled solution is big, you'll also have trouble extending/modifying it.

The argument was that hand-rolled code doesn't break on its own, and my point is neither does framework code.

That was never the argument.