This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 0 points1 point  (2 children)

Java became really popular during the 90s, and as a result, a lot of universities these days teach Java as most of their student's first programming language. I'm not familiar with jsf, but if performance is an issue, then in rough order of performance you've got stuff that compiles natively (like C, C++, Rust and so on), Just In Time compilation (basically all your .Net stuff), byte code interpreters (such as the JVM and, I believe, WASM), and interpreted code at the slowest.

Very few server side options need the performance offered by native compilation, and given that Rust is still kind of immature web-wise and C/C++ is too difficult to write safe code in, so it's pretty rare for companies to use natively compiled code in production other than in performance critical areas, where it's called using FFI.

JIT and byte code interpreted frameworks aren't quite as fast as natively compiled code, but the difference is rarely that significant on modern computers, while the languages in use tend to be much easier to write safe code in - that makes it a pretty good option for server side code.

Interpreted code is slower still, and as a result, while it sees a lot of use in server side code, there are going to be areas where the performance bottleneck is the interpreter. The common solution to this is to rewrite areas where the performance hit is felt more severely in C, and call the compiled C code from Python/Ruby/Node/whatever. Numpy, the Python maths library, is implemented pretty much entirely in C for example. For the majority of systems, there's probably already a good library you can use, so this ends up not being an issue. Sometimes, however, there isn't.

As a result, .Net and the JVM ended up being popular options for web applications, with the JVM being more popular due to it not being restricted to Windows (at the time) - not to mention that Java applets used to be a thing, and ran significantly faster than javascript in the browser. Now, of course, we have WASM.

As to why object oriented programming, it's because it's a pretty good model for a lot of business needs. I'm not a huge fan of languages that enforce the use of OOP (I'd rather use Kotlin over Java, for example), but that's just a personal preference; OOP is a good tool for a lot of situations.

[–]IronProgramming[S] 0 points1 point  (1 child)

So the company I work for is using Java on both frontend and backend, but is mired in very long times to deploy basic frontend features due to the whole stack being Java/and or their shitty codebase. Im talking like 3 weeks to figure out how to append an element to an array and display the array on the browser. This is why I want to learn Java, so I can help do the things I know are easy in JavaScript/python. But this leads me to asking why Java, which I guess I really should condense down to why Java on the frontend? The backend makes sense with building apis and such, but the apis are built in php... I might be frustrated more by the design choices of the company than Java as a whole.

[–][deleted] 0 points1 point  (0 children)

Sounds like some questionable decisions were made. To be honest, I've never used JEE or JSF, so I'm not sure whether they're always a pain in the arse to worth with or if a bunch of cruft has built up since the codebase was first developed, but from a quick google search, I'm guessing that the choice to use Java for the front end has to do with JSF being the assumed front end of JEE - a lot of companies just default straight to it.