To me one of the unsung skill sets of the industry is tool selection. The ability to look at a tool and imagine how it’s going to behave for different pay grades of coworkers, different specialties, and to predict how that will pan out in the future.

Sometimes you pick the simpler tool, and hope it has legs. Sometimes you tweak your product roadmap to dovetail with the tool’s. Sometimes you push to get 25% of a feature set released so you can make progress. Sometimes you temporarily add another tool, and sometimes you fork for a while.

What most people just do though is measure power of the system, ignoring the Principle of Least Power for third party code, if not in fact for the entire project. Approachability is often better than power. Quickly knowing what a tool can or cannot do is generally more productive and results in less politics (who hasn’t worked on a project where person A keeps criticizing Group B for not knowing the framework can just do the thing they wrote, but it’s not immediately obvious that it can? That’s someone tearing down the team to boost their own ego. I don’t like it. I liked it even less when I was the one doing it. Don’t be That Guy, he’s an asshole)

Yes, and even though a lot of tech companies killed the architect role, this is exactly the job function assigned to architects, or more specifically enterprise architects in a lot of more traditional companies.

I haven’t had a lot of luck with architects. In one case I came to a company that got rid of their architect and hired me and another person to replace him (to be fair they were too small to warrant a full time role anyway, not sure what they were thinking).

Especially in the post refactoring era, they tend to have an inaccurate account of what the code is actually like and make bad calls based on bad info. It’s a responsibility that works better when the people have their hands in the code. I’ve had better luck with Architecture as a job description shared by the lead developers. In large enough companies they have Staff Engineer that scratches that itch with perhaps slightly less people skills (though I really don’t recommend it).

yep, if your architects don't have their hands directly on the code, they're making bad decisions.

People talk about enterprise architects as these pie-in-the-sky people who shit diagrams and everything works wonderfully. In practice it's "seagull architecting", with everyone else forced to deal with the reality on the ground.

At some scale architects need to be more hands off. When that happens they need to have a _very_ strong relationship with the people on the ground or it doesn't work well. Even then I would argue they should be getting their hands dirty in terms of reading code, etc, they just may not have time for implementation duties.

I like to go back to the basics. It irks me that folks don’t think HTML/CSS/JavaScript are good enough as-is—but nowadays the default browser capabilities are incredible compared to a decade ago. We basically have a full programming environment and add WASM to the mix! Back in the day the frameworks were first-and-foremost a platform compatibility solution.

People often have it ingrained in their psyche that reinventing the wheel is evil, but it’s not—we do it all the time when we write paragraphs.

It’s of course tempting to grab a library but there’s a learning curve and an often hidden long-term cost with using libraries.

Throwaway for anonymity.

I work at a place that is mostly like this, I can tell you that using html/css/javascript raw, with a bit of bootstrap is a nightmare with a SPA.

Menus are constantly broken, back button is a game of roulette, caching is constantly a problem showing stale data, xss and other vulnerabilities are ubiquitous.

There are modern affordances in many of these frameworks others take for granted.

The underlying issue with web applications is that it’s like a square peg going in a round hole. Remember, HTTP is designed traditionally as a stateless protocol delivering static web pages, more or less.

But here we are, with stacks-on-stacks-on-stacks of layers emulating what truly should be a native application. “Web Application” should not be a thing. HTML/CSS were supposed to be for content and presentation; JavaScript was for sprinkles of functionality.

So no matter how you spin it—each framework is a workaround making the browser do something it wasn’t designed for.

When I say that I don’t mean “abandon all APIs”—I’m just stating why things are so complicated in the web space.

Moral of the story—give us more static content please. “Dynamic” means ads and wasted CPU cycles.

Things change. Just because it was originally made for documents doesn’t mean that it hasn’t undergone such huge changes that it can literally drive FPS games at 60fps without a sweat. And I say that as someone who really doesn’t like many of the underlying abstractions, imo CSS+HTML are just thoroughly badly designed, none of them would be whole without the other resulting in extreme close coupling (layouting for example cannot be done without the other).

Also, should I really download a random exe to order a pizza? Plus, especially because the protocol is stateless a web app makes so much more sense (then replicating the state at the backend side).

Ordering a pizza can be done with static pages and some forms.

You want to make photoshop or a CAD program? That is an app. You want to order a pizza? Just use html and forms, maybe javascript to reload the progress page once per minute. (You don't need websockets or SSE or anything to check pizza progress)

The browser is a sandbox. It requires no install or approval from IT to install a web page. You don't have to go through and app store.

It has huge value as a delivery platform.

Gah, it's too late for an edit. That should read "an app store".

Sorry.

> maybe javascript to reload the progress page once per minute

Not even that, as there is meta refresh :)

> Also, should I really download a random exe to order a pizza?

That's where mobile seems to be heading, McDonalds would like you to download their app to order a burger

Not everyone is a fan of throwing away secure sandboxed environment easily accessible apps run on to native applications that might not even be built for your OS.

None of what you have outlined is actually a problem.

If your requirement is to deliver an application to users on multiple platforms then a web application is a great target.

People complain about HTML, mean while new platforms (Swift, MAUI, Flutter) still design tree like documents. It's insanely fast, optimised, accessible and the tools are fantastic.

Frameworks don't change browser behaviour, they allow you to go up a layer of abstraction. Static content is great for static content. It would be a terrible fit for a rich text editor, a dynamic chart or anything that requires interactivity.

The ecosystem is great. Native applications can get you a more optimised experience at a cost. That cost is not worth it for many solutions.

Ads are on native compiled apps too, it has nothing to do with HTTP/HTML.

I’ve always been in favor of an entirely different file type, specifically for applications. Imagine if we’d just had something like .aml (application markup language). Then html could have stayed as a document format and we could have avoided all this nonsense.

What even is a good DSL for applications?

I liked that react/jsx was born out of the web, and then influenced swiftui, jetpack compose, and flutter for a new way of writing application markup. I wonder: if not for the web and its pain points, would we have landed on similar patterns? Maybe.

Yes! This is the core problem due to the historical trajectory (browser invented for static documents, now being used to build applications) -- one that's no longer possible to sidestep at this point.

I believe there is a phrase "path dependence" to describe such situations.

It's like ORMs and game engines.

Many times when people try to forgo them, they end up making their own poorly specified and half-baked version of it that only some people (who may leave the company) understand.

I don’t think ORM is the same since it’s more of an API than a framework (in my mind). ORM also falls into the platform-abstraction arena because it typically has multiple backends which provides other benefits. It also is served as a wrapper library converting from one language to another (SQL).

Web frameworks are more like… clever hacks to HTML to wedge in a “new way to do it” more clever than the last attempt.

Game engines are also somewhat different because the level of abstracted complexity there is vast and heavily domain-specific. It targets multiple platforms like ORMS and multiple GPU backends as well. It provides physics APIs and other heavy maths capabilities too.

But the browser standards-bodies provide that for us now. HTML5/CSS3/JavaScript will run well across all modern browsers.

I've only used laraval and knexjs over the last 10 years and have no idea which ORMs people are complaining about because the ones I used do not have the issues they talk about.

I agree. They are in general easily net-positive for most traditional applications.

I agree. I like pure JS, but it just does not scale by default. You need to have awesome architecture skills and you need to constantly observe your codebase, you need to write half of framework if you want to avoid frameworks. Of course it's possible, but it's not possible for vast majority of developers, including myself.

May be we need some education: how to write 100 kLoC pureJS WebApp and keep sanity. I didn't see that kind of articles. I know that my pureJS web apps can survive few hundreds LoC. Then it becomes a mess. With React it's much easier to structure an app so it's maintainable, different parts are separated, etc.

Yeah the frameworks do force a disciplined approach. It still boils down to separation of concerns like presentation from business logic etc. Historically the front-end computation existed on the backend but with NodeJS everything sort of mushed together (creating more complexity and possible architecture mistakes). Template libraries are great way to Split View from Model—but even that is taken care of in languages now like Golang templates and JavaScript template literals etc.

I suppose the question is: how much time does it take to master stock HTML5/CSS/JavaScript versus mastering a framework, through-and-through.

Frameworks are constantly in flux but the foundation they are built upon is a more lasting skill set. But the more we spend learning framework X we are spending time away from foundations.

Did you have a look at Elm? Even more easy to structure maintainable apps.

> Menus are constantly broken, back button is a game of roulette, caching is constantly a problem showing stale data, xss and other vulnerabilities are ubiquitous.

So… what’s the difference between this and SPAs using frameworks again? Because it sure seems to me I see many of these in sites that are apparently using frameworks. Hell, Facebook — presumably the poster child for the react ecosystem and certainly with the resources to do everything right — is still introducing nav-state related bugs.

Frameworks might focus people’s attention on what needs to be done, but the fundamental capabilities aren’t in the framework, they’re in the browser and the heads of the devs.

And of course, the other possible point the parent is making is not that people should be doing SPAs from scratch (which probably wouldn’t be wise in many cases) but that it’s not wise to start from the assumption that you should be making an SPA.

I agree with the sentiment of your post, but:

> Hell, Facebook — presumably the poster child for the react ecosystem and certainly with the resources to do everything right — is still introducing nav-state related bugs.

This doesn't necessarily disprove the framework's value proposition. Bugs like this are hard to squash and at great scale (like Facebook) they're a huge challenge. Frameworks propose trade-offs to manage them, but can't eliminate all classes of bugs. We don't know how much worse it'd be without the framework approach.

If browsers could agree on a themable UI component framework - it would solve so many things for so many people. The jazzy designers can still have their complicated CSS/JS animations and cool layouts. But having a standard solution for normal developers would be so good.

As someone trying to create a frontend with plain HTML/CSS for quite a complex backend, I can attest to the fact that's impossible to maintain consistency between browsers.

It's not even about how each block's styling behaves, but how different combinations of tags, blocks and widgets are able to exhibit very specific issues in each one of the 3 main rendering engines around. In very different ways, that require incompatible solutions.

It's quite egregious.

I'm primarily a backend but I've dabbled in frontend at times where needed, and I've always kinda felt there's value in polyfills if nothing else. Maybe you don't go full Angular/React but JQuery adds a lot of value for not much effort.

I realize JQuery is terribly unfashionable these days and maybe people would rather use some smaller niche polyfill library, but with how quickly the javascript world churns and deprecates, that is kind of a virtue tbh. JQuery is 16 years old and that's ancient in the javascript world, the Lindy effect says it will likely continue to be a pillar going forward as well. You're probably just better off using the standard even if you're not using all its capabilities.

https://en.wikipedia.org/wiki/Lindy_effect

The problem was choosing an SPA

Precisely. There was someone here bemoaning how difficult it was to follow generic advice of using profilers to optimise hotspots in the application code.

He started off with something like: "Why don't you try your 'simple' techniques in a tangled web of hundreds of microservices written in different languages and running on different platforms?"

It's like some people can't see the forest for the trees.

In the last few years, I've come across about half a dozen existing web sites with hideous performance problems, all of which should have been vanilla HTML but were written as Angular monstrosities. The same teams -- against repeated advice -- have started new Angular projects for sites showing static data, anonymously, to the general public.

They start off conversations with "We'll need a web app, an API app, a mid-tier, a service bus, and then this, and then that..."

It's madness.

Choosing a framework for that is bad enough, but you could make the case depending on how complex the rendering is. Still…to go with Angular sounds like the literal worst choice. Like at least React is just a UI library and can just be used server side.

That group there…really liked to waste time.

I was looking for this response because I was going to post it if I didn't find it.

So many people don't get that their design decisions have consequences and using a SPA is absolutely a design decision.

Everyone's a "pure html/css/js" gangster until they have to maintain state.

Put your state in your urls, or in the user's session model, that's the only place state should be allowed to live :p

Unrelated to the debate at hand, my front-end team's junior members' only known design pattern is drop-all-state-on-refresh-driven-design and it pisses me off.

Basically every part of the website written before their time functions correctly.

I thought it's the other way 'round. Everyone loves their cool new reactive framework, until they have to tackle the state library/library helpers/library alternative/other library alternative/library helper maintainer social media posts.

That sounds like a training problem more than anything else.

Well, the thing is… for any non trivial web app, you do need a framework (spa or Unpoly like). The question here is if you use an existing one or end up writing your own.

I don’t buy the “just use html, js and css”… giving the same developer skills, without a framework that becomes a mess much sooner than with one.

As your code grows you end up creating your own libraries, and your own conventions, and as soon as you (the one with a vision and that knew how to do it) leaves the company and other team members come and go, it ends up being a disaster because there is no documentation, no maintenance, and as you reinvented the wheel nobody used your framework before, so everyone has to start from scratch with it.

Popular libraries and frameworks are popular for a reason. Business wise, it makes sense to not reinvent the wheel and rely on existing battle proven, secure and documented tools.

Just don’t reinvent the wheel. Web applications are not “paragraphs”.

> HTML/CSS/JavaScript are good enough as-is—but nowadays the default browser capabilities are incredible compared to a decade ago.

I'm not sure they remember a time when the choice wasn't "X Corporate Framework" vs "Y Corporate Framework" but "Native Desktop Application" vs. "Website Only Application."

I feel like I'm already accepting a huge set of "dependencies" by choosing to develop a web application, and I have a vast stack of technologies to draw upon in building my application already.

In a modern web framework you still have HTML and you still have CSS files.

The problem is JavaScript and in particular the way that you interact with the DOM: browsers use an imperative API, that this day is obsolete, and makes writing web applications a mess rapidly, and produce spaghetti code difficult to modify and isolate.

While practically all modern frameworks use a functional approach: you have the component, that has an internal state, a function to render DOM elements from that state, and if you need to update the view you don't directly manipulate the DOM elements, but update the component state, that causes the framework to call again the render function that updates the DOM elements as required. That is so much simpler, because you don't have to ensure that the state of the application is aligned with the state of what the user sees on the screen!

I definitely see the elegance of the modern reactive approach, but in practice I'm not sure how much better it really is. I still see spaghetti code, and I still see stupid bugs in production. Doesn't seem to matter whether it's JQuery or Vue. Right now I'd bet that careful architecture and thorough testing are still #1 for making good software.

It does often turn into a weird kind of spaghetti when it comes to things that are inherently imperative. Sometimes hooks make me feel like I’m trying to follow a Tarantino script.

What irks me is the javascript part. You dont need to run random scripts on my system, just send me some fucking text! Make it a touch prettier with css! The javascripts are so bloated, spy on you, are often a malware vector, and offer little real user benefit.

> It irks me that folks don’t think HTML/CSS/JavaScript are good enough as-is

I'm one of those folks. Allow me to explain.

I compare using HTML/ CSS/ JavaScript (or something that transpiles to JS/WASM) to making GUIs in Qt (C++) or with help of QML. I find the HTML/CSS/JS hopelessly complex compared to the Qt with-and-without QML.

Sting based binding of CSS to HTML classes/ids is super error prone. CSS is not really "connected" to the HTML as would be the case in style my QUI with Qt.

Also the widgets (dropdown, etc.) I get in HTML are often underpowered underfeatured, so I have to use widget libraries on top, or roll my own.

There is a reason why modern UI frameworks like SwiftUI or Jetpack Compose look more like React rather than pure HTML/CSS/JavaScript. And it is not because iOS and Android can’t run WASM.

Because this entire industry runs on trends?

I agree with everything you say, but I'm in the camp that thinks that front-end is stabilizing.

I feel many web projects can go a long way with something like NextJS, a few classic libs (eg, lodash/underscore/ramda), maybe a few libraries for handling data if you really need them. The design frameworks (MaterialUI, Tailwind, etc.) are also fairly stable.

Perhaps that's one dependency too many for some?

Next.js is really bad, IMO and perpetuates more bad practices.

Both Target.com and Walmart.com are Next.js apps.

Both utilize SSR to render the pages (view the markup in the network tab).

Both then STILL send the full data model to the UI (check the `__NEXT_DATA__` on Walmart.com and `__TGT_DATA__` on Target.com) because Next.js doesn't quite offer the right amount of control over what to send back (compare this to Astro.js, which does offer control over which data is needed for the client-side binding).

Next.js handling of images is ugly. It creates tag soup for responsive images instead of using native HTML and CSS capabilities (again, compare it to Astro.js and it's night and day).

Their stunt and exaggerated numbers with Turbopack further contributes to fracturing the front-end community and introduces Yet Another Tool instead of plugging into Vite.

> Both then STILL send the full data model to the UI (check the __NEXT_DATA__ on Walmart.com and __TGT_DATA__ on Target.com) because Next.js doesn't quite offer the right amount of control over what to send back (compare this to Astro.js, which does offer control over which data is needed for the client-side binding).

Those two particular customers use `getInitialProps` which allows them to respond which exactly the data they need to render those pages. Can you tell me more about what other capabilities you'd like to see there?

You'll also want to check out our work into React Server Components (https://nextjs.org/blog/next-13#server-components) which addresses both data payload size and bundle size.

> Next.js handling of images is ugly. It creates tag soup for responsive images instead of using native HTML and CSS capabilities (again, compare it to Astro.js and it's night and day).

Have you seen our updated image component? It's just an `<img>` tag, it uses all the native browser capabilities, and doesn't depend on React hydration (it even works with JS off!). Here's a demo[1] and here are the details[2].

> Their stunt and exaggerated numbers with Turbopack further contributes to fracturing the front-end community and introduces Yet Another Tool instead of plugging into Vite.

We've been working really closely with Evan You from Vite to present the data in the most clear way possible. Next time we'll make sure that any project we reference has a chance to submit feedback before we publish. We also contribute to SWC which Vite 4 has shipped plugins for[3]. We're quite confident Turbopack will continue to have a positive impact in the ecosystem.

[1] https://image-component.nextjs.gallery/placeholder

[2] https://nextjs.org/blog/next-13#nextimage

[3] https://vitejs.dev/blog/announcing-vite4.html#new-react-plug...

Is getInitialProps still incompatible with hooks? Does Next.js have a functional way of doing that now?

I don't understand the "right amount of control" bit, there are plenty of options to control what data moves to and fro in NextJS, but the CEO of Vercel has replied to you in a sibling comment; he's going to be able to address your technical concerns better than me.

I'll just add that I'm not familiar with either of those sites, because I'm sitting in Spain and neither operate here, but on first inspection the UX has felt brilliant to me - particularly Walmart's. Everything loads very fast, the search is great, etc. I cannot say if their code or eng practices are a tire fire but the product looks good to me.

> I don't understand the "right amount of control" bit

Try Astro.js and you'll understand. If the data has been used to SSR and has no function on the client side, don't send it to the client.

If two multi-billion dollar, multi-national corporations with multi-million dollar project teams can't get it right in a space where every ms counts, then the average team has no hope.

What you ask for is now possible using Next.js and the new React Server Side components. Check the link in the sibling comment tree.

That's definitely what RSC accomplishes, which I mentioned in my comment.

Also, its implementation details include monsters like monkey patching native fetch which lost me insane amounts of money and time to be found (file uploads with more than 15 kb of data broke everything).

next is nothing more than yet another bloated collage of poor ideas with poor execution, but they have marketing going for them.

Next.js also get into many of my govt's websites. It's the worst in any direction. I can explain why with bullets but so tired of these repetitive well-known reasons already.

Next.js is really easy for developers of all levels to work with though. It’s main benefit is the ease of use, not the optimized client side data transfer.

What I see from Astro.js is a lot of magic. This is great if it works, but chances are it won’t for a lot of people.

A long time ago. It was so painful I resolved to never do the same thing again.

Presumably things have changed in the meantime, but I just don’t see the point any more. Web has won and my experience is there already anyway.

Those are on top of why React is not the way.

it'll be stable when the JS community stops reinventing the wheel several times a year. Every year we have the 'next big thing' and a whole new JS framework and ecosystem thats set to be the one to beat them all.

Fast forward 2 years, its mostly abandoned and upgrading a 12 month old project is a nightmare. That is not stable.

I can pick up a PHP, Python, <insert other language here> script written 2-3 years ago and know it'll work if I try to do something with it. With JS you can guarantee that one of the bajilion dependancies has had a backward breaking change or vanished off the face of the earth and the whole thing falls apart.

JS tooling, and always has been a total disaster, and NextJS hasn't fixed that.

I've been coding my front-ends in React for 5 or 6 years. I don't have any of the problems you describe, I can also pick up old projects and run them without much problem. There was the change from classes to hooks but I still remember classes fairly well. Then there's been NextJS which I've picked up in like a weekend. That's it.

There are new frameworks popping up all the time. Some look very interesting. But React has been around since 2013 and it's a world standard.

I agree that JS/TS tooling is largely a mess, it's why I don't like JS/TS back-ends other than maybe some simple NextJS API routes, or an Express server with something like three files. But on the front-end, React CRA and NextJS (with TypeScript) both have served most of my needs with just a few CLI commands and minimal config. I rarely have the need to meddle with the tooling and I can get up and running in seconds.

I was given a old unmaintained react project to build a pipeline and the only way to run it was on node 12. It would not even build on latest node versions.

That's absolutely expected. Good news is that it's trivial to install whichever Node version you like.

Would this be out of the realm of possibility if you inherited, say, an old Django or .Net project?

"I haven't died playing russian roulette, you should try it too."

The general experience across the industry in a statistical sense is that JavaScript frameworks are a tyre fire best avoided.

I'm yet to see a JS app that doesn't need constant maintenance to remain compilable.

Meanwhile, the ASP.NET ecosystem had like one significant breaking change since like... 2002.

JavaScript itself is entirely backwards compatible back to 2002. If anything, I'd argue raw .NET is far worse than raw JS for backwards compatibility, because .NET has depreciated entire languages like VB6.

To compare something like React to .NET, let's look at .NET libraries and frameworks. For example: Sliverlight, WebForms, WPF, WCF SOAP, old versions of EF, or old versions of MVC. It's not been pretty for .NET, and you're in a bad place if you still have a Sliverlight app in 2022 because it only runs on IE11.

Every language and library suffers/benefits from the onward march of progress. It's disingenuous to claim JS is the only ecosystem that has significant churn.

WebForms, WPF and EF 6 have been ported to .NET Core.

WCF althought not initially supported, the industry has made enough pressure, that most of it is now available on WCF Core.

SOAP libraries still exist.

Thanks to the magic of WebAssembly, you can port that 2002 Silverlight application to OpenSilver, and use it on any modern browser.

Now lets compare it to Qt and QML? They seem to be pretty stable GUI libs

I find it funny that the library that you think is helping to stabilize the front-end is called "NextJS".

It's becoming a standard, and yes, I personally like it. There's plenty of other great choices if you don't like it.

And even some of the up and coming libs, like SolidJS, feel stable compared to the 2010's - they add incremental improvements but keep things that some people really like, like JSX. In the early to mid 2010's everyone was reinventing the wheel constantly.

Everyone says their favorite library "is becoming standard". The rest depends on marketing budgets.

Do you have any real commentary against Next.js not being standard, or only generic snide and feelings of superiority directed at "everyone" but yourself?

I'll share a few facts about Next.js:

- Their showcase: https://nextjs.org/showcase#all. The number of super-scale websites using it speaks for itself (doesn't include among others Walmart, which another commenter pointed as an example of how terrible Next.js, but which I've found to be surprisingly good)

- Explosive growth in the 2021 State-of-JS from 2017-2021, with 91% purported retention

- The core tech, React, is voted by far the most commonly used front-end framework in SO dev survey 2021, and 4th most loved. You would never guess by reading HN.

Many if not most people building an SSG or SSR site in React are going to reach for it. If this does not point to a standard then I guess what's only left is to run in circles and argue what a standard is.

Don't take this the wrong way, but all those impressive figures you've shown don't compare to actual experience. Some of us detractors have 15+ years doing stuff on the Web and we've seen this cycle play out 2 or 3 times. Everything is cool and the best way of animating divs, until it isn't.

I do not like playing the experience card, but when someone tells me React is good and simple, it just tells me they have no idea whatsoever what good and simple has ever been.

And if Next.js is supposed to be a standard, then I might as well quit doing framework at all because it is not a very good library, it just has great marketing, and thrives upon the shoulders of the most common frontend library, React. Sorry to the devs which are often here to PR, but that's how it is. It gets you easily to 80% of the way, the last 20% are really where the issues (bad docs, bugs, constant churn) lie.

I built my first website in the late 90's or very early 2000's - I can't even remember. I also think I knew what simple was when users wanted very little interaction. Then in the middle between then and now, building a website with jQuery was a nightmare. So pray, do tell, what you build your websites or web apps in.

> React is good and simple

I in particular never said it was simple. React, particularly in SPA form, starts creating challenges pretty early on in regards to state management and app architecture. But I have never seen solutions to build large SPAs that don't have pitfalls.

In the SSG/SSR realm, I'd argue Next.js is quite simple.

> don't compare to actual experience

> Some of us detractors have 15+ years doing stuff

> I do not like playing the experience card

> it just tells me they have no idea whatsoever

> it just has great marketing

> Sorry to the devs which are often here to PR

> the last 20% are really where the issues (bad docs, bugs, constant churn) lie.

About 80% of your comment is how much better, experienced and genuine you are than everyone else - as opposed to us schmucks you accuse of doing "PR", you are here to deliver simple, unadulterated truths. I would've engaged with any technical points you had made, but since there aren't many to speak of, I guess what's only left for me to say is that it's fantastic that you feel so good about yourself.

I did not mean to say you or any other Next.js users are doing PR.

I meant the actual Next.js core team.

I know that you are telling your unadulterated opinion, just like I am. I am not accusing you of lying, just disagreeing.

I've heard that the frontend is stabilising since jQuery came out. Now it's the React devs saying it, but this time for real.

Nearly 10 years after the release of the library, React is by far the most commonly used framework according to the 2021 SO dev survey. It is also the number 4 most loved. [1]

I'm a React dev as much as I am a Python or C# dev. I reach for tools that I know I can build in and hire for. It's been years since I use React with a single command line to kickstart a CRA or Next app, and take it from there. Yes, there are pitfalls once you start building anything non-trivial, but so does Django which has been around since 2005 and by virtue of being back-end should be more stable.

Your choice of examples got me interested - because mine would be similar. Would you recommend something else? Besides Material UI I wouldn't recommend any React-based UI framework (Tailwind is only CSS, solid pick with React nonetheless). I would not recommend NextJS without context, but it is to my knowledge the most mature full-stack React-based framework.

As the old saying goes: "We have a new framework that will make the existing ones obsolete." This makes n+1, not 1.

An agency usually deals with different customers, different settings.

What I achieved by migrating dozens of apps to a Angular only frontend, is a platform. Reusable components, devs that can easily switch projects. This is the one and only framework we use, monoculture.

This is a beast, we could abstract away certain processes and developed a No Code Editor on top of the component platform. This Editor handles alone 100+ apps.

No pain what so ever with migrating from Angular version to version.

Best decision ever, so many benefits, even in abstract logical terms, for example, we could simply compile into any other framework by rebuilding some of the components in another framework.

You won't get these benefits, if you fall for fad after fad. Monocultures help in certain settings.

I could see Angular working out great for certain type of projects and teams. I used it for one project for front end and didn’t dislike it at all. Unfortunately I see Angular relegated in favor of React mostly..

Angular is still the go to framework in Java and .NET shops when a SPA is part of the project.

It is kind of changing in Sitecore projects, because they have a collaboration deal with Vercel, and are pushing Next.JS/React as the main framework for headless CMS workloads.

Any project that changes often is going to break often. When it involves dependencies that are constantly upgrading or being added it doubly adds risk of breakage.

Test coverage and being conservative with adding new dependencies/concepts is always a valuable culture to develop for any frontend team working with junior devs. A good CTO/senior dev can clamp down on this behaviour.

I agree with the dependency commentary. Tech should value supply chain. Development is slower but Power comes from ownership. I'm also anti-JavaScript, at least in abundance.

I noticed this in gaming as well as software... engineers always build for the best hardware. Despite everyone knowing that extremes (in the wild) are a minority.

I believe tech needs to focus on building better 4-cylinders rather than expanding cubic inches.

Partly think that's why there was some dismay at Deno's decision to tunnel packages from NPM, a contingent of folk who wanted a reset on the JS ecosystem and (lack of?) culture

This! The problem is also that as our apps grow the server side part of it and the client side part of it grow at pretty much the same rate. For each new functionality added on the backend we end up writing more UI code. This is a problem. We need start thinking of how a UI frontend can be implemented as a separate app completely independent and agnostic to the backend. To the extent that I can simple take the same frontend code and plug it to any compatible backend and things will just work. We need to develop a frontend client that can work with any backend (your app, my app, her app). The UI across all apps is mostly the same and we keep rewriting the same JS/HTML (albeit using different JS libraries) each time we build a new app. This is the problem. Let's start thinking of how we can build a general-purpose frontend client which doesn't work on low-level details (JS/HTML) but on higher level abstractions.

Back in the day we had this mantra - "complexity kills". Boy, did it take us another decade to learn the same lesson - AGAIN.

the primary solution to all this is to remove technologies which are not required and especially those that duplicate what the web as a platform provides (ie works in browsers/runtime directly); for example React has been technically obsolete a few years, yet that doesn't mean anyone understands what to do instead, regardless of whether those technical implementations were ubiquitous 1 year ago or 15 years ago; I find it remarkable to read job listings for up and coming concerns (eg Anduril, BioNTech, etc) basing their platforms on long outdated notions and implementations, which bring with them multiple vectors for risk to security and more (unnecessary) costs to developer productivity, complexity; SASS and npm/yarn are other obvious examples of tech that costs more than it benefits in modern work.

Over the last 3 years I've started to feel more and more vindicated.

I explicitly opted out of most web development when it turned into angular/react and later vue. I've done work in both angular and vue so I've not been able to avoid them completely, but mostly.

And the reason was a fundamental disagreement with their approach. It has _always_ felt to me like people took a good idea (AJAX) and took it entirely too far.

And they found themselves fighting fundamentally with the browser, so the industry's solution was to create new standards such as the history API, when the REAL solution was to just not do what they were doing.

Does react bring legitimate good ideas? Probably, somewhere, but thank god we're starting to see the light at the end of the tunnel.

imo the best thing to come out of it all is typescript.

I use React and Svelte for different projects. I keep things really simple and it's rare that I need to rely on an external runtime dependency (build tools are another thing), if something is relatively small I will code it myself. I have also built my own state management library (not open sourced yet) that is literally exactly what I wanted out of state management, so I don't need to rely on gazillion plugins to make something possible, I just code it myself.

Hiring is my problem. They all want to use NPM/React/any fad or not do front-end at all.