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

311–320 of 433 posts

Re: Breaking up with JavaScript front ends

#311

Post by sph »

afavour wrote: post #271
t8sr wrote: post #100

Earlier quoted context omitted.

Alternatively, web developers could calm down and just write mostly HTML with some plain javascript where warranted. 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 f…

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

Memory leaks, like bugs, tend to scale linearly with code size. You better believe your 100k line framework has more leaks than my 1000 line script.

Re: Breaking up with JavaScript front ends

#312

Post by diss »

grishka wrote: post #77
jokoon wrote: post #45

Why can't anybody talk about the fact that HTML was not designed for being dynamic? 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 pati…

Whenever I build something on the web, I can't help but feel like I'm dealing with a word processor. A very advanced one, but nevertheless still a word processor at its heart. Coming from native apps, I despise the idea of text just being out there without a TextView or something. I also miss Flash.

I know exactly what you’re talking about from when I transitioned to web dev, but I feel that much less these days with TypeScript (done well) and VS Code. It’s actually a pretty decent experience even if it does feel like a bit of a facade over the top. Once you’ve got all your setup and dependencies sorted of course…

Re: Breaking up with JavaScript front ends

#313

Post by 0xblinq »

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…

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

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

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

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

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

Re: Breaking up with JavaScript front ends

#314

Post by dools »

Many years ago a colleague and I wrote a stand-alone version of a package for my own arcane php framework called Remote.

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:

https://github.com/dgrinton/remote-standalone

Re: Breaking up with JavaScript front ends

#315

Post by 0xblinq »

t8sr wrote: post #100
qrohlf wrote: 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…

Alternatively, web developers could calm down and just write mostly HTML with some plain javascript where warranted. 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 f…

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

I don’t buy the “just use html, js and css”… giving the same developer skills, without a framework that becomes a mess much sooner than with one. Unless you’re just building a small landing page or todo app.

Re: Breaking up with JavaScript front ends

#316

Post by sph »

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?

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

Re: Breaking up with JavaScript front ends

#317

Post by arcturus17 »

deepsun wrote: post #295
arcturus17 wrote: post #215

Earlier quoted context omitted.

It's becoming a standard, and yes, I personally like it. There's plenty of other great choices if you don't like it. And even some of the up and coming libs, like SolidJS, feel stable compared to the 2010's - they add incremental improvements but keep things that some people really like, like JSX. In the early to mid 2010's everyone was reinventing the wheel constantly.

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

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

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

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

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

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

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

Re: Breaking up with JavaScript front ends

#318

Post by sph »

Rauchg wrote: post #204
CharlieDigital wrote: post #197

Earlier quoted context omitted.

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

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

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

Re: Breaking up with JavaScript front ends

#319

Post by sph »

arcturus17 wrote: post #317
deepsun wrote: post #295

Earlier quoted context omitted.

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

Do you have any real commentary against Next.js not being standard, or only generic snide and feelings of superiority directed at "everyone" but yourself? I'll share a few facts about Next.js: - Their showcase: https://nextjs.org/showcase#all . The number of super-scale websites using it speaks for itself (doesn't include among others Walmart, which another commenter pointed as an example of how terrible Next.js, but…

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

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

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

Re: Breaking up with JavaScript front ends

#320

Post by _djvl »

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…

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