Live data from Hacker News

Breaking up with JavaScript front ends

triskweline.de

341–350 of 433 posts

Re: Breaking up with JavaScript front ends

#341
post #319

Earlier quoted context omitted.

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 id…

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,…

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.

Re: Breaking up with JavaScript front ends

#342
post #322

Earlier quoted context omitted.

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…

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.

Re: Breaking up with JavaScript front ends

#343
post #305
post #288

Earlier quoted context omitted.

> This kinda crap is why the gmail tab uses a GB of memory. 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 f…

You can say that about any engineering problem and be right 99% of the time. Because it’s always true, it’s not a super useful analysis. 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…

There's a lot of great software that's not written by people who work with web development. There's also plenty of utter garbage software that's not written by people who work with web development. I don't think web development sticks out enough to make it unique

Re: Breaking up with JavaScript front ends

#344
post #305
post #288

Earlier quoted context omitted.

> This kinda crap is why the gmail tab uses a GB of memory. 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 f…

You can say that about any engineering problem and be right 99% of the time. Because it’s always true, it’s not a super useful analysis. 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…

I think you judge it like that because errors in UI are usually the most visible.

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.

Re: Breaking up with JavaScript front ends

#345
post #19

Earlier quoted context omitted.

I both agree and disagree with this take. 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…

> However, it's also true that the baseline expectation for web experiences is a lot higher in 2022 than it was in 2009 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 slo…

I mean, the broad problem is web performance. I think that client-side rendering is a red herring, and really not the main problem. I think part of that issue is that developers don't spend as much time optimizing performance, because it's less clearly necessary up front.

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

Re: Breaking up with JavaScript front ends

#346

Earlier quoted context omitted.

React is used a lot, but it is certainly not the standard. Angular is still used extensively, especially in enterprise

I'd still argue that React is very much the default for new applications where legacy interop or existing team familiarity isn't a factor. 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.

I'd say you are still wrong. Anecdotal evidence: I have recently started on a new green field project in a large enterprise and it was Angular.

React is just utter trash for organisations where maintainability is a concern.

Re: Breaking up with JavaScript front ends

#347
post #210

Earlier quoted context omitted.

Sounds like hyperscript. Look at this hypothetical PyGtk example: 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, ) ) ) ) Desktop frameworks could do this for decades instead of Glide XMLs or manual setup, but they didn’t.

Nobody cares that you can build up a DOM differently, that's decades old. What matters is: how do changes behave? Your example shows nothing of the complications of lifecycles or state-render loops.

Respectfully, that isn’t decades old.

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.

Re: Breaking up with JavaScript front ends

#348
post #308

Earlier quoted context omitted.

Well google use all of their own internal 'frameworks', so you can't really use their web applications to judge the rest of the web.

This used to be true but isn’t anymore. For a while they pushed Angular, nowadays I think a lot of teams are using react. GWT is long deprecated and gone.

To be fair, gmail was quite great at the time of GWT. Not sure how much use their Clojure “platform” still get, but I think it was very ahead in terms of maintainability of large js code bases (or even ahead as we have it now)

Re: Breaking up with JavaScript front ends

#349
post #11

Seems like a half-baked agency-built version of htmx[1], no? 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 ro…

My problem with liveview IMHO is that it requires an active internet connection and doesn't have offline support, which is a step in the wrong direction in terms of UI performance to me. 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.

A web application requires connection to the web, which only exists with network connectivity. What you're trying to do is create a desktop application with tools built for the web. Therein lies the problem.

Re: Breaking up with JavaScript front ends

#350

Earlier quoted context omitted.

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.

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 inco…

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

Post reply on HN