Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Breaking up with JavaScript front ends

triskweline.de

Post reply on HN
Print view View original

191–200 of 433 posts

Re: Breaking up with JavaScript front ends

#191

Post by johnthuss »

taeric wrote: post #184
nicoburns wrote: post #134

Earlier quoted context omitted.

Google's frontend engineering tends to be pretty poor and out of step with wider industry practice in my experience. They have created not one, but 3 of their own frameworks (Angular, Angular 2 and Polymer), two of which (Angular and Polymer) were rather poorly performing, and the third of which is kinda ok but doesn't seem to be that widely used internally. They tried to create their own frontend language (Dart), wh…

You didn't even mention GWT. I don't know what is causing it, but yeah, Google has dropped some turds over the years.

The original version of GWT was mainly about solving compatibility issues between browsers (of which there were many). Modern GWT/J2CL is all about leveraging the mature Java development tools, especially code completion. GWT can be used with just the standard DOM APIs very effectively these days via the elemental2 library.

Re: Breaking up with JavaScript front ends

#192

Post by Winsaucerer »

trollied wrote: post #182
t8sr wrote: post #104

Earlier quoted context omitted.

> 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... What? The exact opposite is true: the average web app (including ones like gmail) is far less responsive…

Agree 100%. Also makes me laugh when people talk about server side rendering. Serving a html page isn’t rendering. The fact that a couple of megabytes of JavaScript ever became responsible for making the simplest of pages even display is possibly the worst technology regression I’ve ever seen.

I think 'rendering' here means something like 'doing what's needed to produce the final HTML for the browser to render'. You can produce the final HTML on the server (server side rendering), or the front-end (e.g., via DOM manipulation), or mix them up (e.g., HTMX replacing parts of the DOM with pre-rendered HTML from the server).

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.

Re: Breaking up with JavaScript front ends

#193

Post by pron »

synergy20 wrote: post #79

I still think separating frontend from backend makes life easier even though frontend has been chaotic for a decade, and it shows no sign to slow down

Separating the frontend from the backend doesn't necessarily mean putting all of the frontend logic in the client. Your server can also have separate frontend (or "view") logic.

Re: Breaking up with JavaScript front ends

#194

Post by Winsaucerer »

0xblinq wrote: post #156
qrohlf wrote: 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 like new Reddit’s cards layout when scrolling, but I don’t enjoy its poorer performance and new thread view.

The good bits from new reddit could have been added without heavy JS, since those are just CSS+HTML.

Re: Breaking up with JavaScript front ends

#195

Post by simonw »

omnimus wrote: post #98
simonw wrote: post #43

What's the accessibility story for Unpoly? 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.

Why would the story be different than SPAs? The screenreaders read final html in the browser. It shouldn't matter if comes from server rendered template OR javascript template rendered on the client. Seems like it depends on how you code the html/templates not how they are rendered?

SPAs very often have terrible accessibility. I think it's important for frameworks that help people build interactive applications (SPA or otherwise) to provide the best possible defaults, plus guidance as to how to use them to build accessible interfaces.

Re: Breaking up with JavaScript front ends

#197

Post by CharlieDigital »

arcturus17 wrote: post #171
ostenning wrote: post #120

The biggest problem facing the front-end space today isn't so much of complexity of a particular library, rendering technique, or view/model architecture, but rather lots of bad ideas glued together, creating nightmare scenarios for companies trying to maintain products. A micro dependency system with never ending breaking changes to glue different tools and libraries together - bad idea. Using un-opinionated "librar…

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.

Re: Breaking up with JavaScript front ends

#198

Post by _the_inflator »

ostenning wrote: post #120

The biggest problem facing the front-end space today isn't so much of complexity of a particular library, rendering technique, or view/model architecture, but rather lots of bad ideas glued together, creating nightmare scenarios for companies trying to maintain products. A micro dependency system with never ending breaking changes to glue different tools and libraries together - bad idea. Using un-opinionated "librar…

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.

Re: Breaking up with JavaScript front ends

#199

Post by sally_glance »

arcturus17 wrote: post #171
ostenning wrote: post #120

The biggest problem facing the front-end space today isn't so much of complexity of a particular library, rendering technique, or view/model architecture, but rather lots of bad ideas glued together, creating nightmare scenarios for companies trying to maintain products. A micro dependency system with never ending breaking changes to glue different tools and libraries together - bad idea. Using un-opinionated "librar…

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?

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.
Post reply on HN