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

351–360 of 433 posts

Re: Breaking up with JavaScript front ends

#351

Post by mhd »

phist_mcgee wrote: post #327
throwaway999528 wrote: post #216

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.

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

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

Re: Breaking up with JavaScript front ends

#354

Post by JackMorgan »

jiggawatts wrote: post #298
arcturus17 wrote: post #229

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 haven't died playing russian roulette, you should try it too." The general experience across the industry in a statistical sense is that JavaScript frameworks are a tyre fire best avoided. I'm yet to see a JS app that doesn't need constant maintenance to remain compilable. Meanwhile, the ASP.NET ecosystem had like one significant breaking change since like... 2002.

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

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

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

Re: Breaking up with JavaScript front ends

#355

Post by _glass »

hinkley wrote: post #144
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…

To me one of the unsung skill sets of the industry is tool selection. The ability to look at a tool and imagine how it’s going to behave for different pay grades of coworkers, different specialties, and to predict how that will pan out in the future. Sometimes you pick the simpler tool, and hope it has legs. Sometimes you tweak your product roadmap to dovetail with the tool’s. Sometimes you push to get 25% of a featu…

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

Re: Breaking up with JavaScript front ends

#356

Post by majkinetor »

aussieshibe wrote: post #151

Maybe it's just me, but needing to press "back" twenty or so times to get back to HN after viewing some of this presentation really made me question the author's authority when it comes to "how the web should work".

Its a matter of preference. I prefer to go to previous presentaton page.

You should learn to use browser - there is right click on back button

Re: Breaking up with JavaScript front ends

#357

Post by JackMorgan »

whatever1 wrote: post #17
ramesh31 wrote: post #16

Earlier quoted context omitted.

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

SPAs solved a labor problem I think. It was the reason that front end development grew so fast. 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.

A lot of dev managers like that they can turn one team into two teams by splitting everyone into front and back end. This makes hiring easier. I cannot emphasize this enough. Easier hiring is a huge deal.

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.

Re: Breaking up with JavaScript front ends

#358

Post by mawadev »

cpursley wrote: post #211
mawadev wrote: post #209

From my experience, the horrors of javascript come from letting the client handle too much stuff. Frontends tend to run a ton of logic that should be handed off to the proper tool for the job: SQL. The time and complexity you save on the backend is simply not put to good use these days. I like to program SPAs like a reactive thin client and let the backend be more SQL or ORM heavy.

This is not just JS frameworks. Many backend frameworks are overly ORM dependent in my opinion.

That is true. I have seen a big aversion to writing JPQL or native SQL whenever an ORM like Hibernate or JPA is involved. It seems to be like you home in on a single technology and try to make it fit it into things where another tool can do a better job in less lines of code.

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.

Re: Breaking up with JavaScript front ends

#359

Post by mattlondon »

t8sr wrote: post #308
Throwaway23459 wrote: post #270

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.

I think citation needed on that one.

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)

Re: Breaking up with JavaScript front ends

#360

Post by cies »

heather45879 wrote: post #181
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 like to go back to the basics. It irks me that folks don’t think HTML/CSS/JavaScript are good enough as-is—but nowadays the default browser capabilities are incredible compared to a decade ago. We basically have a full programming environment and add WASM to the mix! Back in the day the frameworks were first-and-foremost a platform compatibility solution. People often have it ingrained in their psyche that reinvent…

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

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

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

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

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

Post reply on HN