[rantanplan]

> There are tons of javascript libraries that are out there

And there you have your answer :)

What the JS people don't seem to grasp is that I don't care how many libraries are out there. I care even less about the incompatibilities and the different release cycles of all those libraries. By now, I hope you understand that my interest in maintaining and integrating all those into a coherent system approaches zero.

I am a software engineer and not a JS technologist. The front-end is just 1-10% of any serious system and yet, in the JS world, it takes 90% of the time building it and maintaining it. It just doesn't add up.

Imagine 10-15 years ago if we had to build GUI apps by mixing and matching 100 incoherent libraries, that in 1-5 months some of them will be obsolete, abandoned or whatnot. This is what JS has accomplished today and people just take it for granted.

Now I am sad and I will return to my crying corner.

[malandrew]

Engineering is taking all the bits and pieces out there and choosing the right ones for the problem you're trying to solve with engineering. It's not just choosing those components, but doing all the work to figure out how they should work together to solve your problem and building the pieces that bring them all together.

Using something that does all that for you is tantamount to outsourcing all the engineering work to the makers of that thing.

If you're given and entire system and just have to put the pieces together according to what the client needs, then you're basically a plumber.

Now there is nothing wrong with that, it makes good business sense, which is the justification you provide, but its not really engineering. Or if it is, it's only a small subset of the problems engineering solves.

Do you think the builders of the Golden Gate Bridge, the Hoover Dam or the Space Shuttle didn't have to think about all the bits and pieces they would need source and bring together into one coherent whole? That's engineering.

[rantanplan]

You are in a different conversation.

Unless you're trying to tell me that people who build e.g. KDE with the Qt framework are plumbers and people who develop with Backbone.js are engineers. In which case I wouldn't want to engage in such a discussion.

[malandrew]

Nice strawman.

Neither Angular nor React nor Backbone are equivalent to KDE or Qt, so those are false equivalencies use to construct a poor excuse for a strawman.

The user agents (browsers) and the web as a platform is the closest equivalent to Qt, since collectively, they abstract away all the differences between platforms as Qt does. Collectively and individually they represent excellent examples of engineering. The problem with them is that the problem they are trying to solve basically changed from what Tim Berners-Lee originally tried to solved. He tried to make a hyperlinked document platform, not an app platform. The web is now trying to evolve to supporting apps while also remaining a good documentation platform.

React would be most closely equivalent to added the paint/draw and retain-mode graphics part of Qt to the web. Flux and its different implementations and the various libraries out are likely equivalent to different solutions for events and data stores available in the Qt ecosystem, but I'm not a Qt developer so I wouldn't know. Those who built react are doing engineering as are those who build with react, it's just that the latter are absolved from solving the engineering problems related to render/paint/layout and retain-mode graphics.

Angular is an attempt to bundle everything together (render/draw, events, data) into one monolithic framework solution, doing reasonably well, but none exceptionally well. Those who built angular are doing engineering. However, those who build with angular are basically doing plumbing.

People who build with KDE and people who build with angular are basically performing the same type of work.

I don't know what backbone is equivalent to in the KDE or Qt world, but I would imagine it's probably some early library/quasi-framework in the Qt world when it was still the wild west and there weren't very good engineering practices and project organization strategies in Qt projects.

I can't believe I wasted my time responding to your logical fallacy.

[rantanplan]

Take a deep breath and relax.

First of all I stupidly thought that the part about KDE/GTK which is in this comment of mine https://news.ycombinator.com/item?id=8508094, was included in the comment to which you replied. So my bad and -1 for me.

What I meant is I don't think that anyone sees Qt or GTK as monolithic systems and they are about 1000 times more complex than any JS library you could name, as they solve a myriad problems to which JS is oblivious and wouldn't be able to solve anyway.

Contrast that with the web situation today, where they can't even decide which is the view, which the controller or "hey, maybe these don't map very well on the web side of things". Yes I agree about Tim Berners-Lee and the http stuff. But at some point things have to converge into something coherent, because the problem we have to solve is quite elementary, compared to other technologies.

Also if you honestly believe that people who developed KDE and people who develop with AngularJS are performing the same type of work... it just betrays the fact that you're just a JS programmer and haven't seen some real engineering work.

Javascript touches the tip of the iceberg with regards to technical challenge and Software Engineering, so please... just take a breath :)

[nobleach]

> The front-end is just 1-10% of any serious system and yet, in the JS world, it takes 90% of the time building it and maintaining it. It just doesn't add up.

Wow, I want you to come work for me for a week. The front end is what interfaces with the user - your client - the one whom is paying money. You may hate JS, but it is the tool that we use to build interaction.

[rantanplan]

You misunderstood or I didn't express myself correctly.

I don't want to underplay the importance of the front-end, or in general the interfaces and what that means for bringing value to a product.

But however you spin it it's not the core technology. You could make the same point you made, by saying the same about the marketing/sales department. Yes, it's how you bring customers and without it you'll probably fail to reach a large audience. But again, it's not the core of your product.

Also keep in mind that mobile platforms(which are quickly becoming much more important than the web) also have a user interface. Take a guess at which of the 2(web/mobiles) are more costly to develop and maintain. The web, by far. That can't happen for much longer, that's all that I'm saying.

[joshuacc]

That depends very much on what type of product you're building. I work on two "serious" enterprise products using Angular, and for one of them the "core technology" is evenly split between the Java backend and the Angular application, while for the other the Angular application is clearly the "core technology."

[rantanplan]

Indeed. I work in a similar kind of product. I was talking about the majority of cases though. There are even cases where the mobile app is the core and only technology.

Now what would be interesting questions though are: 1) How many people work in the backend and how many work in each of the respective front-ends.

2) Suppose that you had 2 front-end interfaces, angular(for the web) and an android app(it could be an iPhone app, it doesn't matter). How many backend devs would need to know or actively interact with the angular front-end and how many would need to interact with the android app.

In my case, none of the backend people(a lot) need to interact with the mobile codebase(2-people team for every mobile type), while all of us need to help or interact with the web front-end.

I see similar scenarios with most of the companies I interact or know about. The mobile team is almost always autonomous and can accomplish a lot with just a few people. While hords of people are thrown into the web frontend, even if it's not their primary specialty. Hence the need for fullstack developers. Why? Because the JS ecosystem sucks and we still don't have a real integrated solution. I hope that this will change, preferably before I retire.

[illicium]

Stop trying to shoehorn your backend into your web frontend, and treat the web frontend like the mobile one. That means, one single HTTP API to access the backend for both. I bet you already have this for your mobile app.

More often than not, the web frontend ends up being client side HTML/JS and some sort of intermediate middle-end server that hosts that HTML/JS. That way it turns into a fullstack app that does some processing on the middle-end to pass it on to the front-end JS.

You can make the frontend 100% static HTML/JS (and serveable off any static file CDN), so all you have to worry about is the API between them.

[purpletoned]

If you're using something like Angular, Ember or React, it's safe to assume that you'll be building a Single Page Application with the majority of code in Javascript. So evaluating libraries for stability, functionality etc is time well-spent, not wasted.

While it is true that there are far too many frameworks that come and go in JS land, you can find very stable, well-maintained and clean libraries too. For anything that's essential to your stack(DOM interaction, routing, UI elements etc), typically you'll find multiple well tested and stable libraries. Atleast, that has been my experience.

With well designed libraries, integration is rarely a problem. They are designed to be interoperable and don't make too many assumptions about things they aren't good at.

It takes a little bit of work upfront, but I find it's far better than relying on monolithic frameworks that tries to do everything under the sun(and usually fail).

Switch to React, I guarantee you that your front-end dev time(and overall) dev time will drop drastically to 20% :)

[rantanplan]

I had invested time in Angular. I don't think it was wasted time. If nothing else, it made me hate the JS world about 1% less.

For every well maintained JS "technology" there are 100 others that aren't and they occupy the same playground. Evaluating them takes more time than one might think and at the end of the day, what you choose carries a huge risk. Yes this also happens in other aspects/technologies, but with JS stuff the risk is almost always higher.

A word about monolithic systems; You give too much credit on what a JS framework does. It's just one job. Do you ascribe the same term to GTK or Qt for example?

To be honest, React seems decent. I don't necessarily disagree with you, you just touched... a nerve of mine :)

If I ever have to evaluate JS frameworks again, React will have its turn then.

Cheers