> JS frameworks move really quickly

React is a lot more stable than I think you're giving it credit for.

> And the stability also means that more time is spent on delivering features

Frameworks/libs also exist to save you time, thus letting you spend more time on delivering features. And fwiw, the obsidian team seems to agree in principle. Your link goes to a forum post of some kind, in which one may find a link to obsidian's third party deps: https://help.obsidian.md/credits#Third+party+acknowledgement...

These do not include React, but do include:

- i18next - lezer - moment.js

Plus a bunch of others. Why didn't obsidian write their own date lib and chose to use moment.js? Because it saved them time, despite the fact that moment.js does make changes, and many people are moving on from it in any case.

The idea that not using a frontend framework will let you focus on delivering features seems reductive, and the obsidian anecdote doesn't support the idea anyway.

Whatever you're building, it's never a bad idea to deeply understand the tradeoffs that using a library will bring. Obsidian probably couldn't accept the downsides of React due to them needing a bunch of custom renderers for content, which React makes harder. But that is likely a rare constraint for apps in general.

Generally speaking, libs like react exist to save you time and help you focus on delivering features.

I build a lot of micro sites, but I still use frameworks — like Deno (node alternative), Hono (for APIs), and Alpine.js (for tiny lightweight sites).

you don't have to though!

if you want to do more pure vanilla, understanding signals is really useful — this basically powers svelte's runs and react's hooks and whatever.

I love nanostores, a 286 byte (!) state manager that lets you build highly reactive pages w/o the weight: https://github.com/nanostores/nanostores

flexible tools like tinybase (https://github.com/tinyplex/tinybase) and unstorage (https://github.com/unjs/unstorage) are also super useful

tools like this lets you build highly reactive, engaging sites that load for under 50-100kb

The frontend of my main OSS work was made is plain es6: https://github.com/mickael-kerjean/filestash

The frameworky code is under 100 lines of code, heavily inspired by what I think is a good idea from React: "components are pure function", the simplest example of the about page beeing visible here: https://github.com/mickael-kerjean/filestash/blob/master/pub...

Since the whole project was migrated over from React, I was able to improve performance to a degree that would have been impossible using React, it's a breadth of fresh air to open the performance and memory tab and to be able to optimise things from there to get 60FPS no matter what whilst preventing massive ram usage because those frameworks runs all sort of code that is out of your control. Also because there is no build system, I was able to introduce plugins to be able to patch frontend code via patch applied dynamically by the server to create features like the recall button to recall data stored on glacier when using S3, dynamic patching of the icons to apply branding and many other things that I would have had to fork entirely before

Anyway, I hope our industry would go more often the vanilla route, es6 is ready for prime time and solve all the pain point we had while internet explorer was still a thing

First, I decide if I think the app will have lots of client-side interaction. As a shorthand, the question is “Does my idea seem like a spreadsheet, Google Maps, or a video game with lots of interactive clicking?”

If the answer to that question is “No”, then I’m not conceptualizing a SPA and don’t need a framework.

If the answer is “Yes”, I’d ask where I think that interaction will manifest in the experience and if I can isolate it.

If I am not looking at a SPA use-case, then my focus is on using vanilla HTML and Modern CSS with a tiny bit of javascript (as a scripting language versus as a programming language [1]). Then the remainder of the focus is on data modeling (CRUD), auth flows, and business logic development (what the application will do).

Beyond vanilla HTML, Modern CSS, and a tiny amount of javascript, if I need further client-side interactivity, I would consider something like htmx.

If I need interactivity beyond that, then we’re into SPA territory, but at this point the requirements and application have evolved to that point since we initially said we weren’t building that kind of thing.

Overall, the idea is to progressively iterate on the application, keeping the architecture and dependencies reigned in and aligned with the core objectives.

[1] JavaScript as scripting vs programming language: what I mean by this is JavaScript as a language with many warts is not so bad if its scope is kept small. I believe the issues with JavaScript arise when it is pushed to do too much. This then leads to needing to use Typescript as a matter of pragmatism. I aim to never get to the point of using so much JavaScript that I then need Typescript. I would say using it as a scripting language (to fill in gaps that Modern CSS and HTML cannot handle today) greatly minimizes the need for this progression.

The modern web platform is capable and not bad at all to work with directly. I love seeing projects like HTMX and the recent hyperflask etc showing the way, but you don't need to buy into a project to follow this path, just use the web platform.

Edit: for a more practical example, you don't need to go down the web components rabbithole just for native reactive components, MutationObserver can watch for your template fragments entering and exiting the DOM and run your init/destruct routines on them. Now you can just push HTML back from the server with fetch or xmlhttprequest or whatever, and as soon as your component's HTML enters the DOM it will be "hydrated" by your init routine via MutationObserver. Honestly, add some event signaling and XHR and you're further along to a smooth SPA-like experience than you might think.

Vanilla JS is very powerful and has the features you need to build SPAs without a big framework. Proxies and mutation observers are great for maintaining state, Updating the DOM yourself is fine, view transitions are awesome, etc. The only thing that's hard is routing, but there are lots of small dedicated JS libraries to handle that. Here's one I made that gives you the Express API on the frontend: https://github.com/rooseveltframework/single-page-express

A few years ago I rebuilt a 3D model checker for the building industry and intentionally avoided a full frontend framework to keep the UI performant.

I wrote a small internal mini-framework to follow the MVC pattern and Web Components for reusable elements. I also used external libraries: three.js for 3D rendering, sql.js for handling the 3d's models meta-data in a performant way, and @tanstack/virtual for virtualizing large lists and tables.

The biggest benefit was finer control over performance. The main downside was a less comfortable developer experience — it’s harder to find polished, ready-made vanilla-JavaScript components, so you implement more yourself.

IMO: It's good to know how to manipulate the DOM directly. Any complicated web app will always hit some kind of corner case where you need to bypass your framework and manipulate an element. For example, the spinner that you see on https://manage.onopti.com/ is disabled with a pure DOM call once WASM + Blazor is started up.

That being said, as many other comments rightly point out, (for most projects,) if you work directly in the DOM you'll end up recreating what most frameworks do for you. It's really only "worth it" when you can strongly justify it: IE, if you're making a charting library that can handle thousands of datapoints, or a rich degree of interactivity that a usual business web site doesn't have.

But for a typical interactive website: Use whatever framework your peers at your company will be comfortable with.

1. web-components https://developer.mozilla.org/en-US/docs/Web/API/Web_compone...

2. router https://developer.mozilla.org/en-US/docs/Web/API/URL_Pattern...

The rest should be code organization, not even a build tool.

Can check this example https://github.com/radio4000/components

I've abandoned Next.js and React for Elixir / Phoenix. I am able to build a perfectly pleasant user experience with just a sprinkle of vanilla JS via Phoenix hooks.

The fact that I have been able to build a multi-user collaborative editor experience without a single additional dependency is incredible. I previously worked for a well-established and well-funded React team who had this feature on their roadmap for half a decade but still find it too daunting to implement.

Phoenix was a great reminder that a lot of the "frontend engineering" we find ourselves doing as React developers just isn't necessary with the right backend. It's HORRIFIC to look back at all the yakshaving I've done in my career already. Wrangling types (GraphQL, codegen libraries), wrangling queries and data-fetching (react-query, SWR, server components), fiddling with middleware (serverless functions, getStaticProps, CDNs). I've seen teams outright abandon testing because the hours they invested just weren't catching any of the bugs that mattered.

I'm not doing any of that anymore. I'm spending that time refining the core data model, improving test coverage, thinking about go-to-market and making money.

Phoenix may not be a good choice if your product has reached that level of maturity and product-market fit where you really should care about "microinteractions", fine-tuned animations, or advanced use-cases for an SPA like offline support and highly-optimistic UI. But I would argue that even mature products don't truly need these things. Just look at the GitHub UI. I've spent a truly astronomical number of hours in that UI and never wished I had WYSIWYG text editing, or animated skeleton UIs, or the dozen other things that the React community tells us we need.

It depends on the target product.

I'm working with JS for already 25 years. Tried all of the frameworks, and continue on doing it. And every time I try something new, the refactoring flow turns most of them into NextJS (if it's very UI rich or customer facing or something very web-oriented), or Vite+React+Tailwind (client) and Hono (backend) if it's more of a tinker toy needing more custom solutions.

The boilerplate with NextJS is cleanest (compared to all the other frameworks) and API is the most straightforward one, and you can safely ignore the vendor lock in. Its just a pretext to hate on NextJS. They all have some kind of a "vendor" lock in. Be it a vendor-or-a-specific-approach-or-whatever-lock-in.

And Vite+React+Hono — simplest to set up for quick experiments, and very powerful with minimal boilerplate. Will probably create a starter for this one, as I have been using this stack quite a lot lately.

EDIT:

You can pretend vanilla JS is all you need, but then your app grows, then you suddenly need types, and state, and more events and their handlers, and SSR or something else. Thus React has been the most stable bet for quite a while for me now.

Spritemate is built with TypeScript + Vite + JQuery, and has a pretty organized structure: https://github.com/Esshahn/spritemate (I do not condone its use of the 'any' type everywhere tho)

I wouldn't use JQuery for a new project, as you can do almost everything it does with straight DOM manipulation. But there are still some strategic vanilla JS/TS packages that come in handy, e.g. clipboard, mousetrap, file-saver, split.js.

Web Components with Lit is kinda fun, though you'll have to deal with DOM shadow roots or disable them.

I would challenge that using a framework leads to less security. In vanilla JS you've got to use something like dompurify religiously to avoid XSS bugs, and you're tempted by the shiny candy-like innerHTML attribute.

Addressing the very first sentence in this post:

> I had a mind-blown-moment when I learnt that Obsidian was built without any frontend JS framework.

The comment you’ve linked to is wrong. Obsidian uses the Electron framework for its “front-end” framework.

In fact, it was even affected by the recent “Tahoe” Electron bug.

https://en.wikipedia.org/wiki/Obsidian_(software)#Availabili...

JavaScript is a really flexible language and it’s easy to build “just enough” abstractions to get stuff done. It may be hard to believe now but at one point web frameworks were not a thing. People used plain old JavaScript and maybe jquery. I worked on several large web frontends (SPAs) back in the 2000s that were pure JavaScript. I did a project in 2018-19 modernizing one to get it off of IE11.

So yeah, JavaScript is nicer nowadays, and browser apis are more consistent than they were then.

Back in 2000ish, a singular dude built a full-blown bank teller workplace app using IE4.0 proprietary features and client-side JS. Server communication was done by posting a form into a single-pixel frame and then looking for objects in the DOM of the returned html. It was fast, robust and scalable.

You have been conditioned to think frameworks are necessary. That’s not true. You can build anything without them and it would probably be better in many ways. Would you spend a ton of time? Yes. Would your code be harder to maintain? Yes. But it is absolutely doable and not as hard as you’d think

The reasons I avoid large frameworks like React, Angular, Vue, and even jQuery is that they are aren't necessary. They are code decoration that slows things down. Here is what you can expect without these:

* greater flexibility

* faster execution, My current application produces a large single page application that fully renders visually and executes state restoration in about 105ms localhost or under 200ms across a network

* faster maintenance, I can do massive refactors that touch most files in the application in about 2 hours thanks to thorough use of TypeScript interface definitions

---

Here is how I do it:

1. Just start building your application. Realize that for any significant application the front end UI is probably only about 20% of the application code, or less.

2. Start the UI by writing static HTML. Reserve JavaScript, in the browser, only for handling events and state restoration and execute state restoration only on page load.

3. I prefer to use WebSockets over HTTP as much as possible for absolutely everything I can get away with. WebSockets are full-duplex, where HTTP is not, and have far less overhead. That will substantially reduce the complexity around messaging in and out of the web browser.

4. Everything after that is just execution, planning, refactoring, and feature addition.

5. You can do absolutely all of it in TypeScript now without any compile step. Node.js now executes TypeScript directly, but the browser does not. To solve for the web browser just include the browser code into your Node application using ES6 module import. If the imported code is a function you can convert it directly into a string for transport, and otherwise use JSON.stringify for objects/arrays.

You can, but if you did you would likely just reinvent concepts that are in the framework. Maybe you will do a better job (problem is that many believe they can, and so do).

You could even write your own browser that uses python instead of javascript. However, it would only be compatible with python html pages. We stick with JS for web development because that is how the "browser framework" is designed. HTML, CSS, JS, etc. are all just part of that framework. If you wrote your own browser, you would need to reinvent all that as well.

I do not miss the early browser days, where different browsers could have been seen a different frameworks. Things go allot better when the browser framework standardized. I still suffer from the IE trauma.

Allot of what we see with JS frameworks ought to baked into the browser framework, but that process is uber slow, because people have to a agree, and people do not like to agree. But it is magic when they do.

Every time a company refuses to use a framework for a large web project, they end up reproducing all of its features - badly.

And, when a new developer comes in who knows React, they can ramp up fast and even if they don’t, there are plenty of resources instead of asking Bob how something works - if Bob is even still working there.

As someone who does both a lot of app development and web development I’m always kind of confused about how insanely far behind the majority of the web crowd is on these topics and I largely put it at the feet of React who went off on a wildly different direction and ended up making a huge mess in my opinion that huge numbers of people will swear is somehow a “best practice”.

My advice is to go and learn a proper architecture (MVVM is a great fit in my opinion for MOST things) and then figure out how to implement that with something you enjoy using. My only bit of advice here is that the closer you stick to the underlying web platform the better off you’re going to be so if you want a concrete recommendation something like Lit here gives you all the primitives you need along with great performance, documentation and developer experience.

For web, Elixir Phoenix LiveView: https://www.phoenixframework.org/blog/phoenix-liveview-1.0-r...

For platforms, just go native - it's easier than ever with LLM assistance.

I've written and re-written many toy and throwaway UI frameworks. It's fun! My current pet project is built on SFML, which is basically a thin wrapper around OpenGL.

If I had infinite time I'd probably do most of my UI work at this level. I enjoy the process of "how can I do x? I don't have a feature close to x, so let's go build it!".

I think this mostly stems from the trauma of dealing with winforms/wpf/uwp and from having seen JavaScript once before. I feel like I'm restoring sanity in the universe by stacking rectangles in a not-crazy way.

Frameworks don't have to be complex and all-encompassing. When I'm "done" with a project, its UI layer generally only supports exactly what the application needs and not much more.

The reason the big frameworks are so gnarly is that they try to do everything and thus do no one thing particularly well.

You should absolutely build your own UI framework or try laying out a UI from GL primitives. It's like the assembly of UI design. Not for everyone, sure, but I find it peaceful

If a migration of breaking changes seems like a lot of work for you then I suppose that rolling your own framework won't be any better.

With the framework, you have structure. It might not be the best structure to use, but you have one. React lasted really long and is still works today.

Going without framework works if:

- you have a really small project

- you are so advanced developer or have specific use-case that using a framework creates more burden than time saving

- you are creating something so valuable that reimplementing it yourself is worth it

I think that regular website will bleed via maintenance costs in the long-run if you don't use a framework. Instead of paved road with framework migration you would be fixing and debugging bugs in your framework/codebase.

As an old developer 30+ years. I love to build from scratch with no frameworks, but it is not viable for corporate development requirements. For many personal and yes large projects I still write from scratch. I will be the first to admit I hate building pretty sites so mainly focus on functionality rather than look and feel. Again corporate world would hate that. Frameworks make things easier, and faster, and yeah mostly run better. But they do lose the details of developer really knowing what every bit is used for, and how they made it work.

The web wave was a trick companies played on developers minds. Should've stuck with C people...

The important thing in any "large" application is to set consistent patterns for doing common tasks: creating UI components, re-using them, updating their content as a result of data changes (reactivity), etc. This can be done with or without a framework.

A framework establishes a large portion of those patterns upfront. If the framework is a popular one (e.g. React) rather than an in-house one, it makes it easier to quickly ramp up hires and have a lot of documentation/examples online. Popular frameworks also implicitly contain a lot of knowledge from years of feedback from thousands of devs exercising its APIs and providing feedback, so they're typically pretty good at solving common use cases.

Obsidian was initially built by a single developer. One of the best that I have the pleasure of knowing, but when you're one person, it's much easier to create your own pattern and have it work for yourself. They have since hired maybe 2 other devs, with minimal intention of hiring more, so ease of onboarding isn't a significant concern to them the way it would be for most companies (and "large" frontend apps more often than not require larger teams, by definition).

The reality is that DOM is pretty high-level already. It's just not that hard to do. The only things that have improved my productivity over the years are:

  A) getting better at handling graph data structure, 
  B) learning how to use Regular Expressions as a code editing tool,
  C) quit chasing every new thing, and
  D) Typescript.

JSX encourages sloppy HTML. Props are are overly verbose. Hooks are a nightmare. Contexts are gross. Portals are a stupid hack for the very, very stupid reason of making it nearly impossible for parent elements to read anything about their children. The whole "props down, events up" paradigm is woefully naive and half of React exists to get around it because of that.

So yeah, if all you know is react, you've already been on the hard path.

There's a lot to learn from next gen app tools

- Svelte seems to be fast and simplifying complexity - Laravel is likely the most complete end to end ecosystem I can't rule out. Their hotwire tech is impressive and all built in. - Rails has something similar I believe

It depends on your app too.

React definitely can be heavier than needed especially if the client experience doesn't heavily benefit from it or there's other ways to achieve it.

You build your own framework in some sense, it's a good learning exercise. Modern component frameworks can be anywhere from highly abstract to relatively light weight. If you're mainly using something like Vue, you just need to figure out where and when to update the dom, where to store data temporarily, etc..

Things get unwieldy at a certain scale when you don't have something like Typescript regardless of whether you have a framework, but you could start by building up small bits of the frontend stack from scratch. I learned how to do a bunch of manual raw js stuff from scratch originally, then did some professional work with YUI at a huge scale which was probably as close to an event driven frontend system as you can get. Start by figuring out how to listen for url changes, make a network request library from scratch, store data somewhere.

Imo one of the beautiful things we now get along with frameworks is a host of independent build tools that make the feedback loop of testing changes nearly instant and loosely coupled from your code.

I'll add a secondary, or implicit, criteria that the approach you take should not require a 'build process' for the front end app.

M -> the MODEL is managed by the backend server, or in-browser via WASM

V -> the VIEW is defined by the HTML and CSS

C -> the CONTROLLER can be solely Javascript in the front-end, solely backend server processes, or most likely a mix of the two

While it does not use a commonly used "framework" it uses many libraries and likely has its own custom framework.

In the past we used http://microjs.com/ and similar to find small libs to work with when we threw together marketing websites, not sure how maintained that list is nowadays but the idea is that you can make websites like lego, sometimes you don't need a whole box of Eiffel tower to make a little tree.

If your functionality is well thought out and not super complicated, don't have 10s or 100s of devs on the same project then working without a well known framework could make sense, otherwise there can be steeper learning curve when onboarding new devs, scope creep / bloat, etc that will likely cause issues down the road.

To learn about this you could try to replicate for example the mentioned Obsidian by yourself and research solutions for all the issues you run into, e.g. minimal routing, custom view renders, reactivity, performance, etc.

Even if you go back to using react it's still useful and fun to read about how people can implement things like virtual doms to get an idea about what's happening under the hood. From there it's easier to figure out if react is the best choice or other choices might be better.

From there one big question is if everything needs to be dynamic or not. You often have menus and navigation that you don't need a framework for and that even something like jQuery is well suited for. On the other hand a framework would probably slow things down for the writing experience in Obsidian, which is the main draw for me to use Obsidian. Once the writing module is written from scratch, it won't seem like such a big lift to also do all the navigation and controls by hand.

That doesn't mean this is the right way for everyone. A lot of times the speed to releasing new features is more important, while the handicraft of the UI/UX is less important and in those cases using a framework is absolutely the right choice.

You don't need a large framework to build a maintainable, efficient web app. Here's an example: https://github.com/wisercoder/eureka/tree/master/webapp

It uses two 500-line libraries:

This 500-line lib lets you use TSX syntax without React: https://github.com/wisercoder/uibuilder

This 500-line lib implements MVC routing: https://github.com/wisercoder/mvc-router

Large software projects are an interesting use case because once you get large is precisely when the framework becomes valuable.

A large enterprise project will need security, testing, auth, (AI now too). I'd hate to implement SAML without a library, that would be torture, and likely incompatible with most systems.

While I've often written small self projects from scratch, I wouldn't dream of building a large one that way unless you are sure to have an army of engineers and QA.

As an aside, this is where AI code fails as well. Speed of dev is easy, stability over time and compatibility is hard.

The real benefit of using a framework is that it helps to create components which can be easily and reliably nested. That said, nowadays you can achieve the same thing using native Web Components.

I'm currently working on a Company and Employee finder application with Web Components. I found them a lot easier to work with than React.

Also, I'm using a serverless platform I built from scratch. So it's literally all made from scratch with very few dependencies.

https://www.insnare.net/app/#/dashboard/

React is dead easy to create a component and get going with whatever you want to create. But as your application grows it is really difficult to test. The React testing library sounds good in principle, but once you have useEffects, hooks, the DOM, and every other side effect running interwoven with your component logic, it becomes difficult test. Obscenely difficult. I think there's some tradeoff operating here. I want a front end framework that makes it a little easier to test, happy to go through some more pain to write components.

I think that you have a good angle, with latest HTML, CSS and so on. I would consider HTMX or DataStar (SSE) based on where you want to manage the state. Bear in mind that both can coexist.

My priority is code clarity … so while it is not yet tested at scale, https://harcstack.org is aimed to do this on the server side (disclosure - I am the author)

Another determinant is the server side language / approach to templating you choose. With HTMX Python, Rust, Go are all fair game. I’m leading with Raku due to its web framework and ORM.

Draw.io is quite good, and it is made without using any frameworks. Alas, the source code is not open to learn from.

<https://www.quora.com/What-is-the-tools-and-languages-used-i...>

I don’t know how they do it but in general the big thing you need to think about is how to handle reactivity.

There is no reason you cannot implement MVVC/MVC or whatever else on JS for reactivity, it’s just that react et al just abstracts that away for you.

You are effectively choosing some method of implementing and abstracting the observer pattern and handling cleanup since you can easily get into a situation where you have dangling references to objects that are never cleaned up (memory leaks) or pretty nasty GC hangs which can make the UI feel bad to use.

All you need is fetch, document.querySelector, some sort of observable, and patience. It's really just a software architecture problem of component reusability which is going to be true whether you use a framework or not. How do you compose your views, process events, update information, and send data? Sometimes it really is just as simple as <ui-component onclick=...>

Programming is managing a pile of complexity that wants to fall over.

Going without a premade framework means it's a fight between you and the pile of complexity. Code will tend to become ugly and slow and hard to change the more you add, so you'll have to go into a cycle that's more like add-refactor-add-refactor. Forward then sideways, forwards then sideways. Do this long enough and you'll will end up with your own libraries and frameworks to manage the complexity.

MDN has your answer, built into the browser, ready to go: https://developer.mozilla.org/docs/Web/API/Web_components

If that's not enough, Lit enhances it a bit such that either LitElement and/or litHtml can accommodate whichever style you want: https://lit.dev/

I build a figma clone for animation (https://moos.app). It is by no means a super large project (I think 40k loc) but is has reasonable frontend complexity. Most stuff is just composed of simple functions. For example routing is just an eventListener on hashchange. For state I am passing around an environment or firing events (the event system is 100 loc). For showing UI there is one convenience function to create HTML elements. Basically tag(tagName, props, ...children) (implementation also 100 loc). Each view is it's own file and manages itself. The object list can contain thousands of items so it uses a virtual list for performance (100 loc).

As you can see most functionality can be implemented in around 100 lines of code. The advantage is that you can build up functions just for your needs. These functions are super easy to understand because they don't have any dependencies and the whole implementation fits on one or two screens. There is very little indirection.

Another advantage is that most code is actually doing something concrete. With frameworks you often have a lot of code that is just pointing to other code, or is boiler plate code to set something up. Not having any boilerplate code also makes stepping through the debugger a lot easier.

The project has no build step in development which also makes debugging easier. It does have a build step in production.

Most people use frameworks to give the code structure. When writing vanillajs you need to bring the structure of the code yourself. This does take some getting used to but I think it is an essential skill for good programmers to have. On top of that many frameworks push you into structure that does not make much sense in my mind (for example seperating the view and the controller if those are always gonna change together).

So to conclude: My advice for building without frameworks is, just start building. Problems will come up and you can tackle those as you go. Do you think you need to use events in your application? A simple implementation is 10 lines of code and can be written in 10 minutes. If it takes me 1 hour to not use a library I will spend that 1 hour. Most frameworks will not bring that much value. Easy things become short and hard things will become impossible. I think most value is actually brought by the language and the basic api's (DOM, CSS, etc)

We were building decent apps long before React.

Even pre-web. I remember, how quickly I could create Delphi desktop app with drag & drop UI builder more than 2 decades ago. If we speak about generic ERP, you could make dozens of screens in a day.

You just split your app to layers.

That might be for example:

1. Just UI;

2. UI logic (validations, preloading selects...);

3. Transformation of data between data model and UI model

All of the things above lived on users' computers.

All of the things below were on servers.

1. API gateway (terrible things like SOAP, XML-RPC or completely proprietary formats);

2. Business logic;

3. Database

It is not that hard, DOM model is amazing, that's why there are so many frontend frameworks in the first place.

However, you'll inevitably end up with your own after some time. Even if you try your best to stay away from it, you'll need abstractions for:

  - components and lifecycle
  - some sort of templating
  - connecting your app's data and components

IMO, JavaScript frontends have three components:

- Routing

- State

- Rendering

A lot of frameworks try to cover all three of these, and that's where you tend to see a lot of feature churn. I would recommend picking a rendering library (like react) and writing your own routing and state library, even if it's just a light abstraction on top of an existing library. This will make it way easier to upgrade or move in the future, as you will control the API.

My preferred stack:

- jQuery

- Typescript

- Tailwind

- Novel (https://github.com/owls-on-wires/novel)

- Some other small libraries for things like state management

- Webpack for bundling

An example of it in action: (https://mnty.sh/#serenity)

A LOT of websites don't need a "front end" framework (apart of the one that is already there: html, css).

Could need some js library and that is a maybe.

In general:

If is like a eCommerce site, blog, wikipedia, forum? Not need

If is like a Game, Paint app, form builder? Need.

And how you learn it? Not use a framework, and try to stay with things more minimal, like tailwindcss.

For me, it's Django templates + HTMX + vanilla JS when I absolutely need it. Crazy how far you can get with just this stack. I even did a technical spike for a realtime chat app recently with this, and it honestly performs better than some bloated JS monsters.

It’s always mildly amusing how many engineers believe that React is a framework. I personally attribute it to lack of experience—once you’ve used enough proper frameworks, you’d laugh at that comparison. The fact that React is and always has been literally defined as a library right on its website doesn’t seem to stop them.

Incidentally, many of the issues people have with React are attributable to this mistake: knowing what a framework is supposed to be, one might expect React to take care of everything, and when it turns out you’re on your own and using React in a complex project means (whether consciously or not) coming up with a homegrown React-based framework of your own, or using a collection of disparate extras that fill in the blanks (like CRA), by then it’s already a hairy mess of a codebase in a desperate need of refactoring.

React lacks most of framework traits. The library does reactive rendering and contains a somewhat restricted set of low-level primitives around it. Even its DOM integration is handled by a separate, optional library (ReactDOM).

Someone could complain it feels like with Vercel the direction for React is to become closer to a framework (now with RSC and JSX runtime being part of React), but still it is nowhere near a state where the phrase “a framework like React” rings true—and, in fact, Vercel’s interests are aligned with keeping React more of a library than a framework so that more people use Next and are upsold Vercel’s hosting, and Next is in fact a framework in the full sense of the word, comparable to Django or Rails.

Similarly, Vue, Angular, Marko, Astro, Qwik, etc. are frameworks. They provide you with project structure, scaffolding, and a lot of batteries. The fact that many of them are, in fact, using React under the hood speaks volumes.

people are oblivious to the fact libraries and frameworks dependencies need to be curated...in other words, theres a tradeoff between time spent managing dependencies and time spent avoiding dependencies...by the way, not upgrading is also an option

Check out my talk about minimum viable view library (then frzr.js.org, now redom.js.org): https://www.youtube.com/watch?v=0nh2EK1xveg

I have vast experience with react been using it nearly since the start, built many many large and small projects.

I’ve switched to web components with lit/html driven by AI.

Could not be happier.

When you write an app without using an existing framework, you are bound to write your own framework. And there's nothing wrong with that.

I've been leaning more towards no build solutions like lit.dev (without typescript).

This is what I used for fontofweb.com's snipper chrome extension.

Things have a lot more to do with how good the developer is than the language or framework.

HTML+CSS+JavaScript is already a massive framework and layer of abstraction. Try creating a GUI in C++ without using any libraries.

there's design principles behind css js and html and people don't bother to learn them and instead want to shoehorn what they know into these languages. Take the time and actually learn the elegance of these underlying languages and use them properly.

I don't know why people continue to refuse to do this.

I have had some really good results with Alpine.js and back-end templating for simpler apps (especially served from non-traditional embedded web servers). This base plus the combo of what kids these days call "vanilla JS" and whatever other libraries make sense has worked for me for small-to-medium complexity sites. It would easily grow to larger efforts as long as the team did. I think if my sites grew to need larger teams, there would be some value in using frameworks other people have used; this basically means "match the big guys" to make brainpower a little more fungible, even if the tools aren't perfect for the job.

You don't need a "framework". You don't even really need a rendering/state library like React, depending on what you're doing.

If you're having difficulty thinking outside of frameworks, I would suggest you work on a simple project where you don't use anything like Next.js or React. Start with the bare minimum of tools available to you through the browser API and your backend runtime of choice, then add things on as needed. Try implementing your own routing without using a third-party package dedicated to routing. Work on your own component system, state management, or even a rendering abstraction.

I can guarantee that, once you at least near completion on such a pet project, you'll not only have a better appreciation for what frameworks are doing but realize that they're actually quite overrated in a lot of ways. In reality, it's totally feasible to build an application, especially one for the web, with more of your own code and not having to think about it in terms of how your logic fits within a "framework".

At the end of the day, 99% of frameworks is someone else's opinion. This is I think what makes churn in the JS world painful. The majority of changes are based on a developer's opinion of how things should work, but their opinion isn't necessarily better than anyone else's. Your application is not worse because it doesn't use someone's idea of how an elegant state management system should behave. It's not worse because it's doing its own DOM manipulation rather than handing off all that work to an opaque rendering library. The point is to get the job done. You can make a kickass web application with freaking Backbone or jQuery if you wanted to.

It's not that I don't appreciate frameworks, though I do think it's important for programmers to learn how to move beyond them. Frameworks don't have as big a job as many are lead to believe. Their complexity is primarily arbitrary most of the time. It's not that such complexity can't be beneficial, but bypassing said complexity doesn't require a big brain.

Web evolves fast because billions of people use web based end user interfaces every hour.

It's all about saving time. If you don't care about a particular implementation, just that it works, you're more likely a candidate for a framework. If you do care (or just want to understand how it works), then less so.

One of the biggest follies I've seen on the web is people calling themselves <framework> developers. No. You're a developer who uses a language and you prefer a specific framework written in that language. And if you don't understand that language, it really doesn't matter what framework you do or don't use—you'll be lost no matter what (or making messes that someone more qualified will have to clean up later).

All of that said: learn your language, learn the syntax, and you'll be able to pick up any framework built for it with a quick read of the docs (unless the docs suck or are non-existent, then it's best to move on to the next option).

Do the things that make you productive. All of this "best practices" crap is a farce. There is no best practice, just popular and unpopular opinions. Do what makes sense to you.

They will write their own framework of sorts in any case.

fetch(url).then(res => querySelector/querySelectorAll/getElementById().innerHTML = res.body());

19:59 CET Framework 138 Comments 104

And now for something completely different: https://newspeaklanguage.org Nothing else compares.

checkout out ui-editor.com