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

331–340 of 433 posts

Re: Breaking up with JavaScript front ends

#331

Post by arcturus17 »

miyuru wrote: post #322
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 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.

Would this be out of the realm of possibility if you inherited, say, an old Django or .Net project?

Re: Breaking up with JavaScript front ends

#332

Post by eastbound »

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…

Hiring is my problem. They all want to use NPM/React/any fad or not do front-end at all.

Re: Breaking up with JavaScript front ends

#334

Post by kaba0 »

heather45879 wrote: post #277
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.

The underlying issue with web applications is that it’s like a square peg going in a round hole. Remember, HTTP is designed traditionally as a stateless protocol delivering static web pages, more or less. 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; Jav…

Things change. Just because it was originally made for documents doesn’t mean that it hasn’t undergone such huge changes that it can literally drive FPS games at 60fps without a sweat. And I say that as someone who really doesn’t like many of the underlying abstractions, imo CSS+HTML are just thoroughly badly designed, none of them would be whole without the other resulting in extreme close coupling (layouting for example cannot be done without the other).

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

Re: Breaking up with JavaScript front ends

#335

Post by danielvaughn »

heather45879 wrote: post #277
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.

The underlying issue with web applications is that it’s like a square peg going in a round hole. Remember, HTTP is designed traditionally as a stateless protocol delivering static web pages, more or less. 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; Jav…

I’ve always been in favor of an entirely different file type, specifically for applications. Imagine if we’d just had something like .aml (application markup language). Then html could have stayed as a document format and we could have avoided all this nonsense.

Re: Breaking up with JavaScript front ends

#336

Post by the_gipsy »

wruza wrote: post #210
wefarrell wrote: post #170

Earlier quoted context omitted.

No markup format will support interactivity well, you need a full scripting language with all of the standard features. 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.

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.

Re: Breaking up with JavaScript front ends

#337

Post by danielvaughn »

jiggawatts wrote: post #296
lagt_t wrote: post #260

Earlier quoted context omitted.

The problem was choosing an SPA

Precisely. There was someone here bemoaning how difficult it was to follow generic advice of using profilers to optimise hotspots in the application code. 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 f…

Choosing a framework for that is bad enough, but you could make the case depending on how complex the rendering is. Still…to go with Angular sounds like the literal worst choice. Like at least React is just a UI library and can just be used server side.

Re: Breaking up with JavaScript front ends

#338

Post by danielvaughn »

resonious wrote: post #255
alerighi wrote: post #251

Earlier quoted context omitted.

In a modern web framework you still have HTML and you still have CSS files. 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,…

I definitely see the elegance of the modern reactive approach, but in practice I'm not sure how much better it really is. I still see spaghetti code, and I still see stupid bugs in production. Doesn't seem to matter whether it's JQuery or Vue. Right now I'd bet that careful architecture and thorough testing are still #1 for making good software.

It does often turn into a weird kind of spaghetti when it comes to things that are inherently imperative. Sometimes hooks make me feel like I’m trying to follow a Tarantino script.

Re: Breaking up with JavaScript front ends

#339

Post by blep_ »

LudwigNagasena wrote: post #274
heather45879 wrote: post #181

Earlier quoted context omitted.

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…

There is a reason why modern UI frameworks like SwiftUI or Jetpack Compose look more like React rather than pure HTML/CSS/JavaScript. And it is not because iOS and Android can’t run WASM.

Because this entire industry runs on trends?

Re: Breaking up with JavaScript front ends

#340

Post by robot »

one of my startup projects failed in 2014. one reason was the complexity slide shown for 2014. After that experience I don't do SPAs anymore. React only complicated the problem further and it is expensive for anyone creating their own projects to hire react devs. what's worse is new devs think react is the best thing to learn and start with that.
Post reply on HN