Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: What happened to vanilla HTML/CSS/JS development?
315 points by silent_cal 25 days ago | hide | past | favorite | 397 comments
I'm not a web developer, but I dabble in it because I find it interesting. I went through some courses like The Odin Project and others to learn the basics of HTML/CSS/JS, and I thought it made a lot of sense: HTML structures the page, CSS handles the style, and JS handles the functionality.

However, after working for software companies for a few years, it seems like almost nobody uses these technologies in the way they're presented on websites like w3schools to make web applications. Instead, they use component-based frameworks like React. To me, these frameworks seem way more complicated than HTML/CSS/JS, and I don't understand what problem they're trying to solve. What makes the trade-off of all that extra complexity and abstraction worth it? Aren't HTML/CSS/JS perfectly fine and time-tested tools for web development on their own?




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.



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.


This is hilarious. Those web apps are single page applications, more application than page. The most of what face book does in the background has nothing to do with what the user can see, for example. A chat might require interactivity, but static designs with push and pull work well enough for many use cases, with sparse scripting. The bespoke tutorials might rather target a geocities homepage, admittedly.

It's funny to see how responses in this thread jump immediately to reactivity or "skills you can reuse across projects" but without making the case: why?


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/


If you want to stay close to vanilla, I'd recommend lit: https://lit.dev/


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



> 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 already managed state just fine. We just didn't like the way it looked.


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.


I don’t think JS is much worse than other dynamically typed languages to be honest. In Ruby you’d get an exception instead, which is mildly better than `NaN` in your user-visible text, but not much.

The DOM though is definitely complex and built of accretion over time. The Web resists refactoring because we can’t break websites from the 90s.


> I don’t think JS is much worse than other dynamically typed languages to be honest.

I agree; it's a plague all dynamically-typed languages face. I've yet to meet one that doesn't hit me with some kind of powerful pain-in-the-ass corner cases as a trade-off for the power of its terseness.

I fell in and out of love with Python over the course of a decade or so. Initially very excited about doing so much with so little code; fell out of love when I used it in an industry setting and realized 100% unit test coverage was mandatory because the lack of variable declaration means every line of code is a potential runtime error in waiting due to a simple name typo.


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.


How sure are you of that?


You can vendor your project's framework of choice. Or, more generally, all your dependencies.

Moreover, I believe you should be able to build your project without expecting npm to host all your dependencies ~forever and being online when you need it.


A PCI auditor will ding the shit out of you for using a version of Angular that has known security vulnerabilities, even more so if you've decided to "vendor your project of choice" and it's been EoL'd.

And for good reason.

While you can theoretically do this, the point is that you really can't, nor would anyone call it responsible to do so even if they weren't worried about regulatory compliance.

The question isn't "can you keep it forever", the question is "how long can you keep it". With these frameworks that answer is typically 18-24 months. For more mature systems that answer is going to be 3-5 years, and for even more mature systems it's going to be 8-10.

FOR EXAMPLE

asp.net https://docs.microsoft.com/en-us/lifecycle/products/microsof... 2015-2022 = 7 years

Angular https://en.wikipedia.org/wiki/Angular_(web_framework)#Suppor...

2021-2022 = 1.5 years. And the status is LTS (LONG TERM SUPPORT).

But it gets even worse than that because the asp.net is worrying about the _runtime_, Angular is worrying about the _framework_. If we were going to compare apples-to-apples here, the support term for asp.net is even longer than 7 years.

---

The reason so many developers don't consider this is specifically because they move on every 18-24 months, and they're happy wasting time upgrading systems on the ratwheel. But businesses aren't, instead they're held hostage by it.

---

There's another thread on HN right now with people bitching about SAP. SAP will still run functions that were written 20 years ago.


You seem to have more experience in PCI-related stuff so I won't comment on that. I'd like to focus on engineering point of view, not compliance matter.

Let's say a company's app has a security vulnerability. Let's consider 2 scenarios: (A) using Angular vs (B) using an internal framework.

From engineering perspective it doesn't matter if it's (A) or (B). It's not like the internal framework will be perfect and bug-free.

In both cases it is company's responsibility to patch their app. In case (A) they can fix it in their internal fork of Angular; or fix it upstream; or update Angular to an unaffected version. In case (B) they have to fix their framework.

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

and I disagree with it.

If a company doesn't care about security, they can have Angular "working in perpetuity" as well as their vanilla app.

If they do care about security, their vanilla app will not (securely) "work in perpetuity" since it will need a fix sooner or later.


But you've snuck in another dependency there: that if the company uses Angular, they then have to have people familiar enough with the codebase of Angular itself that they can fix security bugs in it if they crop up. This is patently nontrivial, and a world away from having people internally who can fix bugs in...their internal framework...that they developed.


> This is patently nontrivial

Exactly. I can walk a new developer through most of our internal framework's actual source code in about 30-45 minutes. If you told me I had to explain the inner workings of Angular to some new hire, I may consider a new career path.


People like you keep me employed.


"Every dependency is a benefit and a liability."


Using pure HTML/JS/CSS is so unopinionated that it's very easy to create spaghetti, and hard to onboard new developers because you have to teach them a lot of 'this is how we do stuff here'.

Don't get me wrong, it's perfectly possible to create spaghetti in React, but it just makes large codebases so much more manageable, and the tooling and ecosystem around it is massive.

Typescript with React and a bundler, linter etc. is just an amazing developer experience, compared to the mess those of us who did front end development in the past remember.


I agree with this. It's especially important to use opinionated frameworks (Angular being more opinionated than React) when working with a lot of contract developers who rarely care about internal development culture or standards. With Angular, there are a lot of prescribed ways to accomplish common functionality which you could solve any number of ways in React or even more ways in vanilla JS. A cohesive and experienced development team can do amazing things with whatever tools and frameworks they decide to use, but less cohesive teams benefit from opinionated frameworks.


Vanilla html/css/js are great for static sites, but once you start building an application it gets more difficult to manage state: both on the page, and with the backend that stores user data.

What you're saying is similar to saying "I don't understand why someone would use Django, can't I just use the python http.server for an API and psycopg to connect to postgres?"

The answer is yes, you can do that, but over time you'll find that there are pitfalls with a bare-bones approach that are easily avoided by using higher-level frameworks. Mostly the spaghetti that someone else mentioned, but also getting caught up in technical details that the frameworks have mostly already abstracted away.


The trouble is that even with good definitions for "web site" and "web app" (the distinction clearly matters, right?), non-developers always want their web sites to be more interactive, to the point that using React somewhere you shouldn't feels like the "easiest" choice.

I hate this.


The fundamental problem is that HTML is technically stateless but a web app is not.

So to do anything that needs state (think google maps, or a responsive website) you need to either build or buy a way to manage that state, while working inside the confines of HTML/HTTP.

In many ways you can look at react, vue, etc as javascript applications that use HTML/DOM to render. The problem is that they don't really see themselves like that, so the way they present stuff is sort of fucked up. And even after all these years the DOM handling stuff hasn't adjusted to the reality of web 2.0...because presumably the devs want to keep backward compatibility with hand-written css/html/js.

The DOM is another one of those hacky things that survived and thrived.

If browser makers, the standards people, framework makers, and web devs got together, they could theoretically simplify a lot of this shit going forwards, but they don't because it's too hard. Instead, we have these sort of layers of bullshit that live forever.


Two things:

- adding interactivity to a web page vs building an application. Those are not the same thing, and what you read applies to the first

- there's a widely accepted belief that vanilla js is not suitable for building apps. I don't buy into this belief. I have a built networked Scrabble game with vanilla js. Both the backend and the frontend. This simplicity allowed external contributors not well-versed in the modern web stack to contribute. I also was able to enter the code of Pianojacq (from jacquesm) [1] and contribute quite easily because he also chose vanilla js. This simplicity is very valuable, and lost with modern framework, and nobody is really concerned about this.

I've done some React development, so I know my way in a modern app. I've also contributed to a frontend written in Vue. I think they solve problems but bring complexity to the table, in particular the tooling (bundlers, minifiers, etc), the dependencies and the debugging being much harder.

It seems DOM manipulation through native browser API scares many people, but when it's what you are familiar with, your usual "framework", it's manageable. You need to be disciplined to avoid things getting messy (a discipline frameworks partially enforce), but I really believe you can go far with vanilla js.

I believe React & Co are often picked to ease beginners' contributions, but they actually do require expertise. I'd rather touch vanilla js code from a beginner or an experienced developer than a React code from a beginner.

It's a matter of taste. Vanilla JS has the taste of fresh air to me. It's zen. You write the code and it runs. No tools, no slow compilation, no minification that complicates the debugging. Minification which is only useful because with those frameworks you bundle an awful quantity of code in the first place. Yes, source maps exists but they don't do everything.

But today you won't have access to the whole ecosystem of existing React components with vanilla JS. It might be a curse or a benediction.

[1] https://gitlab.com/jmattheij/pianojacq


I don’t see anyone specifically talking about CSS, but that is something I still generally just write without any libraries or tools. I do use SASS at times because I like the nesting, but I don’t always bother.

In my 20 years working on the web I’ve found that a lot of styling libraries and tools like Bootstrap and Tailwind are great for getting off the ground quickly with a passable UI, and there are benefits for large teams to have a shared syntax and coding style that is well documented which these provide out of the box. But when it comes to overrides and general customization they can lead to people writing exotic selectors and using !important.

People often get frustrated with CSS, especially when the page loads and things start to interact. I’ve always found that less is more with styling and I’ve fixed more problems in my career by removing and simplifying style declarations.

CSS with variables, (and soon native nesting of selectors), animations, pseudo classes, and pseudo elements is quite powerful on its own. As long as there’s internal documentation for code styles and encapsulation of classes to components (even outside of a JS framework/library) its very scalable.


Interesting. I love using SCSS, and personally won't write CSS without it. It's also not just for nesting but also for variables, mixins, and extend functions. SCSS, to me, has made css become more of programming rather than just markup rules, allowing OOP prototypal concept via mixins.

Absolutely agree re: depending on Bootstrap. Unless you're heavily leveraged in BS (no pun intended) either cuz 1) you're at an "early" phase in your product or 2) you've bought into yet another framework and are stuck with it :), you should start creating your own scss mixins to encapsulate these components.

My personal fave is to use scss w/ bem. The naming conventions coupled with nesting selectors also help real well to create long class names without having to type it all at one time


These frameworks have emerged for historical reasons. There was a time when HTML/CSS/JS was much less capable and much more fiddly to use. Libraries and frameworks gradually evolved to both smooth the wrinkles and provide dev-workflow-oriented abstractions (components, etc.).

They do, of course, add their own wrinkles, but at the time of adoption ostensibly the juice is worth the squeeze--at least for whatever real-world challenge a given team (or the broader dev culture) is facing at the time.

---

I'll still use pure HTML/CSS/JS for client projects, depending on the context. Usually for static sites or interactive UI/UX prototypes, both in freelance and day-job (agency, bigcorp) contexts. So far, folks are very happy with the outcomes, but I do vet the fit first. :)

In other contexts like enterprise/SaaS apps, Shopify builds, etc. I won't insist on no-JS or avoiding React/SPAs, as much as I'd secretly like to, but I will advocate for self-hosting and minimizing 3P JS dependencies where we're not necessarily gaining a huge increase in capability in exchange for dev convenience, etc.

It's a balance.


There are two forms of "the web"

There is the document web - in which HTML/CSS/JS is more than sufficient.

Somewhere between Web 1.0 and Web 2.0 we started experimenting with delivering application experiences to a web browser - arguably an abuse of the document web. This is the application web and it is a distinct use case. HTML, CSS, and JS on their own provide a pretty poor application development experience. At the very least, building a full application in HTML/CSS/JS is non-trivial. Rewind 10 years and many of the tools we take for granted on the backend were missing from web development, notably composability and dependency management. Scaling UI work up to teams of dozens of engineers is difficult. Companies with multiple UIs have a hard time re-using code between those UIs.

Tools like React, Storybook, npm, and Webpack are addressing that gap. If you don't use them, given sufficient time and growth, you'll end up with your own patterns trying to address similar gaps in your code base.

Arguably the industry took a pretty windy and awkward path to "on-demand sandboxed applications delivered over the wire," but that's just what happens with incremental development I guess. We started with a web browser and the document web, abused it to deliver some interactive applications, found it was "good enough," and then pushed it as far as it could go. We ended up at a local optimum. There are likely other optimums out there.


Most of my side projects are written in plain HTML/CSS/JS. Of course, it's deemed "not acceptable" by current industry standards. But i work for myself, so i dont care.

https://github.com/altilunium/


Not acceptable if you would have 4-8 people working on it - where any of these people stay with company around 2-4 years on average.

Not acceptable if each person working for 2 years builds his own abstractions that new hires have to learn - but you make it easier by using framework and hiring devs for that framework.

Not acceptable if you would have 20 of such teams and you would have to have UI/UX standardized.


Very cool, thank you for sharing


I have enjoyed writing HTML/CSS/JS (vanilla) apps on my personal projects and use React for large apps at work. When my apps get large, it gets harder to manage, whereas when using React, each component is contained, so I don't have to worry so much about what's going on around it. That's not a good description, but it's easier to built on top of a large React project, than it is on a large vanilla project.

Frameworks also establish a common way of doing things like tracking state. For example, in vanilla projects, one developer might implement it in a unique way that no one else understands. You want to work with code that works well with multiple developers on larger projects.

It's still fun and interesting using vanilla for personal projects. I built a bunch of apps with just a CSS framework and JS was vanilla. (my apps: https://lewdev.github.io)


It's still here, just no longer profitable.

Frameworks are needed for web apps, especially single page applications (SPAs), if you just want to build traditional page/document based sites the traditional methods work just fine.

However SPAs is where the money's at for developers, so developers tend to abuse it due to resume-driven development (RDD) in order to get themselves into better paying positions/companies.

That's why tutorials and articles are all about frameworks now, just follow the money.


> resume-driven development (RDD) I love this phrase. Going to steal it. Thank you.


> I don't understand what problem they're trying to solve

Certainly, not building a website. MAYBE building certain kinds of apps, like a game or a paint app (see: most action is truly on the client-side).

---

I found a simple stack that is super-productive & efficient: https://tailwindcss.com + https://htmx.org.

This is, IMHO, the best way to do "normal" websites, even the ones some are tempted to get nuts with stuff like React (eCommerce, blogs, chat app,...).

The best is that it actually embrace the web as-is and not requiere anything to degrade correctly.


One thing to point out: "web," as a UI platform, is very weird compared to Windows/Mac/iOS/Android.

These frameworks bring in concepts that we take for granted in most other platforms.

More specifically: When I "do web," I prefer generating HTML on the server. Working with text that way is very simple, but the paradigm breaks down when the page needs to update itself from Javascript.

Javascript+html+css alone isn't nearly as powerful as the kind of UI tooling that I'm used to for Windows/Mac/iOS/Android. That's where the frameworks come in.

The reason why they change so much is that so far, no one's really come up with a good one. I personally think we'll get there if we can replace HTML, because that's the real obstacle. For representing a document; it's really cool, but for doing true UI, HTML just makes everything over complicated.


> I don't understand what problem they're trying to solve

I don't use React. I learned a little bit of Vue. I'm definitely not an expert, but I think there are (at least) two problems that they solve: consistency and reusability.

Consistency: I think the hope is that if you're a React programmer and you see a brand new site written in React, you'll understand it, whereas if it used vanilla JS, it might be written in any number of ways.

Reusability: if you start writing your own reusable functions in vanilla, you'll eventually build your own React -- it's the build vs. buy decision.


To build an application a framework was always a requirement. Developers either used an existing one or created their own. And I believe it is true for any application development, the code you see in tutorial or courses are not the same in a professional environment.

Same goes for HTML/CSS/JS, in fact, CSS and JS are the answer to the limitation of HTML and static page serving which was the vanilla www. As for your question, I don’t see HTML/CSS/JS going anywhere, they are the building blocks of web development and are written as such.


It's because you can't scale up without modularisation and component re-use. This applies to pretty much anything. You can find this 'problem' in other languages, markup methods etc. all the same, for the same reasons.


Okay, but can't you do that with HTML/CSS/JS? You can save collections of JavaScript functions, CSS class definitions, and HTML templates pretty easily. Re-using them is just a matter of copying them over to a new directory.


> Re-using them is just a matter of copying them over to a new directory.

And you lost me.

Is it possible to write reusable JS/CSS/HTML? Yes but the overhead is very frustrating and you will quickly find yourself building a custom framework to manage everything. Best to start with a framework from the start if you plan on having rich interactions. The speed at which I can move in VueJS is nothing short of amazing and the amount of reuse I get is extremely high, all without me having to manually manage a bunch of files/includes. With 1 TS import I can get all the HTML/CSS/JS for a component and safely use it in another component. At a minimum that would take 3 http calls in "vanillaJS" to fetch the html/css/js that I would need to maintain and update myself. SFC's are a game changer. Sure the browser might eventually support what I need but by that point I have no doubt that VueJS (or similar) will have lept further ahead.

It's the same reason I jumped on the 6to5/babel train early, it let me write my code in ES6 but still deploy to older browsers without waiting on everyone to upgrade.


Okay, so if I understand the main benefit is that you get to use a package manager and import statements? Also, don't you still need to manage tons of files, directories and config files in a React project? The React websites I've seen have way more complex directory structures than your average HTML/CSS/JS site.


I understand that at the start a pure HTmL/CSS/JS site appears easier (and to a large degree it is) but as soon as your project grows to a certain complexity the frameworks make life a million times easier. Also, once you’ve seen what the frameworks can do (handling the annoying stuff for you) it’s hard to go back even for simpler sites. Especially since we rarely know if a “simple site” is going to grow and need more functionality in the future at which point it would make sense to switch to a framework. Why not just start with the framework?

I’ve tried to go back to plain html/css/JS before and it’s a huge pain. I’m constantly thinking “ugh, this would be 2-3 lines of code in Vue but instead I have to manage all this stuff myself and it’s going to take 10’s of lines if not more. I’m not a fan of reinventing the wheel, also my skill set can be used everywhere if I write all my stuff in Vue instead of needing to context switch between smaller and larger projects (and again, small projects almost always grow so why not set them up for success?).


You could, but you'd be reinventing the wheel. You might start with some snippets you copy around, and every now and then you have to go back to all your previous projects to fix some change required in new browsers. So you might start using version numbers on your snippets you can figure out what you used when. But then you figure some HTML and CSS go really well together, so you try to put those snippets alongside each other and bundle them up. Your JavaScript probably needs to know which one of those HTML and CSS snippet bundles you are using, so you'll want to make sure that you specify which one you are using in your JavaScript.

At this point you're building a crappy version of a module and package manager, but all by yourself, nobody else is using your stuff, and you can't use their stuff either because it's not in your bespoke format.

All of the examples and concepts here are just inter-project related, but this applies within a project all the same.


You certainly can, and we did, with NodeBB. We use plain html, css, and js (with jquery) and a couple of bespoke components that work for our needs (templating engine, i18n, utils methods, etc.)

We call out to libraries when doing things that are better handled via a library.

Guess what, when you use a bespoke solution for common tasks, you end up with something that blows past every other competitor's benchmarks, without even trying.

e.g. take a look at Benchpress, our templating engine: https://github.com/benchpressjs/benchpressjs/


How do you keep said copied JavaScript functions, CSS class definitions, and HTML templates in sync?


And what happens when you want to modify one of those html templates?


It's only relatively recent that you could write vanilla HTML/CSS/JS & have it work. There were inconsistencies across browsers and browser versions. Frameworks like Jquery came about to paper over those inconsistencies.

It's similar for CSS with the added twist that it's a fair amount of work to get something non-hideous. Much better to start with something reasonably good looking and tweak from there.


They're the assembler of web dev, especially css. People move to the equivalent of higher level languages to escape the tedium of dealing with them.


The tedium? The tedium is with React et al.


Spoken like someone who has never built a non-trivial web application using vanilla JS or jQuery.


lololololol... babyface, you are groping in the dark.


I frankly think all front end is tedious to be honest. It doesn't matter what you use, it's fundamentally annoying to build in my opinion.


Security, scaling of development, and progression of language features.

The larger a code base gets, the more complex it can be, and frameworks help abstract ideas (like design systems), rather than having to repeat component code, css, each time it is needed. Also, if more developers are being added to the code base, the scaling of a project can get quite large. We have over 50 developers working at my company coding on the website.

Security is another. When updating a list of items (for example) from a fetch, vanilla js will require direct modification of the html, whereas a framework like React will handle that, with best security practices applied, as the code has been written and production tested.

I'm not going to deep dive on language features, can be quite subjective, for example how great Typescript is (compiler errors > runtime errors), or how SASS fills in a lot of missing features for CSS, etc.

I think some websites could be done in vanilla JS/HTML/CSS, but as the site scales, I feel at some point a developer would build their own framework to make things easier and streamlined. It's what developers do.


FWIW, I chose to make my side project I've been working on for the last couple years an entirely vanilla js SPA. The biggest downside I've noticed vs using something like React is my speed of development is much slower. The upside though is the code itself is extremely efficient / packages sizes are small.

For my own project this is great - I have no deadlines, and half of the process is me just enjoying writing the code. For an existing company the demands are different. Not only are there time pressures, but aligning on something like React means you're introducing convention into the code. Hiring people who already know this convention is easy.

Vanilla js, even with webcomponents, just isn't quite there as far as convention and speed go, and there isn't a rich community around it. Is it perfectly able to do the task at hand? Absolutely, but at a price most companies aren't willing to pay. React is the easier of the two.


How are you going to manage interantionalization, testing, sessions, etc. with just these tools?

(In before people say, "but that's all I need for my blog!" Fine. go ahead and do that then. I'm talking about international huge scale applications)

What you'll do if you stay the purist and need to implement aformentioned services is that you'll eventually end up with some sort of quasi-framework, but bad in the sense that only you (or perhaps your team) know how it 'works'. With most frameworks there are at least opinionated ways to go about implementing all these things, and you can find other teams and consultants who speak this 'language' so to speak.

Being a purist is fine, but it really grinds my gears when people assume vanilla is ALWAYS the solution, and it can 'easily' be applied to things like e commerce shops, huge shared tools, or big social apps. Hint: it can't, unless you like a lot of pain.


It's still there: http://vanilla-js.com/


People love getting themselves tangled in convoluted frameworks.

---

We are building SyncHTML.io to counter that.

Try at https://sy.ht (press up/down arrows)

See how we set ourselves apart https://efn.kr/b/sync#new-playground

---

Web standards are unbeatable when used right.

They are not used right most of the time.

---

See 2 custom elements done right™: (The /?s at the end is significant!)

1. zero-md: https://md.sy.ht/?s (just press up/down arrow keys)

2. WebPDF.pro: https://pdf.sy.ht (view); https://pdf.sy.ht/?s (edit)

(The WebPDF.pro elements are served from an unoptimized server. Takes a few seconds to load.)


I tried these links and couldn't figure out what's going on.

When I go to https://sy.ht, I see a clock animation on the right and a blank editor on the left. I tried arrow keys and nothing happened.

Got ERR_CONNECTION_RESET from https://efn.kr/b/sync#new-playground

What are you sharing? Is this a codepen-like thing?


Oh, thank you for reporting! Might have temporarily hit a limit (https://deno.com/deploy/docs/pricing-and-limits) with the link shorteners.

This is what I am sharing: https://sy.ht/yt (YouTube video showing what this is about.)


Remember that once upon a time, there were options outside of Javascript for high interactivity, most prominently Flash. At the time there was no need for Javascript to be more complex. So harkening back to a "golden age" when Javascript was simple is only telling half of the story.


The same reason frameworks are popular in any language: convention over configuration.

In a native lang there is are near infinite choices to make in implementing a solution and no two developer’s native code typically looks the same. Jumping into a vanilla JS codebase can sometimes take more time because you have to discover and understand the choices the developer made. The code is highly configurable but lacks a common convention.

With a framework, some of those choices have been made for you. So, jumping into a framework codebase is sometimes easier and simpler for those that understand the framework. The code adheres to a public convention at the expense of being less configurable.


JS development in particular is relatively verbose, so folks started writing little helper libraries to get things done faster.

Folks open-sourced their libraries, others contributed, and we eventually wound up with frameworks.


I think there’s a core difference between helper libraries and frameworks like React. JQuery is a helper library, but the purpose of React etc are more to manage state, improve efficiency, and pave over security and browser inconsistency issues more than they are to reduce lines of code.


I'd say that most of the websites still use HTML/CSS/JS and are server-side rendered - well, at least 40%+ of the web does (WordPress).

The distinction mainly is in the apps. Yes, web apps almost always use a framework like React now. Others have already explained the whys.

However, it's still possible to do webapps the traditional way, with the server-side approach, adding only a little interactivity via JS - techs like LiveView and HotWire: https://hotwired.dev/


There's a few parts to it.

javascript used to be awful. Using JQuery was more or less required to have a decent API and not have your entire app full of polyfills. Those days are behind us, but the precedent remains.

Some javascript APIs are still pretty bad. Fetch and XMLHttpRequest are both really warty in their own ways, to the point where you're probably writing a wrapper function. Common-enough collection operations are missing, you'll need to write some sort of utils file. So you're definitely going to want at least some sort of small library for the missing stuff.

The DOM forms a parallel, persistent tree to your application state, and you need to manage the relationship between that and your app. Parallel state trees just always suck (I've also dealt with them in Box2D, some game engines, SVG renderers...), it's probably an antipattern. It's not that big of a deal for a small app, but for larger ones it starts getting hairy. And it certainly feels like you should be able to write a better API easily enough, but because the problem is that the entire DOM is based on a parallel state tree model, your wrapper library ends up getting large before you know it.

There are good technical reasons to use some sort of build system for your web content. Concatenating and minifying all your javascript helps a ton. But to do a really good job of minifying you basically need a whole compiler, and at that point you might start pulling in all sorts of clever transformations that seem like a good idea.


> Parallel state trees just always suck (I've also dealt with them in Box2D, some game engines, SVG renderers...), it's probably an antipattern.

Just to reinforce this ... this is the case even with native desktop GUI toolkits. Take the example of GTK. You build a model for a tree/list view using the "nice" data types GTK provides. In Gtkmm (the C++ bindings) it's even easier and actually feels very idiomatic.

However, if you already have a model data structure somewhere in your code for other reasons (for example, your "backend" code isn't allowed to use GUI toolkit objects or APIs), you now have parallel state trees, and they suck just as much here as anywhere else.


I like to build things in ways where I try and avoid the use of JavaScript if I can, using vanilla typescript for most things that do need that. I really like seeing what is possible in pure CSS for stuff like animations if I can completely avoid doing it in JS/TS while still looking fresh. The component based frameworks make a ton of sense for when your project gets large and worked on by a ton of people though. Personally for most small things I don't think you need them, and a lot of more novice developers really rely on ridiculously fat npm packages which impact site performance - often what I end up doing is finding alternatives in that ecosystem which are smaller and more well written, it's not all hot garbage but a ton of it is unnecessary bloat. Most of these frameworks are very similar and easy to adapt to once you have learned one or two of them but they definitely can lead to a website that weighs like 5 megabytes for no reason.

I once inherited a project where the front end was split between like +20 different react projects across that many git repos which we really had to twist the arm of the original developer to get access to. That's definitely an example of doing it wrong.


> I don't understand what problem they're trying to solve

Building highly stateful / interactive web apps. If your web app is sufficiently complex enough then your vanilla js solution will just become an undocumented framework in disguise. When you build a homegrown system that manages components and their lifecycles (reacting to state changes) then you've written a framework that no one else has experience or knowledge of.

> What makes the trade-off of all that extra complexity and abstraction worth it?

Interactive UI's that react to state changes are hard to manually manage as complexity increases. Your UI and state are connected by an undocumented large state machine. These frameworks essentially allow you to define how your state, in any shape it may take, should be reflected in the UI (DOM).

> Aren't HTML/CSS/JS perfectly fine and time-tested tools for web development on their own?

Sure, but all of the frameworks are written in JS and you write plain JS to use them. You might use something like JSX or TypeScript for convenience, but these are turned into plain JS. They're also not required, they've just become standard because of how convenient they are.


I kind of sought to answer this for myself in a roundabout way. My first experience with web dev was React. I never learned "why" so on a recent personal project I figured I'd start from the ground-up.

First I wrote a little 'RTS' game in Javascript where the player writes code for the units in game and runs the code in the browser. But the player/programmer needs more info about the game's state. Which means I need dynamic html components to display the changing state of the game. Easy enough, I used a lightweight library called slim-js to give me the functionality I needed minus the ugly boilerplate of the Shadow Dom. But now my dynamic components were re-rendering every single frame, since they were tied to a callback that was triggered when the game re-rendered. Ok, I'll just save the state of the game into a map and only update when there's a missing value or a new value. But all of this state management and custom component logic is overhead that makes the page harder to maintain.

I also wanted to use typescript to make sure I was passing the right values back and forth, which means transpiling every time I make a change. I also need to serve the index.html with a webserver, so I can import ES modules. Http-server works well enough for this, but what if I want to add another page to my site for watching tournaments run on the backend?

It was a nice exercise to learn /why/ frameworks like React exist. Moving forward I'm definitely going to move to a React-based page since I'm already starting to outgrow my vanilla-ish stack.

Here's the game if you'd like to check it out: https://ai-arena.com/


This isn't a one-or-the-other situation. A web developer should and would choose the right path depending on the scope of the website. Mainly, is it a web page or a web app? If it's a landing page or even a blog, i'd say vanilla HTML/CSS/JS is just fine. It's when you get to data manipulation, state manipulation, and user interaction that React is very helpful...

Same with BackboneJS and Angulars of the past, and if society has taught us anything, it's that there always be a NEW and IMPROVED one-framework-to-rule-all the other frameworks.

Also, the state of JS in browsers are way more "consistent" than the IE wild west of the 90's and 00's, which was why jQuery was so popular. And that began our dependency on plugins to provide consistent dev codebase in between browsers. So if you REALLY think about it, it's the browser vendors' fault for why "vanilla" HTML/CSS/JS seems to have so much tooling.

In the end...figure out what you're trying to build, and know that if it gets too complicated in straight up HTML/CSS/JS, there's plenty of frameworks to help you organized.


I still write static sites which are hand-coded in HTML and CSS augmented by a (very little) javascript. They're quick to build and easy to deploy and, for some clients, they're all that's needed.

I've used frameworks for twelve years, and covered most of them across various projects. I particularly like the direction of recent frameworks like Svelte and Vue3.


Yes, they are. This is why I built Joystick [1] to take a lot of the valuable concepts of modern web development frameworks and make them work with pure HTML, CSS, and JavaScript without any hacks, syntax tricks, etc.

[1] https://github.com/cheatcode/joystick


The problems that technologies like React, Typescript, NPM, etc. solve are mostly only relevant to startups and corporations needing to write business logic and correlate complex projects between teams. The point of front-end frameworks, for instance, is to reduce the roundtrip cost of requests and server-side code by compiling and rendering as much of the site as possible within the browser - an optimization that doesn't matter for most people, but matters when you're "web scale."

Unfortunately, because the web is serious business, all of that complexity became the standard for the entire ecosystem.

Just using HTML/CSS/JS is considered either regressive or niche. It's called "vanilla js" which only shows how utterly locked in to the enterprise paradigm javascript has become, when what should be the default needs its own genre identifier to differentiate it from "the norm."


Interesting point that "vanilla js" is kind of judgemental, or at least framework-centric. Maybe we should start saying "pure js", or "sparkling, refreshing, clean js", or whatever companies that sell bottled water call it.


A bunch of people started overcomplicating things in order to impress their peers so they will hire them to BigShinyCorp Inc. Things went on for 15 years and ended up with an abomination in which everything has 53 levels of virtual machines behind it. Because i guess virtual machiens are fun.

Yes they are perfectly fine, dont waste your time


Where these basic technologies really start to fall down is when your pages become increasingly dynamic. You start running into an issue where you have to define your structure multiple times: once in HTML, and at least once in JS since that's where you're dynamically updating things.


Depending on what you want to build and how many people will contribute, the answer might vary. HTML/CSS/JS can be enough, but mostly you will need to handle streamlining browser differences etc. explicitly. Frameworks are popular because they can help to streamline these issues. Also there is mostly an eco-system built around these frameworks, so you don't have to build every component from scratch for example. From a business perspective it's easier to say we're hiring for this specific framework (React, Vue etc). vs. we have our own rules and styles. Finally these frameworks also have a social function. It's like a style or taste preference, where a group shares the same preferences.


Some of the better ones do most of the thinking for you in a clever and minimal way and seem to reset the status quo of giant dependency trees that take a long time to install and update and deploy (relatively to your scenario). deno fresh for example is a reset coupled with deno deploy. Its better to not have to worry about manually updating the dom and think of updating state instead just like updating a variable ideally. As long as it gets out of your way and speeds up results, it is a win IMO. It gets even better when its a super fast deployment baked in. Not fun to FTP as I remember long time back. FYI coming from simple user-land and I do think things are getting better when those resets happen, not worse.


I am a solo dev.

I wrote a complete warehouse management system. I wouldn't be able to accomplish this in a relatively short time frame without help of frameworks and libraries. Instead of using vanilla SQL queries I used LINQ. For UI, I used bootstrap, because it made it easy to handle desktop/mobile. For async calls I used old jquery because it worked well enough with .NET and was well documented. Additionally .NET allowed to scaffold models and identity.

I can write a site in JS/HTML/CSS, however, why? I would rather do things quickly with proven frameworks. Size of websites is less of an issues these days. There may be use cases for going pure vanilla but often not the case from a business perspective.


IIRC the email client https://www.hey.com/ and other 37signals projects use vanilla js.

I did use Typescript without a framework to implement this ios calculator clone (https://getcalculator.app/) and it was not a bad experience at all.

I wrote about it here (https://mejuto.co/the-ipad-did-not-have-a-calculator-so-i-po...)


I've always really preferred keeping it simple with HTML/CSS/JS and find most front-end frameworks to be a huge turn-off. You might like Astro (https://astro.build). I love that my sites are still 100% HTML/CSS/JS that I wrote myself. But Astro comes with Sass and Typescript support out-of-the-box (no Webpack necessary), and also makes it easy to do reusable components, scoped styles, supports FE frameworks if you want them, etc. It's the happiest medium I've found yet. :)


Cool, thanks for sharing!


> What makes the trade-off of all that extra complexity and abstraction worth it?

For most applications the extra complexity is not worth it. React started off as a simple library but now it has bloated with Redux and ReactRouter and Hooks and all that nonsense.

You can do plain HTML/CSS/JS development for most projects. Here's an example: https://github.com/wisercoder/eureka It uses a couple of 500-line libs, that's it. No complicated framework, and yet you will be more productive.


For small sites, I always reach for vanilla rather than a framework. For example, [a super simple QR Code website][1] I made uses less than 100 lines of JS (minus the QR code library of course :)), plus regular HTML and CSS.

Anything larger, however, and using a library just makes things easier: HTML partials and helpers, nesting in Sass, and data flow and component composition in JS frameworks are just easier when a project is large enough.

[1]: https://github.com/romellem/easyqr-codes


Disclaimer: I'm the author of one of the frameworks mentioned in this thread.

Yes, HTML/CSS/JS are perfectly fine tools for web development. But just like it's not as efficient to use a hammer as a nail gun, using HTML/CSS/JS alone might not be the best choice if you're trying to build something highly interactive or if you have other concerns (e.g. a very large team that consistently steps on each others' toes on accident).

I'd encourage that you try to actually take HTML/CSS/JS as far as you can take them, if nothing else to experience the pain points of using them at high levels of complexity yourself. This can give you an appreciation for why frameworks do things the way they do. For example, routers are patterns that every framework dealing w/ parameterized pages eventually lands on because it's a pattern that makes it easier to manage page parameterization.

It can be argued that some frameworks land on seemingly strange or overly complicated APIs sometimes, but that's just the realities of engineering. We try to make the best decisions with the known information at the time, and then we have to consider maintenance costs after the fact. Nobody is perfect and sometimes we only see flaws in an approach through hindsight. There's also such a thing as using the wrong tool for the job. Frameworks usually have scope and an idiomatic way of being used. These indicates which use cases the frameworks are strong for, and which aren't.

Most self-respecting frameworks will have some sort of tutorial that you can follow to get a feel for what type of tasks they are trying to optimize for. Try them out to see if that's what you need. If it's not, that's ok, there are plenty of other tools that could fit the bill better. My recommendation would be to try different "categories" of frameworks. For example, React/Vue/Svelte are very similar in scope, so trying one should give you an idea of what all three are more or less all about. You could try htmx, or GWT or even jQuery to experience completely different flavors of "framework-ness", maybe one of those will "click" better. Maybe you'll find that vanilla HTML/CSS/JS is all you need after all, and that's ok too.


GUIs lend themselves well to component-based (a.k.a. Object-Oriented Programming-based) approaches. The earliest GUIs used OO techniques. And JavaScript has VERY weak OO functionality. Or rather, the browser has very weak OO functionality. Everything is global. Any piece of code can just modify elements in the DOM as they wish. There's no modularity or namespacing. When building a big, complex, interactive GUI, it's a lot of work trying to use a homegrown approach. Better to just use what has risen to the top - React,etc.


I notice that the distribution is heavily skewed where the HTML/CSS/JS camp is using it for their blog or 1-person project and has been doing it like this for a decade, where the React/framework camp are the people who have done both and are working on large projects.

The basics of React are learned by 1-month novice programmers in 2022. You don't even need a build system (which is even setup for you with Next or create-react-app). At it's core, it's just a file which contains "super"-html that you can update state more easily.


Great question. I'm short on time (and using my phone to comment) but TLDR, there's a spectrum from

(A) "SPA by default" and piling on layers of abstractions

to

(B) properly leveraging the web as a platform, and mentoring the browser instead of micromanaging it

...and the trend is finally starting to move (back) towards (B).

There's also a significant role played by the "document-based web" vs "web applications" paradigms' semi-dichotomy.

You'll see plenty of (frankly sophomoric) takes like "webdevs are rediscovering that server-rendering HTML is a good idea, LOL, sounds like PHP or my cgi-bin Perl scripts from 1999" -- which ignore the need for client-side interactivity and responsiveness and the profound changes in the capabilities of clients, networks, servers, languages, and tooling over the intervening years.

I highly recommend a close look at https://Remix.run and https://every-layout.dev (and probably https://Astro.build) for examples of frameworks and techniques that thoughtfully leverage the best of what's new as it continues to evolve, while being firmly grounded in from-first-principles foundations that enable creation of magic comprised of sane primitives.

I've been building and improving web-related sites and apps for a living since 1998, and without reservation urge anyone involved in webdev to read up on both Remix and EL's "axiomatic CSS". They provide a profoundly well-informed and -reasoned perspective that answer your question and help show the way forward amid all the froth and churn and nonsense. It's the signal in the noise.


Every non-trivial web application that starts of writing "vanilla" code will eventually evolve into something resembling React, Angular, Vue or whatever else, just with a lot less thought and resourcing put into it. So unless you truly want to build a mostly static web page with HTML content and minor styling it makes sense to just start off with one of them and prevent a painful migration down the line when your dev velocity has slowed down to a crawl because of the complexities of the codebase.


Yeah, things got messy, laggy and sad. Because there are no longer "sites" - there are "apps". Because why spend money on expensive servers while we can run JS garbage on client side? Because why our corp has this boring page? We need something more splashy-flashy than our rivals have! Because why keep old bugged codebase? Let's write a framework! Because can I haz animated website with no skillz? I heard I only need a few clicks with some "frameworks"...


"Papa, which web framework should I learn?"

"Child, you know your mad uncle Joe who lives up at the big asylum?"

"Yes Papa"

"Well stay the fuck away from frontend web development"


I recently started two small web projects (one personal, one work) using ViteJs, Html, Vanilla Typescript, CSS, and a .Net Core Web API. It has been a great dev experience compared to React and Angular, IMHO. Of course I have this sense of guilt that I should be using a framework. And if these web apps were to suddenly explode with unexpected screens and features, then it would get complex. But right now, it is a fast and pleasurable development experience.


In my experience, just having the ability to "modularize" the common elements on pages of a site (navbar and footer, for example) is the biggest task for most simple websites. There are lots of frameworks out there that do this, at the expense of making everything else on the website "html with extra steps". React comes close to solving this, but there's not a "react lite" that does it more elegantly that I know of.


I think the reality that there's little (to none at all) job posting which would only require application development in vanilla CSS/JS/HTML is the main reason why frameworks dominate the land.

While I see the value of using vanilla stuff, the complexity of software requirements, ever evolving browser APIs and features and increasing ease of using libraries (i.e. date-fns, lodash, etc.) has definitely increased the appeal of frameworks.


I’ve seen some complex vanilla js uis back in the days.

They all ended up building some framework similar to react or angular. There is no other way to manage the growing complexity than to invent some “engine” and a set of rules.

So your question has the answer in itself. There is no “or”.

React _is_ HTML/CSS/JS, but organized for complex projects. And definitely not for any project.

I bet most of “js justice” warrior have never got their hands deep in really big uis


Grug develop doctor's appointment website, grug use jQuery + Flask/Django.

Grug try develop Notion or Google Sheets competitor, grug use React/Vue framework.


It’s hard not to read many of these comments as “Old man yells at cloud.”

I’ve been lucky enough to experience development across many different types of systems over my 20-year career, and web development has come a long long way to the point that Vanilla development is viable.

Generally speaking, I prefer to spend my time solving problems, not reinventing the wheel with boilerplate. Using a framework like react aids me in that goal.


They are not fine. Your css styles are tightly coupled with html elements. Your js is tightly coupled with html elements. So why keep all html elements, css and js together and separate from each other?

Components provide a better primitive by combining related css, html and js together as one unit.

This is not supported by native browsers, hence custom frameworks are necessary and better


When you went through the Odin Project, did you do all the modules? Asking because there's a huge chapter on React that the vanilla JS course helps prepare you for. (To answer your question though - HTML, CSS, and JS are absolutely valid ways to go on a simple website that doesn't require a lot of interactivity. You use the tools you have in situations that benefit from them)


IMO for things like static sites, or sites that only have some landing pages and a bit limited interactivity behind a login portal, vanilla HTML/CSS/JS is perfectly fine.

The complexity of vanilla gets out of hand when developing web applications (websites that feature menus and tools and widgets and state that the user interacts with - think JIRA or Gmail or Google Docs, etc)


They are being used. Its just that frontend is a moshpit. Everyone wants more overhead and complexity, mostly to justify the high salaries.


Nobody wants more overhead or complexity. Users expect complicated features as a baseline experience.


Ofcourse. It's the users fault.


It's easy, I think, to forget how bad the basic HTML / CSS / JS behavior is from a modern aesthetics standpoint.

So I'm currently maintaining a totally static blog I build in Hugo. It's almost nothing but plaintext, one static CSS file, and some images. One time in a hundred, when I select a new story, the lightly-shaded background of the page blanks through white because loading a couple resources takes too long.

For my personal blog, for fun? That's fine. For most corporate sites? Unacceptable. Looks unprofessional. This is 2022; we're not using teletypes and command-lines anymore where the user can feel the individual bytes coming over the wire.

So to prevent just that one visual hiccup, I'd need to do dynamic fetching of page content and a hollow-and-replace of the content div instead of reloading the entire page when the user navigates around, but I also need to support direct navigation to the page loading the full page content, and I need to do this all correctly from Google et. al's point of view so search crawling doesn't break. And at that point? I'm definitely using a framework (probably with both client and server-side components). All because the aesthetic of the end-user has evolved and your page looks unprofessional if it navigates like a traditional '90s-era page.


> It's almost nothing but plaintext, one static CSS file, and some images. One time in a hundred, when I select a new story, the lightly-shaded background of the page blanks through white because loading a couple resources takes too long.

That doesn't sound right to me. Why isn't the "one static CSS file" cached? It should load instantly because it's already in your browser and doesn't need to fetch anything. I've created/maintained static sites as well and I've never run into this visual hiccup you are describing.


Excellent point. Upon further investigation, I suspect what I was seeing was that Chrome with the Inspector open was evicting cache aggressively. Closed it up and no longer saw this issue. Definitely worth remembering for the future that the render loop is more complicated than I assumed!


> For most corporate sites? Unacceptable.

im not nessecarily disputing this, but if so, they clearly are stupid, given all the crap they will put up with


You're underestimating how much money corporations have to throw at problems, as well as the fact that they compete on look-and-feel with other corporations willing to do the same.

At their scale, the cost is worth it; it's just business.


and yet they tolerate total pieces of garbage that loads a gazillion scripts taking an eternity


The real meta-question here is why does everyone want to write SPAs in the first place?

This is an era of ubiquitous 100mbps+ connections, CDNs, and edge-computing-two-hops-from-the-customer hosting. The whole reason we invented SPAs (bandwidth savings and latency) predicated on AJAX has been obviated.

We can return to serverside HTML/CSS and forms with no loss of UI quality.


Frameworks solve for architecture.

When a choice is made to use a framework the choice declares the stakeholder(s) trust the framework to provide a better architecture than the assigned developers. How prolific a given group of frameworks become understates how little faith the decision makers have in developers to write an acceptable solution.


I think that most JS developers don't have experience writing code without React, so they just use tools they know.


The HTML/CSS/JS platform offered by modern browsers is very powerful and approachable, but the web's security model prevents most platform customizations. Browser-managed navigation, form submission, control appearance, etc, is largely a take-it-or-leave-it proposition.

JS frameworks allow front-end developers to get around this limitation by rebuilding parts of the platform as a JavaScript application. For example, if you want to customize how navigation works on your page, you can either use the few, limited hooks offered by the browser (e.g., registering window.onunload callbacks), or you can make navigation an application concern by writing your site as a single-page app. There are plenty of things you just can't do with a framework-less multipage site (like animate transitions between pages) that are possible once you make navigation an application rather than platform concern.

I can understand why many enterprise teams choose to use front-end frameworks like React even when it would arguably be faster and easier to just use vanilla JS, as there's a risk someone may need to add functionality that is not supported by the native web platform. For personal projects, though, I use vanilla JS and HTML.


Self promoting plug:

It still works fairly well on the relatively small scale if you just want to write a frontend app (i.e. simulations):

https://aperocky.com/cellular-automata

https://prehistoric.tech


Wow that cellular automata sandbox is almost identical to something I wrote a while back! You might find this article interesting for running arbitrary code in a browser sandbox:

https://blog.risingstack.com/writing-a-javascript-framework-...


I want to add, I like typescript, I think React is okay. What I hate is the build steps.

I tried create-react-app and it's basically on mimimal support, updates broke stuff, outdated deps, devs unresponsive, ...

What is the simplest, least likely to break, minimal dependency, live update tool chain for typescript, and or typescript + react?


I always love vanilla HTML/CSS/JavaScript, here's a site I made recently, using Vite as the development tool, and SCSS as the preprocessor, no JavaScript involved. https://cht-colors.pages.dev/


I have a half-serious way to fix symptom here: everyone gets into javascript is required to implement their own `ui=f(state)` framework, maximum size is 10kB minified.

80% of them will be amazed how easy it is. I bet 20% of those implementation each would cover 80% of application use case today.


I actually have to disagree a little bit... The rise of static site generators have filled a void there of where you can have reuse but you don't need to head off into framework land. I do a lot of projects now (using SSGs) where most of the work is plain jane html/css/js


Still going strong, I do it exclusively every day, maybe with a little splash of jQuery when needed!


Every time I've started a new vanilla project, it's not long before I figure out I need a lot of stuff that's already been done better in a framework. It's usually about the time I start writing a helper function to build up dynamic DOM elements.


This. Also, these frameworks increase our productivity significantly


They make everything faster to develop and maintain. Same reason you'd use a framework for anything in any other language. When was the last time you saw a web server implemented with a HTTP-parsing library, instead of a framework for defining endpoints?


> When was the last time you saw a web server implemented with a HTTP-parsing library, instead of a framework for defining endpoints?

This is not unheard of in languages that have an HTTP server and router built into the standard library (Go is the most prominent example here, but I've seen many node.js web services written w/o 3P frameworks). You could argue that the stdlib functionality is a framework, just not one that you need to install, but the same could be said of vanilla HTML/CSS/JS.


Go's vanilla HTTP server lib gets pretty close to being not much more than an HTTP parsing library. Some people pull in a routing library, but a lot of times its all done manually by processing off the incoming http.Request struct.


I built my multiplayer web client with vanilla: http://fuse.rupy.se

There is nothing like being on the lowest common denominator, but you can understand why browsers are not evolving past this point.


I blame Facebook/Twitter/Social for this.

With their rise in mid 2000s, having a framework with which you could manipulate the entire dom real-time to reflect the state in the backend have been accepted as obligatory.

Whereas in reality, aside from the neat templating that frameworks like React bring to the frontend, there is absolutely no need for the majority of web applications to be able to send micro updates to the client like how it is obligatory for social networks or other apps that are heavy in user interaction.

The least thing that you would want to do when a user is going through an ecommerce checkout process is to manipulate the dom and change stuff that could distract the user from the checkout process, for example. If you need to update some info with the changing quantities in the cart or address, that could as well be done with simpler stuff like jQuery - considering that your site does not have such features that will cause your jQuery to bloat.

There is even less need in the majority of the web where only content is consumed - how much interactivity do you need for a news article at the guardian or even your local-news blog? The user will just want to read the article. He or she may not even bother to comment (and likely wont), and when they comment, you definitely don't need a full fledged framework manipulating the dom to post and refresh the comments section. HTML and the browser already sort that out.

...

The overall idea is sound, yes. A better form of presenting and manipulating the dom is a good thing. But, the bloated frameworks and the dependency hell that we created for ourselves do not look like the way to do it.


Abstraction. If you use HTML/CSS/JS to solve some problem there is a high chance you are reinventing some package that's freely available via npm or Yarn. Even a leaky abstraction can be better than reinventing the wheel.


The web is now a virtual machine combined with a content delivery service and “web dev” companies are actually just building software that runs on it. If this were 1994 all of these companies would be shipping disks in boxes instead.


It still exists and it is the best form of website. The UK National Health System (NHS) use it extensively for their health infrastructure and it supports all devices intrinsically. This was a huge boon during the earlier pandemic where many other government websites were having to roll back their advanced features and re-enable older protocols to cover all citizens.

Corporations generally can ignore the majority of people and only concentrate on their target market. If their target market can be coerced into using SPA and other application based weapon design then that's easier and cheaper for teams of paid developers to do. If only because most modern web devs are trained to make such JS applications.

But everyone else, individual humans, institutions, governments, they should try to make their websites accessible to all. It's a shame that few are.


Why do you think JS frameworks can't be used to create accessible websites?


There's this assumption by for profit business that all people will have modern software with modern JS support. They're wrong and the tools they use to measure such things are implemented in a way they won't ever know they're wrong. What JS is in terms of what features are used to write those frontends changes far faster than the software that resides on a great many people's computers.


You have to somehow employ more people and slow down corporate growth, so React was introduced, plus google idiocies like WEB VITALS... oh my friggin god, web development went full retard mode in the last 5 years.


Web vitals were created specifically to address the user experience issues often caused by slow JS websites: things jumping around as they are loading, things being unresponsive until some script initializes, etc. Using these metrics for search placement now incentivizes website owners to take them seriously and fix them.


No, it's a layer to obfuscate things even further. It's a pseudo kinda job, bullshit job for future gen ppl. Even the simple pagespeed value was not respected by any Goog product, so why pushing it as a metric?


I use vanilla html/css/js exclusively. I made some helper functions to manipulate DOM. I do everything manually, including saving state. And it works just fine. I find React and others confusing.


Pure HTML/CSS/Js either devolves into spaguetti code very fast, or requires you to put very hard conventions to avoid it.

Component Frameworks give you more structure that organize the projects in more sane ways.


People still write vanilla HTML/CSS/JS.

Maybe it just "seems" like they don't because so many people post about using web frameworks, and nobody posts about not using frameworks?


If you develop any decent sized application with vanillaJS you will end up at some point building your own framework. The chances of it being as good as React are almost 0.


I worked on a "web app" in the early 2010s, 10k lines of vanilla JS and jQuery, and it was a nightmare.

Adding basic features or fixing the many bugs we discovered every day took hours or days. Any refactoring took weeks. We had to invent new abstractions on top of existing abstractions to keep everything more or less understandable and maintainable. Just splitting the code into different files (like to achieve some sort of frontend MVC and avoiding to have 5k lines of code in a single file...) and loading everything in the correct order was a puzzle. Making or changing any kind of edit forms was a real challenge too and prone to just adding new bugs to the list. Between loading all the data in AJAX, adding an id to each input and filling every input one by one with jQuery by copy/pasting their ids from the HTML, generating the selects and selecting the correct option(s) and adding them to the DOM, dealing with all the buggy jQuery modules like date and time pickers and their own ways to initialize and return data, showing or hiding parts of the form depending of the selected options, extracting the new values one by one from the DOM with jQuery once the user submits the form, validating the data and toggling the classes of the inputs to "error" with jQuery and adding error messages at the correct spots inside the DOM, revalidating the data and formatting it and sending it to the backend, refetching the values just to be sure everything is in sync and updating the values inside the DOM again with jQuery by copy/pasting ids and classes from the HTML... We take all this stuff for granted nowadays because the frameworks do it for us but it was so artisanal back then.

Eventually I pushed to rewrite the app when Backbone.js came up, and we started using tools like grunt, and it was already a huge step forward. Then some years later we migrated to Angular 1, it was another big win in productivity. Eventually React came out and I started experimenting with it and I thought it was revolutionary. Its component paradigm allows to break the app into small manageable and reusable pieces and this makes everything simpler. And then Microsoft released TypeScript and now we have code safety and autocompletion on everything, including external packages. And we also have JS export/imports, fetch, async/await and so on... And tools to test all the logic and interactivity in our apps.

Nowadays frontend development is just so much easier than before. I can't believe that people who think the opposite have actually worked on any sort of real life big frontend projects in an enterprise environment (1 or several teams working on the same codebase, new non-trivial features to implement every day).


TL;DR - People started using their mobile devices not just for apps, and not just to view static pages, but to spend money. They started expecting websites to behave like apps started spending money on websites that behaved like apps.

We have frameworks instead of static HTML because it is really complicated to make a website behave like an app and it takes a LOT of javascript. We started out with jQuery ajax calls and media queries. We moved on to AngularJS to start swapping content in the page in larger chunks and maintain state and code better. We've now moved most/all of the site functionality into Javascript via React to better manage caching and state of the application for the best performance and more manageable code.


This actually makes a lot of sense, thank you


What is the easiest way for someone with HTML, CSS, and Ruby programming skills to add JS interactivity to a site? Would that be something like HTMX?


I agree with your perspective on separation of concerns as that was the intent of the html5 standard.

The reason react was invented was to enable real time update of items on the page -- to update when someone liked your item, or send you a notification update instantly instead of polling the server.

It was the idea of pushing code to the webpage. So they made a component in javascript that updates in realtime -- the state or prop determining the content or how many likes the post had. However this ended up requiring a huge Redis instance which is also very expensive, so now they need to sell more ads. In order to figure this out they realize emojis on the like button allow people to choose a sentiment of their reaction to the content. Their ML uses the sentiment to group and sandwich ads between content the ML knows or thinks you will react favorably.

So for example, a comedy central ad will be shown after a meme or story that is similar or something you reacted Haha to because the advertiser's desired reaction is a Haha as well.

Thus the name React. Plus it makes that div/element/part of the page defined as a "component" in js that will update or "react" in realtime -- anytime they push an update to the server everyone viewing that page sees it change in realtime.

Essentially a combination of a push notification or pubsub and ajax request.

Honestly, when jsx goes out of style like it should because its idiotic, and gross, and a violation of those separations of concerns, it could just be an html page where you write a js function to add a realtime update to an id or class...

Svelte uses that style of approach to the DOM.

If you don't have a realtime data store like Redis or any type of realtime data streaming going on, React or any other component based framework is a waste of time.

The ability to update the page without reloading or building as a single page app is not SEO friendly unless you use SSR which you already would have created in your normal seo friendly html files.

also name your files consistently and clearly.

unless you need to change the page in realtime without reloading, react and these other component frameworks have no use case.

If you want a clean css3 framework to help build a web front end that works neatly in html5 check out Bulma.

Bulma.io

You are exactly right, the js developer scene is like a herd and people wanted to work at facebook or look smart so they learned it.

It's useful for making single page applications, however all framework interactivity can be written in normal js, so if you take your time you'll have much cleaner, unbloated code, yielding pages that run better and faster...


You also forgot to mention Flash :) It was starting to solve all the problems: from design to inveractivity. But then Adobe.


ITT: non-web developers whining about JavaScript (a favorite pasttime of HN)


Or bragging about a pet project they made with vanilla HTML/CSS/JS that's any or multiple of:

* not particularly impressive in terms of UI requirements

* likely took them 10x the amount of time it would have taken if they just used a framework

* doesn't make any API calls

* doesn't manage any/much state

* is composed of code that no one else would be able to easily hop into and refactor if working in a team scenario


Nothing happened there’s just no need to talk about it every day.


TL;DR - People started using their mobile devices not just for apps, and not just to view static pages, but to spend money. They started expecting websites to behave like apps started spending money on websites that behaved like apps.

We have frameworks instead of static HTML because it is really complicated to make a website behave like an app and it takes a LOT of javascript. We started out with jQuery ajax calls and media queries. We moved on to AngularJS to start swapping content in the page in larger chunks and maintain state and code better. We've now moved most/all of the site functionality into Javascript via React to better manage caching and state of the application for the best performance and more manageable code that leverages APIs for most of its data and content.


For my own startups that I work on as a solo developer over the last few years, everything is currently in vanilla JS and CSS.

I have been programming for decades and used many different component systems on the web and desktop, such as React, Angular, Vue, WPF, wxWidgets, some more that I dont remember.

For projects involving several designers and developers, some kind of component model might be necessary to be able to easily reuse and integrate code. Also designers or backend programmers may not factor in the complexity of certain design or architectural decisions such as state changes that are supposed to cascade to other items on the page.

Since I am controlling all of those decisions, I can for example simplify so that either only state relevant to one small element is updated, or an entire tab panel is re-rendered. And then can ensure there is time to optimize the panel rendering.

With that amount of control, usually the extra cognitive load for the component system etc. seems to not be worthwhile.

But for example many years ago I had a complex web front end given to me on a shoestring budget, with subpanels etc. supposedly automatically reflecting every other type of state change that occurred. He insisted that I use a plain version of something called Knockout.js which did not have facilities for tracking and updating based on so many dependent state changes. Then he kept adding more and more panels and components, with more cascading or interacting state changes that caused bugs when I tried to manually keep them up to date.

So that was kind of a "setup" in terms of the architecture required of me by the contract and the design decisions and there were lots of bugs and was especially rough to do in a small time frame. At the time things like React and related state management did not exist or were not known to the client, who thought he knew better about architectural decisions anyway and so that wasn't something I had room to negotiate or in the budget to research.

You either need a good concept for handling all of these potentially interacting state changes such as what happens with component and state flow systems, or you do what I do. The whole design avoids it where possible, and when necessary I set it up so I can just re-render that whole section, making design decisions to avoid something causing annoying latency or other problems. It's a lot easier for me to do this stuff as a solo developer where I have end to end control.

Also one thing that has changed in the last several years I think is that Firefox and Chrome have gotten significantly faster at re-rendering HTML through various optimizations. So actually some teams may want to reevaluate complex state or component frameworks to see if they might be overkill.


I'd say 80% marketing and "monkey see, monkey do" effect.


I find myself missing React when building a plain HTML/CSS/JS site. I just like the modularity and my fingers have muscle memory for solving certain issues.


From somebody who's been in the industry for a little bit (only 10+ years, which depending on your perspective could be no time at all, or a lifetime!), I'd be wary of becoming too familiar with the "react way" (substitute your framework of choice.)

Aeons ago I learned js with Mootools, so much so I thought in Mootools vernacular. Imagine my surprise when Mootools went away seemingly overnight and I couldn't code vanilla js to save my life.


Fair!

I'm pretty confident in my ability to pick up new tools and tech (I'm probably too far into the "bleeding edge" side of the "how comfortable are you supporting new tech in prod?" scale), so I'm not overly worried about getting left behind.

I just recently had to explicitly build a "raw" JS/HTML/CSS app for work, and found myself missing the organization React overlayed on top of JS, is all.

Besides, my bread and butter is backend, so I can always throw my hands up and shove the work onto some web dev's plate if I ever do get left behind! :D


I make little JavaScript stuff on my WordPress site, does that count?

No react needed.


If you don't understand the problem they are solving, you're still very green in the field. Try to implement a basic data bind input field and display the value in the DOM with react vs with just "vanilla js". You'll see the difference right away.


https://jsfiddle.net/craqvoxz/

3 mins... or were you looking for a server-side component as well?


I already said I'm not even in the field - I just dabble in it. But thanks for your input.


Sorry, I missed that part




Applications are open for YC Winter 2023

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: