Please stop trying to act like the state of web and javascript is good because it's shit. Web development is basically a bunch of people suffering from stockholm syndrome.
People that complain about verbosity really don't have their priorities in line
Bragging about LOC is one of the most ridiculous things ever, since it is a bad thing.
Also, I'm in college for computer science and the school will only teach Java courses. It's dreadful and maddening. Classical inheritance is complete shit. Compiler error messages suck. The language itself is just too bloated for me to want use. Whatever I can write in Java I can do in a fraction of the time with js with much more modular and maintainable code.
I think java interfaces are a clear sign of stockholm syndrome, as every time I asked the professor why they are necessary I never got an answer other than "to hide part of your code from the outside world", "to use as a blueprint for your classes", or my personal favorite "Because in Java you write interfaces." I tried shifting my question to "Why don't I have to write an interface in js?" That one never got answered. Maybe someone here who is crafty with Java could explain and justify for me the reason for writing what feels like more code for no obvious benefit.
Also, sorry if Java is your thing and I sound like I'm bashing it. It's just been really frustrating for me compared to literally every other language I've used, especially since my degree depends solely on the language.
Whoever likes writing Java in CS courses?
> I think java interfaces are a clear sign of stockholm syndrome, as every time I asked the professor why they are necessary I never got an answer other than "to hide part of your code from the outside world", "to use as a blueprint for your classes", or my personal favorite "Because in Java you write interfaces." I tried shifting my question to "Why don't I have to write an interface in js?" That one never got answered. Maybe someone here who is crafty with Java could explain and justify for me the reason for writing what feels like more code for no obvious benefit.
Almost all modern, statically typed languages have some equivalent of Java interfaces. Inheritance a la Java is controversial, but the concept of interfaces/signatures/typeclasses/traits is a very accepted language feature[1]. Maybe the benefit of it will become apparent to you once you have to write a project with more than 7 Java classes - or when you don't have to answer to lecturers that profess that you have to make all your throwaway course work super modular and generic.
[1] Litmus test: even Go has it.
Also how have you not, in a java class, written code that uses polymorphism? That would be the easiest way to understand how useful interfaces are.
My preferred method of "inheritance" really is just extending an object. Which js is great at. And there's multiple ways to do this, with multiple kinds of prototypes. For something quick an easy I can make a prototype and just pass that through object.create() and now I have a new object that has all the properties of what I would loosely consider to be a "parent". It's more cloning than it is inheritance, and I can completely override properties however I want, while the original properties stay unchanged.
IMO polymorphism and interfaces in Java seem more like hurdles and added complexity compared to object extension and cloning in JavaScript. _.extend paired with browserify also makes for extremely modular code that I haven't seen any Java code compare too.
I think that a lot of "classical" programmers simply don't understand how important modules are to JS development.
This is why you get these posts about "how can you manage 1,000,000 LOC in JS!!?", when they don't understand that you never have 1,000,000 in JS, you have a bunch of small, unit tested modules.
Writing UI components out of HTML/CSS/JavaScript glue is a joke compared with what native UI toolkits allow for.
What was that? Sliders, exotic buttons, reactive graphs? What kind of applications are you selling?
Customer comes with Powerpoint/Photoshop mockup of their idea, based on how native UIs work.
Usually when it comes down to paying, there should be a 1:1 correspondence to their idea, across all requested devices.
While native UIs allow for full control down to pixel level and hooks on control behaviors.
Web requires a CSS/HTML/JavaScript magic mix to make it work properly across all requested browsers and devices, and still not good enough for some.
A recent example was a control for file uploads and the information that should be displayed while the file was loading. The files were too big to be processed server side and HTML 5 File API doesn't provide all the required features.
We, as developers working for companies that sells enterprise software "on the shelf", are not looking after pixel-perfect native UI and lowering customer friction during a project, as you seem to do (no offense, I can respect that).
What drives us is (i) innovation in solving enterprise problem, (ii) delivering a smooth, cutting-edge UX, (iii) offering the most affordable price while still being profitable.
If you consider those goals then a stack based on JS desktop application makes suddenly a lot of sens (lower development time, easy deployment, etc.)
Have you considered the possibility that, in some years, you could be the one that will be trying "to catch with the web"?
As I said everything goes. A native desktop .NET project today, a C++ embedded project in a few months and then a Web one.
So I never was, nor will be, a language X developer.