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

411–420 of 433 posts

Re: Breaking up with JavaScript front ends

#411

Post by panopticon »

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.

It depends what org you're in. Cloud seems to use a lot of Angular, but the rest of the company is coalescing around an in-house framework called Wiz (you can poke around the open sourced jsaction library to get an idea of the design philosophy).

Re: Breaking up with JavaScript front ends

#412

Post by Throwaway23459 »

ttfkam wrote: post #373
Throwaway23459 wrote: post #272

Earlier quoted context omitted.

React and Angular are both blazing fast, and are definitely not pointless. Open create react app, spin up a page with 50000 buttons, compare that to a plain js version, then come back and tell us about the atrocious performance.

Apparently you've never heard of event delegation, which has been around for at least twenty years? (I could swear I was using it on IE6, but I might be misremembering.) At any rate, the plain JS way of handling 50,000+ HTML buttons efficiently is a long-solved problem. https://javascript.info/event-delegation

You appear to be reading more into my post then I intended. The point I was illustrating is that there is no cruft in React.

Try and keep your posts factual.

Re: Breaking up with JavaScript front ends

#413

Post by xupybd »

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)

The browser is a sandbox. It requires no install or approval from IT to install a web page. You don't have to go through and app store.

It has huge value as a delivery platform.

Re: Breaking up with JavaScript front ends

#414

Post by jimmont »

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…

the primary solution to all this is to remove technologies which are not required and especially those that duplicate what the web as a platform provides (ie works in browsers/runtime directly); for example React has been technically obsolete a few years, yet that doesn't mean anyone understands what to do instead, regardless of whether those technical implementations were ubiquitous 1 year ago or 15 years ago; I find it remarkable to read job listings for up and coming concerns (eg Anduril, BioNTech, etc) basing their platforms on long outdated notions and implementations, which bring with them multiple vectors for risk to security and more (unnecessary) costs to developer productivity, complexity; SASS and npm/yarn are other obvious examples of tech that costs more than it benefits in modern work.

Re: Breaking up with JavaScript front ends

#415

Post by wruza »

ttfkam wrote: post #378
wruza wrote: post #347

Earlier quoted context omitted.

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.

Java Swing is decades old (1998?) and does everything you list above. Was even embeddable as a browser applet in all major browsers at the time.

Every swing tutorial out there starts with a good old:

  c = new Container()
  w = new Widget()
  c.add(w)
  w.addActionListener(
    …200 bytes of a functor boilerplate…
  )
Also I don’t know java well, but variable/keyed arguments and closures like in python do not exist there, to my knowledge.

Am I missing something, or maybe you meant something else?

Re: Breaking up with JavaScript front ends

#416

Post by remram »

hliyan wrote: post #284
recursivedoubts wrote: post #250

Earlier quoted context omitted.

htmx is focused on hypermedia exchanges in the mode of normal HTML, so client-side stuff is out it does, however, have an extensive event model to hook into, including pre and post request processing: https://htmx.org/reference/#events as well as an extensions API: https://htmx.org/extensions/#defining for client side scripting, I think you are talking about hyperscript, which is definitely more speculative than htmx…

Just checked alpine.js. While it's very nice, was a bit worried about this potentially risky eval use:

What's risky about evaluating your own code on your own pages?

Re: Breaking up with JavaScript front ends

#417

Post by SturgeonsLaw »

kaba0 wrote: post #334
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…

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…

> Also, should I really download a random exe to order a pizza?

That's where mobile seems to be heading, McDonalds would like you to download their app to order a burger

Re: Breaking up with JavaScript front ends

#418

Post by xupybd »

xupybd wrote: post #413
traverseda wrote: post #365

Earlier quoted context omitted.

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)

The browser is a sandbox. It requires no install or approval from IT to install a web page. You don't have to go through and app store. It has huge value as a delivery platform.

Gah, it's too late for an edit. That should read "an app store".

Sorry.

Re: Breaking up with JavaScript front ends

#419

Post by P5fRxh5kUvp2th »

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…

Over the last 3 years I've started to feel more and more vindicated.

I explicitly opted out of most web development when it turned into angular/react and later vue. I've done work in both angular and vue so I've not been able to avoid them completely, but mostly.

And the reason was a fundamental disagreement with their approach. It has _always_ felt to me like people took a good idea (AJAX) and took it entirely too far.

And they found themselves fighting fundamentally with the browser, so the industry's solution was to create new standards such as the history API, when the REAL solution was to just not do what they were doing.

Does react bring legitimate good ideas? Probably, somewhere, but thank god we're starting to see the light at the end of the tunnel.

imo the best thing to come out of it all is typescript.

Re: Breaking up with JavaScript front ends

#420

Post by P5fRxh5kUvp2th »

hinkley wrote: post #401
_glass wrote: post #355

Earlier quoted context omitted.

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.

I haven’t had a lot of luck with architects. In one case I came to a company that got rid of their architect and hired me and another person to replace him (to be fair they were too small to warrant a full time role anyway, not sure what they were thinking). Especially in the post refactoring era, they tend to have an inaccurate account of what the code is actually like and make bad calls based on bad info. It’s a re…

yep, if your architects don't have their hands directly on the code, they're making bad decisions.

People talk about enterprise architects as these pie-in-the-sky people who shit diagrams and everything works wonderfully. In practice it's "seagull architecting", with everyone else forced to deal with the reality on the ground.

At some scale architects need to be more hands off. When that happens they need to have a _very_ strong relationship with the people on the ground or it doesn't work well. Even then I would argue they should be getting their hands dirty in terms of reading code, etc, they just may not have time for implementation duties.

Post reply on HN