Breaking up with JavaScript front ends • Hacker News Board

Re: Breaking up with JavaScript front ends

#421

Post by P5fRxh5kUvp2th » Mon, Dec 12, 2022, 6:35 AM UTC

lagt_t wrote: post #260

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 problem was choosing an SPA

I was looking for this response because I was going to post it if I didn't find it.

So many people don't get that their design decisions have consequences and using a SPA is absolutely a design decision.

Re: Breaking up with JavaScript front ends

#422

Post by sparks1970 » Mon, Dec 12, 2022, 9:42 AM UTC

wruza wrote: post #347

the_gipsy wrote: post #336

Earlier quoted context omitted.

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.

Qooxdoo: https://qooxdoo.org/

It's a no-html, widget only web framework that's been going for at least 10 years.

Re: Breaking up with JavaScript front ends

#423

Post by lenkite » Mon, Dec 12, 2022, 10:13 AM UTC

wwweston wrote: post #280

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.

> 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. So… what’s the difference between this and SPAs using frameworks again? Because it sure seems to me I see many of these in sites that are apparently using frameworks. Hell, Facebook — presumably the poster child for the react ecosystem and certainly with t…

If browsers could agree on a themable UI component framework - it would solve so many things for so many people. The jazzy designers can still have their complicated CSS/JS animations and cool layouts. But having a standard solution for normal developers would be so good.

Re: Breaking up with JavaScript front ends

#424

Post by nicoburns » Mon, Dec 12, 2022, 1:53 PM UTC

thex10 wrote: post #244

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…

> Talking layer of DOM nodes, I actually did a few samples of this the other day. Is there a tool for this? I’m kind of wanting to check my site now…

You can run the following snippet in the console:

    function getMaxNestLevel() {
        var i = 1, sel = '* > *'; /* html > body is always present */
        while(document.querySelector(sel)) {
            sel += ' > *';
            i++;
        }
        return i;
    }
    
    console.log('total nodes', document.getElementsByTagName('*').length);
    console.log('max nest level', getMaxNestLevel());

Re: Breaking up with JavaScript front ends

#425

Post by jrochkind1 » Mon, Dec 12, 2022, 2:08 PM UTC

TranquilMarmot wrote: post #88

jrochkind1 wrote: post #21

It's interesting that they appear to plan to use with Rails as a back-end (they mention Rails bindings), as Rails 7 release corresponded with a solution which appears somewhat similar to me, turbo/stimulus. (I want to provide a link to it, but I honestly don't know any great docs for it!) But I haven't used stimulus/turbo myself. I'd be interested in a compare/contrast between Rails' Stimulus/turbo and "Unpoly" cover…

It's worth noting that this presentation is from 2016, so it is over 6 years old now

Oh, I and I think many commenters had missed that, that is important to note!

I wonder if there's an update on how Unpoly has worked out for them or anyone else.

Re: Breaking up with JavaScript front ends

#426

Post by artursapek » Mon, Dec 12, 2022, 3:52 PM UTC

rawrenstein wrote: post #123

artursapek wrote: post #46

You should break up with web based front ends and write them in Rust. :-) https://iced.rs

> It is inspired by Elm, a delightful functional language for building web applications. That killed my interest instantly.

Top HN response dismissive and rude, 100% reliable

Re: Breaking up with JavaScript front ends

#427

Post by dormento » Mon, Dec 12, 2022, 5:29 PM UTC

traverseda wrote: post #365

kaba0 wrote: post #334

Earlier quoted context omitted.

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

Ordering a pizza can be done with static pages and some forms. You want to make photoshop or a CAD program? That is an app. You want to order a pizza? Just use html and forms, maybe javascript to reload the progress page once per minute. (You don't need websockets or SSE or anything to check pizza progress)

> maybe javascript to reload the progress page once per minute

Not even that, as there is meta refresh :)

Re: Breaking up with JavaScript front ends

#428

Post by llanowarelves » Tue, Dec 13, 2022, 12:49 AM UTC

antifa wrote: post #391

llanowarelves wrote: post #222

Earlier quoted context omitted.

It's like ORMs and game engines. Many times when people try to forgo them, they end up making their own poorly specified and half-baked version of it that only some people (who may leave the company) understand.

I've only used laraval and knexjs over the last 10 years and have no idea which ORMs people are complaining about because the ones I used do not have the issues they talk about.

I agree. They are in general easily net-positive for most traditional applications.

Re: Breaking up with JavaScript front ends

#429

Post by belmont_sup » Tue, Dec 13, 2022, 12:52 PM UTC

danielvaughn wrote: post #335

heather45879 wrote: post #277

Earlier quoted context omitted.

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.

What even is a good DSL for applications?

I liked that react/jsx was born out of the web, and then influenced swiftui, jetpack compose, and flutter for a new way of writing application markup. I wonder: if not for the web and its pain points, would we have landed on similar patterns? Maybe.

Re: Breaking up with JavaScript front ends

#430

Post by belmont_sup » Tue, Dec 13, 2022, 12:55 PM UTC

danielvaughn wrote: post #337

jiggawatts wrote: post #296

Earlier quoted context omitted.

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.

That group there…really liked to waste time.