Hacker News Reader

Comment by ksec | Hacker News Reader

People are generally happy with the development of JS the trends of always improving languages along with frameworks makes developing with JS makes developer increase in happiness for the third time in a row.

ES6 is good, TypeScript is gaining ground, people are moving away from Flow.

Angular is dead? Most don't even want to touch it again ( Great ). Ember hasn't moved a bit in three years with a declining of interest. I am also surprised no one is using preact. The Choice is now either React or Vue.js, I think Vue.js 3.0 will continue to move vue forward.

Given the amount of hype with GraphQL, I am surprised only 20% are actually using it. And nearly 50% are using Redux!

Backend is dominated by Express only, and Testing framework doesn't have a clear winner either.

And my biggest surprise is how Javascript turned from one of the most hated programming language ( besides PHP ? ) into being acceptable and loved.

I really wish other languages communities do a similar survey, Python, PHP, Ruby, Java, Rust etc... It will be interesting to see the trend and big picture.

View on HN

I suspect one of the reasons people are happy with JS (even though there's plenty of much better languages) is that it has made a huge progress. Writing ES6 after a few years with ES5 is so much more pleasant. I used to be annoyed every time I had to write some JS code in the past, now I must say I even enjoy it.

However, regarding the metric that shows developers' happiness over the years:

* If someone asks me if I'm happy writing JS these days vs a few years ago I'll say I'm much happier now than I was before.

* If someone asks me if I'm happy writing JS vs writing Elixir (or Python or some other language), I'll still say I'm much happier with Elixir.

I think we should also consider that most people have gotten used to the fact that JS is the language of the web, and there’s basically nothing we can really do about it in the short term, so let’s just have a positive attitude towards it!

P.S. I don’t, but most people I have met seem to have this kind of mentality.

Yep, the Stockholm Syndrome. I still swear a blue streak when I get pulled from my nice backend world over to do some trivial UI work on the front-end, and it takes me frigging forever because there's no type system, and no compiler, and the tooling is stone age, and it takes me longer to run gulp and babel to build it to see changes than building my entire backend solution and running all my tests.

It's all we've got, but it is assuredly not good. Hopefully WebAssembly comes to fruition and we can leave this dark era behind.

> to do some trivial UI work on the front-end

If that takes you forever, consider that it may also be your lack of familiarity as much as the lack of type system/compiler. Despite my preference for the back end, I have spent plenty of time on the front end and can pump out changes very quickly.

But client development is always hard. Comparing backend work to browser client development in an effort to attack Javascript never made sense to me.

At least you have pretty good wiggle room to use other solutions on the browser client, whether it's other languages (TypeScript, Elm), to completely new abstractions (React, Elm again, etc). For example, Elm or React are a fuck ton better than anything we have native on Android and iOS.

Look at other clients people development for like iOS. It's not easier. And any gains in ease of use are traded off because you're developing for a platform that not everyone uses.

Also, continuing with iOS, things like CoreData and the entire UI abstraction are super OOP and not very pleasant (especially the former). And it's nontrivial and a lot more warty to switch out abstractions (like using Rx) or use something other than Swift.

So that things are harder that you moved from backend to client development isn't a very scathing review of Javascript because client development isn't easy.

Look at flutter. Please.

Like everything, it has trade-offs and is not a free abstraction.

That is why I love React Native. Things like laying out screens is simple using flex and position properties. Laying out in iOS? Not as simple with those atrocities like auto layout, constraints...

That isn't surprising because the backend is simple and the frontend is not.

By that, I mean that you get to choose your entire playing field on the backend. What language are you going to use? What database? What OS will it run on? What (reliable) network connection? All can be tailored to your heart's desire.

No such luck on the frontend. Your code is going to run on a diverse set of clients, which you have no control over. The connection quality might be awful. The CPU on the device might be awful, or it might have low memory.

As much as people like to crap on JavaScript, it isn't the reason the front-end is difficult to program for. And WebAssembly isn't going to solve all of these issues either.

These technical problems you present, are difficult but solvable if a big player is willing to pitch in.

I don't like to target specific words, but the problems you specify apply to JS as much as they do to any other language.

A C/rust like language has far better CPU/memory efficiency than JS.

A batteries included language like python might even be better at network latency since it doesn't have to bundle in the code that should've been in a stdlib, not client code.

We use different languages because they are good at different things. The browser doesn't seem to respect this Philosophy :(

And my biggest surprise is how Javascript turned from one of the most hated programming language ( besides PHP ? ) into being acceptable and loved.

I enjoy modern JS myself, but I'd be careful about coming to a conclusion like that based on this survey. All it tells us is that JavaScript is very well liked among people who wanted to take the time to complete the State of JavaScript survey.

People who dislike or hate it JS probably wouldn't see the value in completing the survey, so the happiness factor might be a bit biased as a result.

JS is not loved. Is hated less :)

BTW, I insist that is a missed oportunity of clean JS even more (ala typescript, whit some of the wats removed).

I don't know a language in a better position of improve by a HUGE margin than JS.

> Angular is dead? Most don't even want to touch it again ( Great ).

I don't get the Angular hate. I work with it daily and seems like a productive environment. I did some tests with React and Vue too and couldn't find any relevant advantage. Angular has batteries included tools for a lot of tasks: i18n, routing, isomorphic builds, web components, etc.. You get a cross platform mobile development environment too using NativeScript and a somewhat Angular-esque backend development framework using Nest.js. Seems like a good deal to me.

One major reason is that Ng is its own thing. It's not JavaScript, nor HTML. Also, "batteries included" means buying into the whole monolithic framework. The React ecosystem requires more decisions, but also benefits from ability to pick and choose the right libraries for a given project. That said, Angular has some great parts, eg TypeScript and RxJS.

I think people will grow "hating" React because of the ease of use. Just like JS and PHP.

I weep for the people that will maintain all the React mess that is being created. React is great, but the current ecosystem has too much liberty for too many junior dev using it.

Angular being a framework has a lot to offer in term of maintainability and good practices.

I can assure you that nobody on earth hates Js and PHP for "ease of use"

A couple good points. I agree w/ your 2nd and 3rd sentences. That said, I'm personally glad I invested in React and its ecosystem.

I find the "build your own framework" aspect of React to be as much a curse as it is a blessing. You can skip some of the bloat, but you also have to kludge together multiple libraries of varying quality to get the same things you'd get out of the box with a "batteries included" framework.

especially for new developers and organizations. You have a choice between a wide-open landscape and a script that you're deathly afraid to eject because you can never go back. Neither is great for someone considering adoption for a new commercial product.

Yeah, I hear you about the "eject" problem for create-react-app. In CRA1, react-app-rewired emerged as a reasonable approach to no-eject config extension, but CRA2's switch to Webpack 4 (itself having moved towards zero-config) broke almost all the rewired plugins. There are solutions in the works (eg babel-plugin-macros), and alt approaches like Neutrino, but timing is tough right now as there isn't a clearly-established and well-lit path for good defaults plus low-maintenance config.

> One major reason is that Ng is its own thing

You're spot on with that in my case. I already knew JS and wanted to build on top of it. React just felt natural to pick up than Ng. Also, the fact that ng completely changed in v2 really put me off and I haven't looked at it since.

I think they could have avoided 90% of their problems by just giving it a different name.

Agree, I can't believe that the company owning the major Internet search engine gave the same name to two different frameworks.

Loved? Well, it's a point of view. I personally hate it, due to the tooling and the dependency management (npm and yarn are catastrophic, an "hello world" example with React downloads on average more than 100 packages).

As much as I dislike Javascript OP is right. The latest stack overflow survey[1] puts #7 on most loved languages and it's not even in top 25 most dreaded ones.

[1] - https://insights.stackoverflow.com/survey/2018#most-loved-dr...

And #2 in most wanted, right after Python.

I do wonder how much of that love is from devs who basically only know JS, and have done nothing by web stuff.

Can't speak for anyone else... but will say I'm far more productive with full-stack JS. My second most familiar language is C#, followed by Ruby, VB, Java and several other languages. Most of the productivity outside the browser is because of Node + NPM though. Also the browser gives you a much more rich rendering target than pretty much any common UI platform out there. Including some very nice abstractions.

In the end, it isn't the best choice for many things, but it's good enough for most things. As such, it's what I tend to reach for first, since getting something working takes less time, and gets in my way so much less. Windows, Mac, Linux via Node, Electron, Carlo (node + installed chrome), not to mention Cordova (iOS/Android) and React Native. Best of all, I don't have to deal with a lot of issues seen in other platform specific tools.

It's so much closer to write once, run everywhere with less friction than anything else that has been done in computing. Aside from trivial projects.

I hear a lot of complaining like this from Java devs. Oddly, they are often okay only knowing one language (Java). The exact words from a Java dev were, "well, when all you have is a hammer, everything looks like a nail".

On the plus side, once you built it, the only dependency you have is the browser, and you can distribute it however you want since it's cross-platform compatible.

>> the only dependency you have is the browse

HA! maybe this is technically true, because in the end that's where it runs, but have you looked in your modules folder at any substantial project lately?

The dependencies run deep and they run wide...

Tell me about it.

https://news.ycombinator.com/item?id=12209300

Typescript and other transpilers especially, seem to be quite resouce hungry, slow and a pain to configure — always getting in my way :(

My "secret" weapon against tooling creep is https://parceljs.org it really lives up it its tagline.

I wish that was true.

It is :)

What's 'catastrophic' about Yarn?

Not exactly Yarn or NPM. The problem is that JS is suffering from extreme dependency hell, due to overly fragmentation of modules. It's appalling. It is not a good thing starting a project, doing a install and having hundreds and hundreds of modules on node_modules, some with less then 50 lines of code. Of course things must be modular, but unwraping everything in a folder like this is far from good.

Isn't the issue here basically that JS doesn't have a "standard" authorized library, like Java or C# and NPM has basically become the standard library?

Having someone like Google steward a "standard" library (and it could even be distributed using NPM), would pretty much bring JS dependency management at par and beyond Java or C#.

hmm maybe you're onto something here..

I'm curious: why is it bad? I very, very rarely have to delve into my node_modules folder to take a look at something.

The leftpad fiasco (which I believe NPM has now mitigated), and the recent security issue where a certain popular package was uploading any passwords it found showed the current dangers with NPM.

I'm not arguing about the security of NPM, rather the idea that multiple modules is a bad thing.

The lesson from left-pad should have been to vendor all your deps rather than bet your org on third parties with no SLA commitment to you.

You should take a proper look once, you'll be amazed at all the different modules implementing the same functionality over and over again (e.g. globbing, promisifying, or the myriad of `is-*` single-function packages).

Why is that bad? It's a huge waste of effort, increases the burden on anyone who's maintaining a package using those micro-libraries, and will guarantee more unpatched security vulnerabilities and unmaintained packages in the long run.

NPM and Yarn are both working on approaches that would replace having a separate unpacked `node_modules` folder for every project: "Yarn Plug 'n Play" and "NPM Tink".

Having just inherited a legacy python project where I couldn't use a library due to conflicting dependencies on ancient, incompatible versions of a dependency's dependencies... I'd kill for the npm way of dealing with it. To each his own I guess.

That's interesting, what happened? I've always loved the simplicity of a couple of inhereted requirements files in Python depending on the environment. Pin the version as necessary and call it a day. usually my requirements files for local, dev, QA and production are 30 lines total. Js land is a complete shit show of ever changing dependencies with an ungodly amount of sub dependcies that will break every thing

> And my biggest surprise is how Javascript turned from one of the most hated programming language ( besides PHP ? ) into being acceptable and loved.

I think a primary reason for this is that Javascript first was a language that was easy to hate because mistakes couldn't be fixed - "don't break the web" and all that. The community then found a way to improve it without breaking the web: add improvements with different syntax, and let your editor/build system/whatever use a linter to deprecate the old syntax from your personal codebase. It's greatly improved in that way and now easily holds a candle to other long-term popular languages.

> I really wish other languages communities do a similar survey, Python, PHP, Ruby, Java, Rust etc... It will be interesting to see the trend and big picture.

2018 state of Haskell survey results:

https://taylor.fausak.me/2018/11/18/2018-state-of-haskell-su...

Regarding GraphQL, I think the reason is at least partially that there aren't too many applications that actually benefit from the all-dynamic approach of it. It's neat and useful in certain applications, but I wouldn't use it everywhere. The tooling isn't quite there yet also in my opinion, but the friction will probably go away with time.

I agree that the dynamic querying aspect of it isn’t useful in most apps but the way graphql simplifies your API (and maybe your state management) compared to REST is by itself, I think, worth it. Tooling seems to be ramping up quickly but I agree, isn’t there yet.

Yeah, I assume the low usage of GraphQL in this survey coordinates/correlates with the low usage/knowledge about Apollo in this survey. Apollo seems the most invested in ramping up strong tools for GraphQL, so of course developers aren't likely to be using GraphQL if they haven't yet heard about/explored Apollo's efforts.

For instance, apollo-link-rest would be a strong way to bootstrap into GraphQL for shops with heavy REST investments.

That said, Apollo aren't yet doing themselves favors with nearly every part of their tooling still showing a "Caution: Active Development" warning. That keeps them right on that cusp of "Should I use this in production?" worry for enterprise, and slows adoption probably more than they intend.

It's a data access language where data sources are a far secondary concern for the tooling, and it looks like the tooling does not care about access control at all.

The standard looks great, and with some time some useful tools will probably arrive. But not right now.

> Angular is dead? Most don't even want to touch it again ( Great ).

Yet what I see around me is enterprise customers on our projects adopting Angular as the official internal Framework, as React is seem as too advanced.

Most of HackerNews isn't enterprise hackers. At least the active commentators.

Is that the assumption or for fact? I see people with very diverse background here.

I don't have stats to back it up, talk to pg for that :)

But it's not that hard to figure out based on comments, upvotes, stories on the front page, etc.

Consider it an educated guess from a relatively active HN member who's been here for 5 years :)

as someone who tried Angular and was so relieved with the simplicity of React, I have no idea how they can come to that conclusion. But then again, I'm not very well know with the field of enterprise customers

React requires too much FP concepts for the typical average enterprise developer.

It feels like doing Haskell with JavaScript.

You can write haskell style in any language. but you don’t have to.

function MyComponent(props) { return <p>Hello {props.name}</p> }

    import React from 'react';

    export default ({name}) => <p>Hello {name}</p>;

So much nicer than Angular.

> You can write haskell style in any language.

It would be great if that was true. The fact is that you can not copy Haskell in any mainstream language (Lisp gets the closest), and that hurts.

I dunno--most of what I end up doing has state, if not context. Not super Haskell-ish.

I've got the same feeling but with bad connotation.

React is easy the same way jQuery is. Easy, unstructured, foggy, too much permissive tool.

Far too easy to end-up with spaghetti-code.

I prefer not using it, Angular is far more organized.

Like another reply.

    // MyHello.jsx
    import React from 'react';

    export default ({name}) => <p>Hello {name}</p>;

Now do the same in Angular.

I cannot speak for GP but for me the complexity comes from stitching dozens of libraries to get similar "base" to build the app on. Ember/Angular have way more stuff baked in or standardized, while in React you have to handle ball of ever changing dependencies ... For seniors it's ok(-ish) tradeoff (you get much more choice / control), for juniors it is hell on earth.

But that is more of an issue for projects maintained for a long time. If you want to crank out small apps fast, your "example" is relevant, and React definitely is the better option.

What do you need that isn't in the box with React? Aside from fetch, which is in all modern browsers? The new Context component interface pretty much flushes out the last of what you are likely to need. As much so as what you get in the box with Angular. Even then, with Angular you'll usually need at least a visual component library, and with React, disparate components tend to work together with less friction comparatively.

Well if you focus on components only in your app then sure, not much needed. But complex apps need much more, like testing infrastructure, routing, data layer, service layer, tons of utility functions (last time I toyed with React it did not even have debounce ... Library for UI w/o it seems weird for me) and likely something else.

But hey, most apps are simple, so no need for all the above. I would say Ng/Ember are more specialized / niche.

"Hello world!" programs or their slightly more sophisticated variation, the to-do list app, aren't a realistic measure when it comes to actual real-world software that has to solve real-world problems.

The survey results this year is misguided as it now mixes AngularJS with Angular. Was surprised they made such remarks in the conclusion knowing this change. Most AngularJS users will not use it again for sure.

Since I mostly work in the enterprise (in Europe) I see Angular all around me as the de facto framework. It's definitely not dead. With TypeScript it's a pleasure to work with.

I think a lot is due to the unfortunate naming, people still confuse AngularJS (v1) with Angular (v2-v7). I totally believe a lot of folks will say "Used AngularJS (v1) won't use it again".

Same. I don’t think this survey is representative of the enterprise at all. In fact, it seems like responses are down this year from last year from what I can tell. 20,000 is not a huge sample size in this market.

When having a few conversations a few years ago with enterprise devs, the React license was seen as a problem[0][1], and Angular wasn't, so the default path was from the top-down to go with Angular, for those I spoke to. This was also when Angular 2.0 was new and the comment was also "This is moving too fast".

Once enterprise chooses a tool, that tends to stay the tool for that project, then all of the team is competent in the tool after a couple of years working with it. There's a critical time-frame when new competing tools win a geographical majority [2].

[0] Link to facebook announcing Reach license changes: https://code.fb.com/web/relicensing-react-jest-flow-and-immu...

[1] Link to short article on MIT-Patents license in reack. Takeaway: This has never been litigated before https://hackernoon.com/4-lessons-from-the-react-patent-licen...

[2] Geographical majority http://www.businessdictionary.com/definition/geographic-mono... replace 'place' with 'technology tool'

While 2+ is definitely better, I would still prefer to never use it again. To me, React + JSX is the most natural abstraction for component development. Vue is probably second, but tends to introduce complexities that make things harder for mid-large apps imho.

Yes, it is quite a fact that enterprise businesses tend to adopt Angular as it has more sort of an enterprise appeal due to its popularity and being backed by Google.

I had a friend (F) interview for a FE developer position. He was more of a React adopter and he spoke with the architect (A) of the team. The company was heavily invested into MS technologies (think a lot of WCF Services)

F: So, what technology stack are you moving into? A: We wanted to retain as much of our backend WCF stuff, while we move our front-end into Angular. F: So has there been a project that was started? A: Yes, we have started to move 8 of our enterprise apps to Angular. F: Any challenges so far? A: Well, the code seems to become a little too complicated for our developers to work on. We'd like to get it to a cleaner and more maintainable state. F: Have you considered other frameworks? A: Sadly, no. Company has invested more than 2 years in re-designing the app. And besides, Angular is backed by Google, hence, we seem to think that it will be the right tool for the business. We've invested a lot of time as well with it. F: But you are saying that productivity overall is low because the complexities of your Angular code base is taking a toll on your developers? A: Yes, in some sort of ways. There are Angular constructs which just does not make sense. And nipping the warnings and errors in the console is just a task that's too heavy and tedious. Although we like the fact that Angular can play nicely with our backend stuff with very minimal changes required on that side.

Practically, the architect was saying that the enterprise adopted Angular due to its immense popularity way back then and being heralded as an Enterprise framework.

Although my friend was offered a very good salary (by Canadian standards), he politely declined the offer, after inspection of some of the code base and the challenges that he would be facing.

That sounds more like a quality problem of the particular dev shop than an indictment on Angular.

I think the conclusion chart shows it clearly: Angular has very high usage (nearly as much as React) and very low satisfaction in using it.

(Which is often what you would expect of enterprise development: go with the solution "everybody else uses", whether or not everybody else enjoys using it. ;)

IMHO Angular in its recent versions is the most simple front-end framework ever. It's not even JS anymore. It's type script + reactive framework. Those 2 things makes programming extremely easy.

I keep repeating myself here...

    import React from 'React';

    export default ({name}) => <p>Hello {name}</p>;

Now duplicate in Angular and tell me it's simpler.

what's the point of this? I mean, Angular has its use cases aswell as React does. The point you are trying to achieve leads to nothing.

My point was, angular is emphatically NOT the most simple component option. I, personally, can not think of a single use case where Angular (any version) is a better option than React, Vue or Polymer.

If I were to write such an app, html + vanilla js is more than enough.

The point was in response to how "angular is the most simple..." where it is emphatically NOT so.

After having dropped Angular in the 1.3.x days, I was pleasantly surprised by how much it's changed. There are still a few mental concepts a new programmer would have to grasp (DI, observables, OO, type-safety) but overall, it's not too bad. I'm not sure I could call it "simple" though. Maybe I'm conflating simple with "easy". I'm of the few that still believe in Redux though. A one-way data flow, a finite state-machine, a new version of the state on every action.... that just defines "simple" to me. (not arguing at all)

All right, my background is 10 years of .NET programming where DI, OOP, type safety are fundamental concepts, so having these things in the front-end framework is extremely helpful.

>> And my biggest surprise is how Javascript turned from one of the most hated programming language ( besides PHP ? ) into being acceptable and loved.

For real?

I personally think JavaScript is awesome.

I personally think jQuery is awesome.

And I feel really alone a lot of the time in these opinions. I see a lot of disdain for JS here in comments in particular.

I also see a lot of people browsing with JS disabled, and who complain when a site doesn't function without it.

>Given the amount of hype with GraphQL, I am surprised only 20% are actually using it.

Glad to see people don't adopt things only because they are hyped.

You've never been or spoken at a JS meetup... the whole audience glazes over whenever you talk about something that's not hyped right now.

At the end you'll even hear questions like "So where do I add <insert hyped thing here>"

New JS dev's in the last few years have been under the idea that using whatever is hyped is cool... ignoring that it's not stable and you shouldn't probably use it in production.

> TypeScript is gaining ground, people are moving away from Flow.

Is it really the case? Both projects are watched and have quite big number of stars in github.

I have tried flow and liked it. I have used typescript in the past and I'm not crazy about it. Therefore I would like to get better understanding here. Is there anything I could read about it?

I don't have hard data, but a large part of this is probably ecosystem. TypeScript updates more often and, most importantly, almost every relevant library has TypeScript type definitions available. Interesting hard data would be the percentage of popular libraries with TypeScript type definitions available vs. those with Flow definitions available. I'm quite sure that would heavily tilt towards the former, though.

Don’t have to take the survey so seriously. It’s not representative of all JS community. My circle of JS hackers don’t even bother to participate.

Is there any reason to suspect Flow users are less likely to do the survey than, say, TypeScript users?

I can speculate here a little bit. Majority of survey users has less than 10 years of experience. That makes them susceptible of being Visual Studio Code users. VSC - Microsoft product. Typescript is Microsoft product as well.

I am curious (as a VSCode user) what makes you conclude that junior devs are likely to use VSCode?

It is really good tool and free one. Better tools are either commercial or requires a lot of learning.

You're mistaking "representative" with "inclusive".

The survey can be a representative sample, without including your ̈́"circle of JS hackers". That's how surveys work.

The proportion of Flow users who said "would not use it" has increased substantially over the past year. (24% vs 41%)

I started using TypeScript professionally for the first time this year. A few more datapoints: I've had recruiters calling me for TypeScript projects, but not for Flow. This is in the Netherlands.

GraphQL has a LOT of boilerplate to be able to use it. In many situations the effect is barely, if at all better over direct REST/RPC API end points. That has a lot to do with only 20% using it.

I really wish more would migrate to Koa over Express, but I get it.

As to the JS Love, I think there's still plenty of hate around.

The State of Rust is a yearly survey:

Unsure if the 2018 results are done?

https://blog.rust-lang.org/2017/09/05/Rust-2017-Survey-Resul...

Still analysizing them. Soon though!

Rust do a survey, https://blog.rust-lang.org/2018/08/08/survey.html

Just curious why no one want to touch it again? I never developed with Angular but I loved to develop with AngularJS (and still working with it). Can anybody entlighten me?

My personal experience (used Angular JS and EmberJS, before React) -- AngularJS (like Ember) required a lot of Angular _specific_ understanding to use properly, and (_unlike_ Ember) some of those had significant performance impacts. When I switched to React, i felt like there were 3 or 4 API's I needed to understand, and that the escape hatch was easily reachable at all times. There were numerous features I extended deadlines for in Ember and Angular where I would say to my teamates: "I could solve this with Javascript, but how do you handle this in Angular?". Some people are ok with that tradeoff, but both sides feel relatively strongly about that particular choice.

> Angular is dead? Most don't even want to touch it again

Quite the opposite is happening from what I'm seeing. More people seem to move away from React towards Angular, but that's just my anecdotal observation.

That's just absurd - I have no love for React, but I can't imagine why anybody would adopt Angular now.

why? because you don't like it? Angular 2+ is the perfect transition for most of the developers who are used to do Desktop or Backend development and want to jump to front end stuff. In the enterprise, Angular 2+ is loved over any other framework. Is the best one? who cares.

Of the several dozen people I know who've used Angular and React, I know only one that would prefer Angular. Also the only one that would use Angular over Vue with experience in both.

Reply on news.ycombinator.com