Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The State of JavaScript – Survey results

stateofjs.com

Post reply on HN
Print view View original

51–60 of 357 posts

Re: The State of JavaScript – Survey results

#51

Post by wvenable »

Klathmon wrote: post #25
anamoulous wrote: post #24

I apologize if the predictability of this comment, but I just want to say, I recently started a new gig at a company that has undergone a full on embrace of Javascript for tooling and server side projects and it boggles my mind how much productivity is wasted on this ecosystem. There is an interesting amount of energy put into making asynchronous code read synchronously in situations where asynchronous code provides…

Could it be that you are still just new to it (in the grand scheme of things)? Because all of those things sound very similar to the complaints I hear from web developers on their first foray into desktop development. There are so many tools it's impossible to know them all (or to even know which one is best to use in which situation), so much legacy code out there it's tough to learn what the "right" way to do thing…

> Application development is hard, and is still far from "solved".

I'm surprised you feel that way; I always find it nice to do plain 'ol desktop development because it does feel solved. Everything is clean, quick, and heavily documented. Much of the languages, frameworks, and libraries have been around for decades.

Re: The State of JavaScript – Survey results

#52

Post by aidos »

I'd love to hear more from people that expressed certain viewpoints - specifically those who used a library but wouldn't use it again... Specifically mobx :)

I've played with most popular js libs now and I've found that for my use case I wasn't totally happy for one reason or another. I've been dabbling in mobx for that last few weeks and the ease with which it has allowed me resolve issues in my codebase is really promising.

If anyone here is in the 58 people who wouldn't use it again, care to share what you ran in to?

Re: The State of JavaScript – Survey results

#53

Post by [deleted] »

anamoulous wrote: post #38
Klathmon wrote: post #25

Earlier quoted context omitted.

Could it be that you are still just new to it (in the grand scheme of things)? Because all of those things sound very similar to the complaints I hear from web developers on their first foray into desktop development. There are so many tools it's impossible to know them all (or to even know which one is best to use in which situation), so much legacy code out there it's tough to learn what the "right" way to do thing…

I'm not going from backend to frontend or desktop apps. I'm going backend to backend. I guess part of my point is I'm made uncomfortable by the encroachment of Javascript into areas where it's not particularly well suited, and the historical baggage it must carry into those areas. It's the when you have Javascript as a hammer, everything looks like a nail issue. I don't think my organization is unique in its embrace…

[deleted]

Re: The State of JavaScript – Survey results

#56

Post by morgante »

It's nice to see some love for Apollo here. It's leagues better than Relay and has definitely been the biggest boon to my development stack in a while. That being said, the article should make it clearer that Apollo is perfectly usable just as a frontend client—you don't have to adopt the backend at all.

The Meteor team really deserves commendations for learning from some of the mistakes in building Meteor. Apollo specifically emphasizes incremental adoptability: you can drop it into an existing project and see benefits almost immediately, without having to refactor/rewrite any of your existing code.

I'd also like to provide a counterpoint to the inevitable complaints about the complexity and low-productivity of a JavaScript. In my experience, once you've paid the initial cost of learning these tools you can become extremely productive. As a freelance developer who is paid a flat rate for projects, I'm directly incentivized to find an efficient stack and the modern JavaScript stack is definitely it.

Specifically, my stack these days is Django + Graphene + React + Redux + Apollo. It's insanely high productivity: I can usually have the basics of an app built within a few hours of starting.

Re: The State of JavaScript – Survey results

#57

Post by hood_syntax »

talmand wrote: post #34
Aldo_MX wrote: post #19

Earlier quoted context omitted.

To be fair, a side effect of JS Fatigue is the inability to tell whether "Plain JavaScript" is the newest kid on the block or if it really means "good old JavaScript (ES3)". Especially when the headline is "JavaScript Flavors".

Exactly, I've seen discussions about vanilla-js.com suggesting that people thought it was a real framework.

Poe's Law, maybe?

Re: The State of JavaScript – Survey results

#58

Post by majormajor »

ng12 wrote: post #9
grabcocque wrote: post #7

This seems to suggest the rate of framework churn has rather settled down. Are JS devs finally starting to be satisfied with their current tools and not needing to restart every 18 months?

I see this same, tired old meme in every thread about web technologies. It's funny to me that certain people are so disdainful of the churn in web development on a forum dedicated to "hackers". Web application development is hard, and the reason why there's so much churn is because smart, inventive people are constantly finding better ways to do things. Things aren't just resetting from scratch every 18 months. The w…

> The web apps I'm working on today are way more modular, composable, testable, and maintainable than the ones I was writing as little as two or three years ago.

The better question is: are the apps someone with two or three fewer years of experience than you more modular, etc?

My experience is on the backend rather than the frontend, but in that domain, at least, system quality is still way more about developer maturity than ecosystem maturity. You can figure out a terrible, hard-to-maintain lazy way of solving today's immediate problems in any language.

Re: The State of JavaScript – Survey results

#59

Post by Touche »

lhnz wrote: post #47
Touche wrote: post #35

Earlier quoted context omitted.

You're spinning this as a positive thing, but the fact that a UI library needs its own build tool does not speak well to the state of front-end development. Specifically the fact that we still don't have modules or widely-deployed http2 is what makes the build tool complexity necessary.

I wouldn't say that was spin, I said that build complexity is likely going to be handled by fewer engineers. The underlying problem still exists but less people need to put their oar in: that's bittersweet.

You're pointing to create-react-app as a solution to JS churn when it was just created 2 and a half months ago.

The fact that people keep thinking that a 2 and a half month old project is the solution to all of their web development problems is exactly why there's so much churn.

Every new tool overtakes the previous generation by being superficially more simple, only to add complexity of its own over time until the next generation repeats the cycle. It turns out the complexity is there whether you acknowledge it or not, and over time your leaky abstractions will burst.

Re: The State of JavaScript – Survey results

#60

Post by tracker1 »

GnarlyWhale wrote: post #45
Roboprog wrote: post #14

Some interesting things on the "Front End Frameworks" page: * 53% of the respondents used React, and would do so again. * 47% use "No framework", and would do so again. (hmm. that doesn't leave much room, unless you can use more than one tool depending on the situation) * 43% had "no interest" in Angular 2. One other thing to consider, of the "had used X, would/would-not use again" responses: there is of course a lot…

For the record, you don't need to use Typescript for Angular 2, you can just use regular JS (or Dart for that matter). The documentation is definitely biased toward Typescript at the moment, but I anticipate the situation improving as the framework matures.

I used it (ng2) across 3 versions (beta 3-5 iirc), I used the flow type transformer via babel, which worked well enough. It'd be VERY difficult to do without some transpilation that allows the directive-style to be used.

For me, a lot of things in the templating seemed goofy, and had horrible, or no error messages when they didn't work right... I also still don't care for the DI system, though it's definitely a leap from ng1, I'd still prefer React over ng1 or ng2.

Post reply on HN