Breaking up with JavaScript front ends
triskweline.de
triskweline.de
A micro dependency system with never ending breaking changes to glue different tools and libraries together - bad idea.
Using un-opinionated "libraries" that don't scale well, but at scale - bad idea.
Technology organizations trying to stay relevant by simply adopting every next hyped fad out there, rather than stepping back to get a bigger picture of what the front-end space actually needs - bad idea.
The list goes on, for quite a long time.
And all of these issues are further exacerbated by an army of junior developers entering the front-end development space, along with recruiters subscribing to buzzwords to hire them.
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.
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)
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).
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 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?
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.
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...
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.
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.
next is nothing more than yet another bloated collage of poor ideas with poor execution, but they have marketing going for them.
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.
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.
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.
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.
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.
> 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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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.
So many people don't get that their design decisions have consequences and using a SPA is absolutely a design decision.
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.
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.
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).
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)
It has huge value as a delivery platform.
Sorry.
Not even that, as there is meta refresh :)
That's where mobile seems to be heading, McDonalds would like you to download their app to order a burger
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.
I believe there is a phrase "path dependence" to describe such situations.
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.
> 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.
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.
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.
Basically every part of the website written before their time functions correctly.
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 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”.
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.
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.
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.
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.
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'm actually very intrigued by the whole "let's take a step back and move a lot of our logic back to the server" approach to modern dev, but IMO when you need more than statically rendered pages, it should look a lot more like htmx or Phoenix LiveView (if you're using a framework) or something ultra-minimal like Slimvoice[2] if you want to go the bespoke route. Not this.
[1] https://htmx.org/.
[2] https://javascript.works-hub.com/learn/a-javascript-free-fro.... https://slimvoice.co/
What's old is new again.
There's an entire generation of developers now who have no concept of the old world. They started with React/Angular/Vue and have no idea that SSR was the standard default for decades. And now it's a "new idea" that is held up against JS development with no understanding of why and how we got to where we are, and the tradeoffs that were made along the way.
It is much faster to train people on a combo js+css framework rather than training someone on backend languages, databases, queues, authentication, scaling + html & css for server side rendering.
Ask yourself: Do "people2 prefer looking at "spinners" or more-or-less animated "page loading..." texts?
Waiting time is the issue, the technology is not.
A server generated page that loads fast beats a Framework-generated page hanging every time!
As for technology:
With "classic" server generated pages "people" will know what is going on (browser indication tht page is loading) and they will know what to do (wait a few seconds at most). With frameworks "people" are left out in the cold with no indication what the problem really is and no apparent remedy or path for solution as a page refresh might interfere with state logic or whatnot bringing totally undesired results.
Bare AJAX itself almost always will perform better than a full page request, but as you layer on additional requirements, frameworks, libraries, etc. that isn't always true.
I think old reddit and new reddit are a great example of this - both are processing the same data and presenting a very similar UX. But at least for me, the relatively javascript light old reddit interface with full page reloads feels much more responsive and usable than the new site.
But I guess that is just me/generational? Ironically, I feel like there are a lot more job openings for front-end than for back-end now, and I'm much more comfortable on the back-end.
Cloud Tech (AWS) which also includes, lambdas, Iam management, dynamoDB, cdk or serverless, API gateway, S3, secret managers etc.
Add to that list the technologies that often get thrown in for extra monitoring testing etc. Jest or mocha/Chai for unit tests. Dynatrace for monitoring. Kibana or something for logs. Some tool for analytics. Github actions for setting up deployment and CI. Maybe you need redis for intermediate caching, etc.
In addition, before you kind of sort of had an intuition of how the data flowed through your basic stack from the database to the web page. Nowadays who the heck knows what's happening. You'll hit some api gateway endpoint which auths through a random lambda who knows where on what server, then it will go hit the actual lambda that holds the function you want to call which may reach out to a database but get intercepted by the redis cache etc etc etc.
Yes modern web dev is definitely much simpler /s.
There’s nothing stopping companies from using the cloud for its primitives (compute and storage), maybe with managed FOSS services (RDS Postgres). We don’t _need_ to go all in on AWS to build a ‘modern’ web application. Yet somehow much of the industry dances to AWS’ tune on how to architect software.
Users wanted responsive UIs and Gmail showed the power of AJAX in the browser. In the mid-2000s, server power, network latency, and maintaining state were the challenges. The UX was more powerful when the client tracked state, only requested the data it needed, etc.
Things have flipped. SPAs became bloated as abstractions were introduced. Network latency and server power is not an issue anymore. Rendering a bunch of HTML is as quick as rendering JSON.
As a vet of the IE7 days, I love this trend. Leveraging the best of server compute and browsers is going to simplify web app development a LOT.
But Ajax is merely a pattern that was enabled by the ‘dynamic html’ that was made possible by having a DOM and JavaScript. It was possible in Netscape years before IE6. I did a production app with Ajax in 1999, using IE4. Before the term Ajax had been coined.
As a secondary effect it also allows for more kingdom expansion. It's much easier to have two teams of five than one team of ten.
That being said, I'd rather manage a team of five good full stack engineers than ten average front/back end engineers. The communication cost of trying to get features out the door with two teams of five is very high.
I started out hand-coding static html pages, graduated to Drupal and Wordpress php stuff circa 2009 (glad that's over!), then worked on a largely server-rendered Rails SAAS in the APM space that I guarantee you've interacted with if you've been in the web game for more than a couple years. These days, I may sling React for my 9-5 but a lot of my personal projects and internal tools are vanilla express apps with very little client-side code.
It's true that a lot of newer devs really don't have a great deal of context for why React & company became the de facto default for building websites and how much we used to get done with largely server-based architectures. I wish we did a better job of teaching fundamentals here rather than bootcamping everyone straight into building SPAs.
However, it's also true that the baseline expectation for web experiences is a lot higher in 2022 than it was in 2009 in terms of the level of responsiveness, interactivity, and overall "app-like-ness", to the point where I think that even with the massive improvements in bandwidth, latency, and web protocols, we still need to accept that there are many cases where just shoving full HTML documents over the wire isn't enough to satisfy user & stakeholder expectations. That's where stuff like LiveView, htmx, and Web Components become interesting to me. The web has evolved, and finally the server-side-application paradigm feels like it's starting to evolve along with it, and these evolutions do feel like they're novel & useful enough to deserve being called "new ideas".
Users get experiences they don't need (nor want). Site owners gets a maintenance dependency they don't want (nor need).
I've built basic CRUD forms with ASP.NET MVC. I've built them with Rails. I've built them with React (+ a hundred random libraries). I've also built interactive "apps" in those languages.
Looking back, the amount of "interactivity" that React adds to a CRUD form is NOT worth the added complexity. But! Right now my dayjob is creating an _insanely_ complex app that you could not have done five years ago with Rails (or, like this presentation is about, something like Unpoly).
I think a problem is that React is just more _fun_ to work with than basic server stuff so devs want to work in it. The added complexity is worth it to have more fun. Maybe that's just me, though. I know a lot of people see React as a hammer to hit every nail with, and I was like that for a long time, but I'm starting to come back around to more server-driven use cases for simple sites.
I've been messing with Fresh a lot lately and it's a nice middle ground of defaulting to rendering _most_ stuff on the server, but you can have "islands" of interactivity that get sent to the client as JS. I'm not sure if it will end up gaining traction, but it's pretty nice.
Rails, Lararavel and similar frameworks are great for crud apps. No need for fresh or demo or svelte or next.js for that.
This stands out to me as one of the cases very few JS frameworks have gotten right. Remix, with its "all mutations are just form actions" approach, is the only one that stands out to me as having done it well.
My own team “modernized” a forum/blog tool used for internal documentation by moving a lot of it to react and SPA architecture and added ton of “app like” features, and I just hate the thing now. The old version, which we still run on some installations, is way, way faster, easier to use, more responsive and more reliable.
But hey, it looks so App-like now…
Sigh…
What? The exact opposite is true: the average web app (including ones like gmail) is far less responsive, slower and heavier than it was 10 years ago. On my M1 Pro, gmail renders at about 20 fps and takes 2-3 seconds to load on gigabit fiber. The web has never been shittier than it is today.
i.e., there's two different steps that each do something that can be called 'rendering': templates to HTML, and HTML to what the user sees in their browser.
I'm inclined to agree with the main sentiment of your post though, and lean myself towards solutions that rely on the server heavily with just a splash of javascript on the front end.
Is it?. I think this expected behavior and increased complexity comes more from designers and product owners than from real actual users.
I, as a user, still enjoy a lot more the old Reddit (old.Reddit.com) than the new one. I even prefer hackernews than many other more “modern” forums that feel slow and bloated. And I also prefer the current GitHub to what I bet it will become the moment they start moving it to React.
The good bits from new reddit could have been added without heavy JS, since those are just CSS+HTML.
Web in particular is very hard to optimize for performance just because of its inherent platform limitations. For applications, people expect as-good-as-desktop. But you can't just download a big .exe and install it -- you have to transfer everything over the wire, which is obviously very expensive. So the big optimizations are reducing how much you need to do that. In apps where people click to new pages and do server-roundtrips for interactive data constantly, you can reduce the amount of time your blocked by caching stuff in the browser. For pages which transfer a lot of data, you must use webpack and similar tools to compress and optimize the various bundles.
The second issue is that when people experience slow and annoying websites, it's normally because of ridiculous ad tracking and subscription popups, which are things most web devs don't really care for. But this is also how the web is funded, so you can't just wish it all away. But this is completely unrelated to client-side rendering frameworks.
Another point is it's not like servers are automatically fast. Sure, more powerful than client computers, but also serving many times more people at once. You'll have to do performance optimizations for servers too.
So my main point is that 1. client-side rendering being slow is usually a red herring. and 2. with any site, you should be optimizing performance. That includes both client and server, both of which can be tricky to optimize
And I do think baseline expectations are higher. For example, on old.reddit.com, when I open a post, it opens a new page. When I go back to the post list, the whole page reloads, which takes time (and I'm on a gigabit network). It's a lot faster in new Reddit, where everything happens on the client. At the same time, I'll certainly agree that it's very poorly optimized in many cases. I think there are some memory leaks. It's a solvable problem, though. It's not bad because it's using React; it's bad because they haven't taken the time to optimize its performance.
And talking about GitHub. The new client-side nav is a lot faster for navigating around a codebase than the full page reloads it used to do. It makes sense, that's a huge part of the page you can just leave there. It's a performance optimization to use more client-side rendering in this case, pretty clearly. Fewer round trips to the server (very slow), less data to fetch overall because half the stuff on the page doesn't need to change... etc.
And products like Google Sheets and Google Docs have also really pushed hard on client-side interactive features that were not common 10+ years ago, but are more common today.
And talking about hacker news... here are some problems hacker news has that modern websites typically don't have:
- Form submission weirdness, particularly around the back button
- Have to go to a new page and reload the old page when writing/editing a comment. More round trips to the server.
- Styles are poorly optimized for visibility on both desktop and mobile.
- On mobile, touch targets are very small.
- Form markup is limited and opaque (e.g. most people expect to have a toolbar for rich text options).
I work on some old ColdFusion apps.
Some aspects feel very modern.
OTOH I have really surprised some PMs by producing a Perl cgi wireframe site during the course of the meeting where we designed the wireframe so we could actually try it. It's a skill more devs should really have in their back pocket.
http://triskweline.de/unpoly2-slides/ http://triskweline.de/unpoly3-slides/
I'd say 95% of the apps we build are now based on Unpoly, the rest on React.
We now believe SPAs are not a good default for the type of apps we're building. We're still reaching for SPAs when requirements demand high-frequency user input and optimistic rendering, e.g. for a chat or online game.
YMMV!
HTMX 0.0.1 was released as "kutty" in May 2020. That was its first release. It wasn't a thing in 2016.
intercooler.js started in 2013
https://github.com/bigskysoftware/intercooler-js/commit/62d3...
I've recently done some web development for the first time in 12 years, and I was horrified at all these pointless frameworks that break every usability win web browsers have made in the past 20 years, cost extra bandwidth and have atrocious performance. Like, why? Can web devs really not learn the 4 functions that make up the websockets API? Do they really need a special framework named after a coffee bean?
This kinda crap is why the gmail tab uses a GB of memory.
This is what is so shocking to me when HN spends such an absurd amount of time rallying around this idea that frameworks are the reason sites are bad. Mind you, I do think a lot of them are misused, but 99.9999999% of poor websites aren't because of the framework chosen.
While IDLE, the gmail tab uses 10-30% of an M1 CPU core.
That stuff is not down to tracking - it's because the damn thing keeps messing with the DOM, because it has some insane structure where javascript controllers are attached as strings to DOM elements, because it uses about 100 divs to render every row in the list of messages, and because every message is nested literally 15-30 layers deep in a pointless tree of divs.
I am sorry, but web frontend is an insane dumpster fire.
I have very clean mailbox, though.
I do have a lot of emails, but I think it should only have to worry about 100 of them at a time, so I don’t know why it’s different for me and you. It is possible that my account still receives beta features, because I used to work there, but I remember it being like this for multiple years, since the new gmail came out.
I’m not arguing for using hundreds of divs, because that’s a sign of engineering insanity imo, but it’s not a performance issue. You can create a static page with thousands of them and (likely) see that it still doesn’t use 250Mb+ neither idles at 30% cpu core.
Added:
damn thing keeps messing with the DOM … web frontend is an insane dumpster fire.
Totally agree with these parts.
—————
… I just tested 50 div-rows with 200 spans containing numbers from 1 to 199. Total 10k elements, text doesn’t fit on the screen. Bootstrap css+js is imported via CDN.
Mithril.js implementation uses 50Mb of RAM consistently.
A static page with the exact same content uses 71-96Mb depending on the run.
Both use 5-14% cpu when I shake my mouse and 0% when I don’t.
Refresh is significantly faster with Mithril, idk why, probably because static html parser is slow. (Opera, Windows 10, no extensions).
With a single span per row instead of 200 both take 23Mb.
Removing bootstrap from the head inconsistently frees 0-2Mb for both.
From what I understand (no special insider information) React is essentially non-existent inside of Google, and NPM is not even available to engineers (be default)
You have to remember that a large chunk of "web apps" means "electron apps" which are absolute bloated pieces of junk next to their desktop cousins.
You also have to remember a 'framework' typically doesn't stand in isolation - tens, hundreds, thousands of dependencies typically lurk.
We all agree tracking junk makes it even worse, but the whole thing is already overcomplicated before you get to that point.
While this is true, at least by having a large number of people commit to the same set of dependencies, you stand a higher chance of complications between those dependencies being ironed out, either directly by the framework maintainers or by the user base of the framework.
Meanwhile most of the industry is using React, which is actually pretty well engineered and perfectly fast (you may well find yourself using a slow React app, but that's not React's fault).
P.S. Talking layer of DOM nodes, I actually did a few samples of this the other day. Gmail has 34, which was by far the deepest of any website I checked and probably isn't helping it's performance.
That makes sense, but I also recall it was about trying to use the same language on the server as the client. And it worked as well as the efforts to use JavaScript is the server. Which is not to say it can't work. There are a lot of traps there, though.
I also have a pet peeve with the Roboto font family developed by Google and used everywhere on the web. But I’ll admit that it is a fine font face for its purpose, just very boring and used way too much.
Is there a tool for this? I’m kind of wanting to check my site now…
function getMaxNestLevel() {
var i = 1, sel = '* > *'; /* html > body is always present */
while(document.querySelector(sel)) {
sel += ' > *';
i++;
}
return i;
}
console.log('total nodes', document.getElementsByTagName('*').length);
console.log('max nest level', getMaxNestLevel());[1] fun fact, you can shorten this to “ol.reddit.com” which is nice because it only requires one hand to touch type “ol.” and get an autocompletion. I always thought reddit was a great name because for right handed users, “redd” could be typed with the hand that would typically stay on the keyboard and would 100% get an autocompletion. Alas, most users are now on mobile.
I use RES[1] to force the old layout (along with many other things).
It isn’t. Ironically things like memory leaks are why pages use a ton of memory and in my experience everyone coding from scratch results in more of them, not less.
Try and keep your posts factual.
Actually no, and the real reason is organisational.
It has been a pattern for years now for front-end projects to consist of multiple, independent modules developed by separate teams - banking apps are a prime example of this.
Gmail appears to have went the same route, because it now sends over 200 requests when loading - a hallmark of a highly modularized front-end.
The organisational benefit is less knowledge required per developer, which in turn brings other advantages like resistance to turnover.
Somehow, software on embedded, the kernel, graphics, flight control, etc. is all developed by equally large organizations and while they’re far from perfect, they produce far better software than the vast majority of web UX organizations.
Something about web dev is uniquely terrible, in addition to the common factors you mentioned.
Meanwhile I can't get my laptop into sleep mode at times because such a seemingly simple feature can't be reliably implemented for some reason and it's been like that for years - that's just one out of many instances of non-web software being terrible.
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. Unless you’re just building a small landing page or todo app.
I haven't written Java in years so I can tell you with authority that Java 17 is terrible and we should just go back to the good old days of J2EE.
Not for nothing, but when I wrote a couple of web apps recently (most recently a market monitoring tool and a physics simulation in wasm and webgl for rendering), I tried different frameworks, but always ended up dropping them. The end result is snappy and fits in kilobytes, and the freaking back button works.
I did of course use some libraries for rendering things like graphviz. I am not a crazy person. But I fail to see what value e.g. react.js* adds, or why there are libraries to wrap websockets.
* For react specifically, I can actually imagine scenarios where it’s useful, but in practice, 95% of places where it’s used should have probably just been HTML with some minor JavaScript for bits of interactivity.
You don't mention maintainability in your examples, purely things like back button support and disk footprint. They're just pieces in the puzzle.
This is already the direction that Remix and Deno’s Fresh framework seem to be taking, at least spiritually. Isolated server-rendered-first approach and only bare minimum JS loaded for fragments/islands that need to be interactive beyond what can be loaded on pageload.
The html attributes vs JSX style templates is really a matter of taste IMO. Although I haven’t used htmlx I get the feeling it would be limiting for more complex cases and involve a lot of hackery or pigeonholing complexity better served by straight up Typscript.
it does, however, have an extensive event model to hook into, including pre and post request processing:
https://htmx.org/reference/#events
as well as an extensions API:
https://htmx.org/extensions/#defining
for client side scripting, I think you are talking about hyperscript, which is definitely more speculative than htmx, but I wouldn't call it half baked: a lot of people are using it successfully in production
a less-esoteric alternative would be to use alpine.js, which is similarly embedded but uses plain ol' javascript (and offers reactivity as well, hyperscript is more of a pure event-driven language)
<div x-html="(await axios.get('/some/html/partial')).data">there are a large number of events
and the extension mechanism has enabled a diverse number of extensions:
generally I consider htmx to be on the high side of JS libraries when it comes to events and hooks that can be used
I think it's very good and for me, the best of the bunch. I'm moving a very large app to it (from old school RJS) and it seems to have thought of everything that I need.
It makes sense for a subset of applications that require connectivity but many apps or tools should be able to work offline or without a constant connection.
It is a way to avoid writing backend APIs.
If you’re sending every click or every key press then it’s not the tools fault. I agree though, that this should be better explained in their docs.
Never was allowed to put it into prod - "didnt need it". Oh well.
Perhaps, what is most interesting is that it took nearly 4-5 years for the front-end community to collectively come to the conclusion that SPAs are not _always_the answer. I don't think the zeal for SPAs came from a bad place either. I can remember how poorly ASP.NET and other frameworks of the 2008-2012 era packaged an overcomplicated way to pass data to view layers. There's lots of curmudgeon-ining from non-frontend folks but, in my opinion, the lack of performance and ergonomics with existing frameworks, combined with the newness of Node.js is what brought about the explosion of tooling and frameworks.
There is a place for SPAs, though. VS Code, Spotify, and other apps that need a desktop / browser experience to feel like a mobile app are great candidates. Twitter, for example, shouldn't be a SPA or SPA-like application. I find that it frequently over-caches content and will randomly refresh my feed at times while I'm browsing. It feels as if a simple web page that needs to deliver more JSON responses as I scroll is trying to do too much.
But I haven't used stimulus/turbo myself. I'd be interested in a compare/contrast between Rails' Stimulus/turbo and "Unpoly" covered here.
There also seem to be a number of other non-Rails-related offerings in this space too. They seem to be really multiplying, which I think shows the exhaustion with JS front ends and desire for things in this space (I am not sure quite what to call it). But I wonder if we can converge on one or two instead of creating more and more. One of the benefits of a popular layer is that you can start building share-able re-usable solutions which compose with it -- you can find lots of solutions for certain things for React, like you used to be able to for JQuery, but splitting between stimulus/unpoly/htmx/etc...
I setup a demo, rails7/mysql[1]/turbo/docker - one command setup you are playing with it. https://github.com/james-ransom/rails7-on-docker-mysql. Give me a star you have a friend for life!
* not Postgres!!
I wonder if there's an update on how Unpoly has worked out for them or anyone else.
The official docs are decent:
Isn't there any format that is a real alternative to HTML, which is truly interactive, lighter than the DOM, use text as a mediu, is multi usage and platform agnostic, can use whatever scripting language, and be easily rendered?
It's not another new format, it's just that a new format is needed to make things simpler.
I have zero patience when it comes to learn angular and its framework model thing. I don't want framework, I want formats and protocols.
I don't even know gopher but something new and fresh and different is really needed. Maybe as long as it's used in a controlled environment for internal/pro software.
I also miss Flash.
This is becoming untenable. The web has only gotten more and more difficult for novice users and developers alike to publish onto. That spells doom for the web in the long run.
I wish we had a clear path out of this trap.
I don’t think it’s possible to couple the interactivity and visual layout in a single language and have it make sense. We can certainly do better than JavaScript, HTML and CSS but I think there will still need to be at least two languages to describe layout and interactivity.
i = 1
def click(event):
i += 1
g.Window(
g.Frame(title=“Hello”,
g.VBox(
spacing=10,
g.Label(
“i = %d” % i,
expand=True
),
g.Button(“click me”,
click=click,
)
)
)
)
The example above is brief due to forum limitations, so yes, it doesn’t include lifecycles or the whole implementation of a rendering loop. But the context of that comment was using one or more languages for building interactive hierarchies of widgets, and not the topic you brought up, so it didn’t even have to.
c = new Container()
w = new Widget()
c.add(w)
w.addActionListener(
…200 bytes of a functor boilerplate…
)
Am I missing something, or maybe you meant something else?
The question is, how can we not end up in a spaghetti ball? Your scripting style alone brings nothing to the table.
I would look up to something like Elm, which does answer OP's question.
It's a no-html, widget only web framework that's been going for at least 10 years.
People will roll a gigantic create-react-app mess for the tiniest of frontend projects. Yes, it's an instant codebase! But that's all code you have to maintain. Stuff like hotwire and htmx can't come fast enough.
There's a clear trend back to the server to some degree, so on the margin what I'm saying seems to have some basis in many people's experience, where the sweet spot of many apps does not require the added complexity of SPA's or lack of expressiveness of writing so much app code in javascript, building distributed systems, or having to use Firebase style non-relational database services. Moving much of this to the server reduces some of this complexity often with productivity gains.
???
Modern SPAs are typically written in TypeScript which is very expressive and using frameworks to structure them.
One may like or not like the tooling around it, but the language and code is just as robust and clean as any backend code.
That reason alone is why I prefer having the server doing the bulk of the heavy lifting. It reduces variables in the most functional parts of the app and reduces my need to try to herd users into using particular browsers.
It is still SSR but it's much much more than just going back to 2005. Combining the lessons of the last 15yrs with the as much of the past SSR world as possible. It's not simply throwing it away and regressing to the old ways.
Essays on HTMX website also help a lot:
> Site doesn't load properly with javascript disabled
They should put their money where their mouth is
- Site does not support HTTPS https://triskweline.de/unpoly-rugb/#/ => breaks
The back button has evolved alongside SPAs, and users mostly don't expect or want their back button to take them back through the hundreds of small state changes they've caused by interacting naturally with a UI.
After years of not knowing what to use because the libraries I've used 2 years ago are no longer maintained or their APIs changed 3 times since then, there's now Next.JS which seems like a well supported, batteries included, opinionated framework with good documentation...
with vite and esbuild on the rise, the days of fiddling with webpack and other complicated build configurations may soon be behind us...,
typescript vs. flow seems to have ended with typescript being the clear winner and having great support in most libraries, frameworks and IDEs... (although I'm a bit scared that the JS native type annotations proposal may again fragment the typing world here...)
browser-side APIs are no longer evolving so rapidly, IE11 & EdgeHTML are dead and there aren't that many features/bugs specific to Firefox/Chrome/Safari anymore...,
Supabase could be enough for a simpler project where you know you won't need any advanced features.., I wouldn't just start with it if I knew the project's gonna get huge in the future, but I did a couple of smaller projects with Firebase alone..
Is it really? I have the exact opposite opinion. I mean, I feel like the industry has pretty well standardized on React in Typescript for the front-end on web apps. Sure, there are other technologies that do different things (e.g. Svelte, and someone else mentioned Phoenix LiveView), but for the standard "I'm building a CRUD-focused web app", there are simple choices to make and it's easy to "do the right thing". I contrast this with 2016, when things were still in flux so it was much easier to make what turned out, in hindsight, to be the "wrong" choice (e.g. Angular or Flow). Plus, tooling support is much better now.
I mean, this is obviously an extreme example, but COBOL is also still used extensively in the enterprise, yes it's still not really used for any new projects.
React is just utter trash for organisations where maintainability is a concern.
Inevitably you want some computation to be close to the source data (for efficiency) and some other computation to be close to the point of interaction (for responsiveness). It's not an either / or proposition. You can do both. And phones and browsers can do a lot locally these days. So there's no need to pretend that it is still 1999 in terms of browser capabilities. They can do so much more now.
Instead of AJAX, we now have companies like Tailscale doing all sorts of funky networking stuff in a browser. Likewise, people are running entire 3D games, photo and video editing tools, or design tools like figma, etc. in a browser. All enabled by WASM. Most of that stuff does not involve a whole lot of css, javascript, or html. That stuff is increasingly optional. Browser application development and desktop application development are finally merging after being considered completely separate things for more than 2 decades. It's all just application development. It may or may not involve talking to servers via a network. You don't have to limit yourself to HTTP when doing that.
I'm just starting to recover from my previous work. I had to maintain migrate and add features to a legacy system (built in 2017) which had initially a GraphQL api and a SPA, but that was later split in 12 microservices (with cycling dependencies because hey why not) and 3 Big react applications, all of that in Javascript + Typescript (added later with all the gradual typing stuff that makes you think that your code is correct).
All of that to serve 300 monthly users between 35 and 50 years old, who just cared about filling forms here and then and have some charts over data. 0 rocket science.
So far I remember history going like this: - 2010 Clean SSR with rock solid boring technologies and some vanilla JS where it made sense, I remember page load where crazy fast and you could not feel the need for an SPA. - 2012 NodeJS arrives. It came to save us from slow blocking IO apparently (??) - 2016 React arrives. It came to save us from boring old SSR apps - 2017 All React + SPA frameworks (in house often) - 2017+ Someone has the brillant idea to do SSR with React. "It's a revolution" - 2017 GraphQL arrives. You are saved. - 2020 Nextjs arrives. You can now do static generation for SEO and SSR and apis ! That's great. Thank you Next ! - 2022 Someone wants now to do Server Component that will make your page load going insanely fast (which we already did in 2010 when we carefully loaded vanilla JS at the time)
I learned a bit of ASP.net core recently, and I think that boring razor pages are still relevant.
I remember my first lead in 2010 telling me that ORMs and SPA where completely overrated. I didn't agree with him at that time. Now 12 years later I think he might have been correct.
I'm not saying SPA have not their place. Some apps can't do without it. I'm saying that we are victims of "hype driven development" which involve having some trendy hashtags in your resume and convince your manager that you have seen an incredible new tech that will make the business incredibly wealthy. Except it does not and you end up with a legacy system that nobody wants to maintain because too complex.
Maybe like Jonathan Blow stated in one of his videos, we make a confusion between going forward and progress. Now all the new kids learn React in some boot camp or online but have no idea how to implement a map function. And I feel old and grumpy. And tired by all this.
I never understood why the answer to the "frontend problem" was to do more things on the frontend.
Writing yourself and API to talk to your own backend is silly nonsense, yet somehow it has become the norm. I loathe it.
Thank science for Phoenix LiveView and the various frameworks that followed in its footsteps. Also htmx and the like.
Came to a similar conclusion lately. It's a superior, cleaner alternative to traditional MVC controllers. Currently building a side project with Razor Pages + HTMX.
This SPA unnecessarily approach eats up so much time, it is not rare for things to take weeks instead of days compared to simply rendering templates on the server side in a better language than JS.
It should be a simple thing to understand: Use the right tool for the job. Not JS for everything, just because of hype. But I guess part of the issue is the mentality of some frontend people to only learn JS, so they are incapable to going for the mixed approach.
At this point I'm getting a bit tired of backend people claiming that the cure to the frontend mess is a big library that pretends to be html.
You should learn to use browser - there is right click on back button
I once worked with a team where the devs didn't know what hibernate generates inside the database, it was shocking how much trust is in these layers of abstractions.
The concept of unique and foreign key constraints, sequences or indexes was unknown.
It may be cleaner to you and written in the same language you are familiar with, but some problems simply aren't that easy to solve.
A SPA is a piece of an overall architecture and these frameworks are still just a piece of the overall architecture.
Almost all of these frameworks can/will assist in strict standardization. Bootstrap is a good example. BS with a well designed style guide is a blessing, without it's the wild west. Angular, React, Vue are all very useful (back button included) if thought out and as part of an architecture.
In the end, they get you much further along with support, than a team could do with vanilla.
I'm always interested in ways of building partial page fetches, dropdown menus etc in a way that is thoroughly tested to work well with common screenreaders.
I'd love to see a frontend framework that includes detailed documentation (and ideally video demos) demonstrating how effective their ARIA screenreader stuff is.
Seems like it depends on how you code the html/templates not how they are rendered?
Unpoly takes special care to always move the focus to the next relevant element in an interaction. E.g. when a link updates a fragment, the focus is moved to that fragment. Or when an overlay is closed, focus is returned to the link that originally opened that overlay.
More details can be found here: http://triskweline.de/unpoly2-slides/#78
Feel free to install a screen reader and play with the demo app (https://demo.unpoly.com/).
The slide said
> DEMO OF SERVER-SIDE APP ISSUES
> Link to demo app (https://demo.unpoly.com/)
> (press Start Classic on first page)
but there is no “Start Classic”?
I completely get that reason. Any front-end framework app is on live support in a few years. It feels like the equivalent of buying a cheap refrigerator that will break in 4 years, that is easier to get a new one rather than try to fix the old one.
I've been working on a Ruby framework with all the fancy stuff (reactive VDOM, hot reloading, scoped css) but it's 100% server side. Imagine React, but with Ruby and Haml instead of JS, and all logic runs on the server.
The GitHub link can be found in my comment history. It's not ready to be used for anything serious, but I think it's an interesting approach and maybe there is someone who would like to play with it.
I have (and still do) written SPAs that only use Angular and nothing else. I don't even have NPM installed.
I'm loving it so far. The pages load instantly, they're extremely lightweight, and all the state is on the server where it's easy to debug and all strongly type checked with Rust. I called my little "framework" curmudgeon, because, well I'm under no illusions about what I'm doing. Get off my lawn with those SPA JavaScript frameworks.
But the bigger thing is it's just for me, because I'm the only one working on it right now. If the project is successful and I hire people one day, they'll put up with it because I'm the boss :) Meanwhile I'll enjoy working on frontend again, something that hasn't happened in years.
If you have a fully client-rendered SPA (not saying an SPA is the only thing you should ever build, but many of the complaints seem to be aimed SPAs), then why do you still need Models, Controllers, and Views on the server? Or Routing for that matter. Many modernish SPAs would handle all the routing client side. So your backend complexity might look more like: Asset Packing, API, Authorization, Dependencies
So you've moved some of the complexity from the server to the client. You may or may not like that, and there may still be a net increase in overall complexity, but it's not the same as necessarily suddenly 2x complexity.
Also I don't know what Authorization is doing in both graphs. Or why Virtual DOM is there - yes you might be using a Virtual DOM, but it's presumably part of one of your dependencies, and not something you're interacting with directly or maintaining. Also what is a "Controller" in React? React (and similar frameworks) don't fit neatly into the MVC paradigm. I guess it's more like Components + Models? Although the Components aren't always cleanly separated from Models/business logic, which can be a strength and a weakness.
It's a never ending cycle.
SPAs are a pain in the ass, like all distributed systems are, but they're also the most flexible and you don't need to reinvent half your framework or use dirty hacks if you have to do something slightly out of the beaten path. They're not the problem.
The real friction comes not from where you put the code but from the fact that you have to use different languages with different ecosystems. I'd claim most of the arguments against SPAs would suddenly disappear if one could write most of the code in whatever, compile to WASM, and slap a generic JS bridge on top.
[1]: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/fr...
We started before Promises were standard, before composer and NPM. Before Virtual DOM. Back when we started, there was CodeIgniter and Kohana and jQuery (anyone remember?)
Along the way, we kept the vast majority of our code in-house. We didn’t want to pull in libraries or updates unless we understood their code.
Looking at the latest and greatest, we were often wondering if we did the right thing. Some developers (especially JS) used to chastize us for not using the latest techniques like “two way bindings” of Angular 1.0 or JSX of React
Then - lo and behold - Angular 1.0 is totally rewritten and all those concepts are redone. Over and over. And people come around to our way of thinking. Web Components and Templates appear. Shadow DOM.
Our way of thinking is: use standards for HTTP/REST, HTML, HTTP, JS, CSS as they were intended. Every concept should work well with all the others.
Result is at https://github.com/Qbix/Platform if you want to give any feedback. We have been using it for ALL our projects since 2011.
Front end frameworks are an anti-pattern. They hviolate DRY principles and exemplify premature optimization.
They did not grow organically out of the open source community because they solve a problem only a handful of companies on the planet have. They had to be pushed into the dev mind share by the mega cap tech companies. Unfortunately, they’ve been successful over the years.
Even projects from a few months ago can be become unusable unless you are willing to sit down and spend a couple of hours fixing the problem. And don't get me started on packages that have been abandoned altogether but are like glue to functional software.
(I am talking about npm)
You have to make smart decisions when adding dependencies based on how mature and supported is it. This often means sticking with the big names even if the little project has more hype.
I'm doing something similar to HTMX or HotWired, but with 100% vertical ownership. I posted about this some time ago: https://www.adama-platform.com/2022/06/26/making-html-the-be... ; where I am at today: https://book.adama-platform.com/rxhtml/ref.html
The core thesis is to turn the browser into a RIP terminal ( https://en.wikipedia.org/wiki/Remote_Imaging_Protocol ) to some degree where the server is 100% in control like a BBS/MUD. As an example app, the main IDE uses it, and it's great how lean everything is.
I'm enjoying going my own path.
It's no coincidence the most popular frameworks are analogous to video game game engines. They both listen to user input, calculate the input against the state, and then render the results to the screen. It's also no surprise UIs are moving in the direction of becoming "gamified" (actual term), and adding elements that guide the user/player's attention. What this means is that we can expect UIs to increase in complexity until they match game engines, at least in terms of how it models interactivity. I should add, there will always be the static, simple pages, but web apps which are currently considered complicated will certainly keep evolving by providing a more immersive experience.
Nobody cares about "interactivity" or "immersive" experiences except the devs who make them. People want to get their shit done as quickly as possible using software that feels simple and works as they expect the first time.
A SPA might be the best way to achieve that. But often it isn't.
edit: i should add I'm not saying it's ALL going this direction, but certainly the big apps with lots of users.
I think this is probably true of many (not all) of the kinds of things you are calling "interactivity". In any case, the reasoning isn't sound, even if you think your conclusion is.
However, I migrated to react-router 6.4 and it has a very similar concept of embracing web technologies and partials can be defined as an outlet of another page where only the data for the partial and dom for the partial is loaded if sub sub-tree is navigated in. They say they took this idea from emberjs.
I felt the same way as the authors of unpoly and many in this thread looking at most UI frameworks until I stumbled on react router 6.4, and it very much enabled me, a primarily backend engineer, to be productive in the frontend. I highly recommend it to people who are trying htmx but want something that is more IBM "No one ever got fired for picking react"
Build it without frameworks? Absolutely! Build with HTMX? Makes sense to me. It's a light-weight and isolated extension. It would be great if such partial load semantics was added to the web standard.
Isn't the core question whether the web client is stateless or not?
My front ends have been very stateful for long time. But I build desktop equivalent web apps. I jumped on the AJAX track in 2000 and never looked back. My state has been represented in XML ever since. I sync with server via "updategram" semantics (borrowed from SQLXML), and transform state into HTML with XSLT in the browser. I use no frameworks or libraries/ Has served me very well for 20 years and likely will until retirement.
If it's not an explosion in JS/CSS from frameworks, it's the content image/video size.
Upside is that a "fast" user experience is easily achieved by defaulting to first principle JS capabilities of the browser, and delivering compressed content from the CDN edge.
What's with this htmlx shilling anyway? If you want an app, just use JavaScript; what's the point of arbitrary syntactical barriers between page content and logic, except for maybe CSS done by UX experts - though if you're bad at CSS then why tf are you into web frontends anyway?
If OTOH you think about content-heavy sites, document-oriented workflows, and publishing (ie. what the web was originally made for) then just use a competent markup processor. HTML is based on SGML after all, giving you templating, markdown processing, stylesheets, pipelines, toc and search indexing, and whatnot; there's a wealth of SGML/XML-based tools available.
The idea was that you write in Web 1.0 and immediately get a Web 2.0 front end because it just updates what it needs to.
I still think this is the holy grail of frontends:
If you look at the hottest trend of the "island architecture". New frameworks like Astro (https://astro.build/) and Fresh (https://fresh.deno.dev/). They are basically what are you describing. All SSR but with dynamic parts. Seems like these "islands" by their nature are less entangled than full SPA.
What's the solution to such a use case?
Btw, client can run rust in WASM, so no reason to keep javascript in there either!
That killed my interest instantly.
Something similar to how we’ve had C standards - we had c99 and then c11 (followed by c17)
Although, this solution feels to be heavily inspired by https://hotwired.dev/ Is there a reason, why new framework (with some extra cool features) have been developed as opposed to contributing to hotwired/turbo frames?
Everyone jumps on the latest hype, going from either server to front-end, or nowadays front-end to server side, without thinking where your application resides on that scale.
(I'm using Nuxt on a project, but not finding v3 to be as stable as I expected...)
2. If you’re already familiar with Vue, and have no problems with it, the only reason I’d stray is because stuff in JSX-land is getting around to addressing many of the problems people (rightly or wrongly) complain about here. Weather React Server Components, Qwik which ships minimal JS bundle and data by design, or Solid with recent support for partial hydration… the component story being good for UX is increasingly compelling for JSX. I wouldn’t recommend any of these in particular unless you share more about how you’d prefer to develop.
3. If I were to recommend any meta-framework it’d be Astro. I’d have stronger recs for Solid Start but it’s explicitly not stable at present. Astro also has the benefit of being UI library agnostic which is a good gradual story.
4. Take literally all of this with a grain of salt. Part of the reason all these tools have a bad rep is from trying stuff when existing tools are imperfect but serviceable. Happy to share some ideas of where to look, but if I’m choosing anything for my current projects under maintenance I’m starting with how they can be adapted and reconfigured to solve whatever problems they don’t already solve. I’m only even looking at other tooling because there’s serious gaps in the existing setup.
1: Porting a legacy XML-centric project away from proprietary server dependencies which take ~8 min to build and has gobs of incidental complexity and tons of performance problems… to run in a browser really fast. It took a few minutes to figure out how to set up the project to load static XSLT assets as ESM modules, as well as dynamically loading XML payloads both from local fixtures and as library input. Builds are instantaneous and runtime is fast enough I can sell running it in a headless browser as a major incremental improvement. I can probably also sell scrapping a whole server target, or at least its persistence layer, because it’s fast enough the primary responsibility (caching) is either moot or solvable in the browser.
Server-side DOM mutation is deeply interesting, but I don't think it can be grafted onto existing server-side frameworks. Someone will need to rethink the MVC model with client-side state in mind.
It is not a framework to organize your own JavaScript (like react, vue, etc). It is a framework so that you don’t have to write JavaScript in the frontend.
Of course it is written in JavaScript, because that’s the only thing that can run on the browser.
This is absurd statement.
It doesn’t mean that the OP framework is bad or that SPA idea is not generally abused etc and doesn’t call for some changes etc.
It’s just a ridiculous and somewhat arrogant way to promote your yet another fancy js thing.
I think a Nim backend with this would be great.
When the browser can reason about your site it opens up nice cool stuff like right click to open in a new tab, bookmarks always working, fast load times, caching, etc.
The old demo app focused on the downsides of classic multi-page apps (MPAs), i.e. the reason the world moved to SPAs all these years ago. In an MPA clicking a link loses all transient state, like focus, scroll positions and unsaved form state. This can all be solved with updating fragments instead of full pages, while still keeping rendering logic on the server.
intercooler.js started in Dec 2013:
https://github.com/bigskysoftware/intercooler-js/commit/62d3...
unploy started in Dec 2014:
https://github.com/unpoly/unpoly/commit/6d1691815b9c89f10e9b...
Can you add (2016) to the title? Thanks
I wonder what the dependency pictures on the earlier few slides would look like today.
There are ways to keep things simple with the front end, only add js for the things where you want instant visual feedback. It requires a little pushback on the part of the dev team, against UX and Product management.
There are fourteen competing standards ...