Hacker News Reader

Comment by jaytaylo | Hacker News Reader

How was it worse than the current state of affairs of complexity with React? Bowser, npm, typescript, obfuscation, compressors, build pipelines.. it’s a lot. Life at the front-end today is so discombobulated, creating a bunch of backend APIs which will generally only be used and consumed by a single browser front-end.

I’m genuinely curious, because I never used JSF except for a single school exercise

View on HN

Frankly, with yarn, typescript, and a packaging / compressing tools of your choice, web frontend development is pretty pleasant and efficient these days. (To say nothing of using Elm, if you can afford it.) Typescript is particular is nice compared to, say, Python, and even to Java (though modern Java is quite neat.)

The only unpleasant part is dependency management, but you have the same, or worse, with Python or Ruby, and neither Java nor Go are completely hassle-free either.

Really curious, how is it worse with Ruby?

With bundler, Ruby dependency management is excellent. I don't think I've ever had a problem setting up an app where the Ruby dependencies are the issue. I certainly can't say the same for JavaScript apps.

Typescript nicer than Python? Bc of speed? Python has typing module + mypy to be warned about typing mistakes.

It may have improved significantly since I last used it (9 months ago?) but mypy was a world away from the ergonomics, quality of tooling and maturity of TypeScript.

Primefaces makes it a bit more tolerable, but JSF is an ancient, slow, buggy beast that's hard to integrate with anything. Managing state on the server for every little thing is not scale-able, even for a measly number of clients. You don't have to grow to be a Facebook to feel the effects of the bad design of JSF.

I’ve used JSF when it was still beta. It was chosen by an external “architect” as the front end for a big site with millions of views (he was anticipating that JSF would be come popular, and a big project with it would be good on his resume).

Salesforce (classic) is JSF.

It’s full of bugs and quirks. But it’s kind of nice in certain situations.

The big problem here is performance load on both client and server. State is sent back and forth and it that kan be huge, and needs to be deserializes, altered, and serialized back again every action. It also doesn’t reflect any http verbs. Everything is POST

The big site was technically running on JSF, but in such a way that it wasn’t JSF any more

> Salesforce (classic) is JSF.

Here's a little bit of trivia... The Visualforce framework (that customers can write interactive pages in, and a small minority of the standard UI is build in) is based on JSF, but most of Salesforce classic standard UI is written in a home-grown system that generates HTML described in imperative Java. It's more akin to an HTML generating Tk.

Makes sense and they had a few big architectural changes of their front end. Lighting is unbelievably slow

Reply on news.ycombinator.com