The State of JavaScript – Survey results • Hacker News Board

Re: The State of JavaScript – Survey results

#191

Post by lossolo » Mon, Oct 03, 2016, 9:23 PM UTC

OhSoHumble wrote: post #152

It's really unfortunate that so many people aren't interested in learning Ember. I just started an internal IT tool in Rails and Ember and I'm really enjoying the simplicity of it. I want something that is easy to understand, easy to setup, and won't change for a while. I became more interested in Ember when I read something online about how they are focusing on stability in the long term instead of a bunch of featur…

If you are building simple app then it's really easy with Ember but you need to remember that Ember is very opinionated and if you need something that is not exactly standard or creators didn't predicted that someone would use something in certain way then you have problem and you spend time fighting with framework. I've been there, lot of time wasted fighting with Ember in corner cases but if you get this out of the equation Ember is really good and you can be really productive using it.

Re: The State of JavaScript – Survey results

#192

Post by mmmpop » Mon, Oct 03, 2016, 9:24 PM UTC

pauljaworski wrote: post #89

>Overall, developers are not happy about JavaScript testing. This is because of the low percentage of devs in the survey who have used Jest. I can't begin to describe the joy of finally finding a JS test utility that just works and doesn't require a giant configuration file. If you aren't using Jest, make the switch now! It's likely a lot of your existing tests will work with Jest.

Can Jest run concurrent tests? I'm using Tape as of late and I find myself having too many long-running functional tests in series but it doesn't seem to be something I can work around.

Re: The State of JavaScript – Survey results

#193

Post by OhSoHumble » Mon, Oct 03, 2016, 9:26 PM UTC

lossolo wrote: post #191

OhSoHumble wrote: post #152

It's really unfortunate that so many people aren't interested in learning Ember. I just started an internal IT tool in Rails and Ember and I'm really enjoying the simplicity of it. I want something that is easy to understand, easy to setup, and won't change for a while. I became more interested in Ember when I read something online about how they are focusing on stability in the long term instead of a bunch of featur…

If you are building simple app then it's really easy with Ember but you need to remember that Ember is very opinionated and if you need something that is not exactly standard or creators didn't predicted that someone would use something in certain way then you have problem and you spend time fighting with framework. I've been there, lot of time wasted fighting with Ember in corner cases but if you get this out of the…

Yeah, I do like the convention over configuration approach. Sails is somewhat similar. Not fighting against "the Ember way" is valid advice.

However, I see this advice everywhere. When I'm googling "how do I do this in Ember" I usually get a good set of practices.

What's interesting, is there is another thread on HN about a WalmartLabs platform release that bundles React and a bunch of other boilerplate libraries a la Facebook's "create react app" and it looks really cool.

Re: The State of JavaScript – Survey results

#194

Post by ggregoire » Mon, Oct 03, 2016, 9:28 PM UTC

pauljaworski wrote: post #89

>Overall, developers are not happy about JavaScript testing. This is because of the low percentage of devs in the survey who have used Jest. I can't begin to describe the joy of finally finding a JS test utility that just works and doesn't require a giant configuration file. If you aren't using Jest, make the switch now! It's likely a lot of your existing tests will work with Jest.

The survey should separate unit testing and e2e testing.

I don't know what the general feeling about e2e testing in the JS community, but in my last job we had to write, fix and maintain hundreds of e2e tests and it was a nightmare.

Our stack was Angular 1 and the de facto Angular e2e tool, Protractor. We wrote tons of helpers, like waitToBeVisible & waitToBeHidden, most of them copy/pasted from StackOverflow because every users of Angular and Protractor have the same basic troubles and use the same workarounds, and we had to use those helpers in every test. Also I can't imagine the number of hours spent to mock our Angular services + MySQL/Redshift data, to spy the functions who manipulate url/cookies/localStorage/etc and to write some "page objects" to make the tests readable.

In my opinion: The benefits of the e2e tests are too small to justify the crazy amount of time spent to make the new tests work and maintain the existing ones. Most of the time, the tests break because someone has changed something in the DOM or renamed a CSS class or modified an external API and forgot to update the tests/mocks. But they almost never break for a regression... so what's the point?

Or otherwise you need a dedicated team with 1 or 2 engineers (for a small/medium company) working full time on the e2e.

(PS: I used only Protractor with Angular 1. I haven't tested the other tools like Nightwatch.js, and I don't know what they have done for Angular 2 (Protractor 2?). Now I develop in React and just do unit testing & dog fooding).

Re: The State of JavaScript – Survey results

#195

Post by erikpukinskis » Mon, Oct 03, 2016, 9:33 PM UTC

OhSoHumble wrote: post #152

It's really unfortunate that so many people aren't interested in learning Ember. I just started an internal IT tool in Rails and Ember and I'm really enjoying the simplicity of it. I want something that is easy to understand, easy to setup, and won't change for a while. I became more interested in Ember when I read something online about how they are focusing on stability in the long term instead of a bunch of featur…

I think Ember is great, and agree more people should use it, but it is NOT simple. It is easy, but it is extremely complicated.

Ember follows in the Rails tradition of "convention over configuration". This means common activities can be done with a simple command, creating a file, or adding a flag in the right place.

This comes at a price: everything that happens in your Ember app is deeply tangled in Ember internals which are very complex.

This means adding behavior leads one of two places: It Just Works, or you have no idea what is happening or what to even ask.

When you are an Ember beginner this second state can last for days or weeks of frustration. As you learn about Ember internals, it happens less often and you move through it quicker, but expect this to take months or years.

The Ember team has taken steps to mitigate this difficulty: adding great error messages, and adding great documentation. But it a fundamental downside to the architecture they have chosen. And it's fundamentally at odds with what I would consider the Node Ethos, which is small packages that do one thing cleanly.

I would recommend Ember to professional developers who have the time to really learn about its internals and can afford to lose a week here and there to tricky debugging challenges.

I would not recommend it to developers working on small projects with tight deadlines.

Re: The State of JavaScript – Survey results

#196

Post by OhSoHumble » Mon, Oct 03, 2016, 9:33 PM UTC

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…

I'd like to dive into React sometime when I get a side project that needs web development but I am a simple guy and I need a "hey stupid follow these conventions" setup in order to learn and grow and be productive.

There are a couple projects out there that do this but they're new. The WalmartLabs Electrode project looks incredibly slick and has good documentation so maybe I'll spend an hour or two with it this upcoming weekend.

Re: The State of JavaScript – Survey results

#197

Post by saosebastiao » Mon, Oct 03, 2016, 9:35 PM UTC

indexerror wrote: post #186

darksaints wrote: post #72

Earlier quoted context omitted.

After using Mobx for a few weeks, I've come to question why anybody would use anything else. It is the only software I've ever used that was created for a dynamic language that has me trying to re-implement in my favored strong/static typed languages. Now I just point and laugh at anybody trying to make sense of their Redux global state atom with a bajillion reducers. So far, I've only found one common objection to i…

> They need mutable state because their entire existence depends on it. Sure, you might be able to model the mutable state of UIs using immutable data structures, but you can't get rid of the mutable state. Can you give an example of this? I have worked on fairly complex Redux applications but have never ever mutated states and it has been just fine. In fact, I use ImmutableJS to keep my apps' states. State machines…

If you haven't mutated states, you don't have an interactive UI. With immutable data structures holding your state, you mutate it by re-assigning variables. This is exactly what Redux does.

In fact, the rendering benefits of immutable data structures comes from the fact that you can perform equality comparisons by reference safely, and ref comparisons are faster. Any time you re-assign a variable, you change that variable's reference, and it is no longer necessary to deep check the reference's value to know that it changed.

Re: The State of JavaScript – Survey results

#198

Post by OhSoHumble » Mon, Oct 03, 2016, 9:42 PM UTC

erikpukinskis wrote: post #195

OhSoHumble wrote: post #152

It's really unfortunate that so many people aren't interested in learning Ember. I just started an internal IT tool in Rails and Ember and I'm really enjoying the simplicity of it. I want something that is easy to understand, easy to setup, and won't change for a while. I became more interested in Ember when I read something online about how they are focusing on stability in the long term instead of a bunch of featur…

I think Ember is great, and agree more people should use it, but it is NOT simple. It is easy, but it is extremely complicated. Ember follows in the Rails tradition of "convention over configuration". This means common activities can be done with a simple command, creating a file, or adding a flag in the right place. This comes at a price: everything that happens in your Ember app is deeply tangled in Ember internals…

Ah, maybe you're right. I think I'm used to convention over configuration setups so it feels a lot more comfortable to me. I think that maybe that's why its so popular with Rails developers because they're used to operating within the bounds of the prescribed architecture and then having to deal with edge cases.

I think, for me, I feel comfortable debugging as long as I understand the idea that is trying to be communicated. I think "weeks of frustration" is a bit of hyperbole but that's just my opinion. I can see days lost... but I think that's true of any technology stack that you're trying to acclimate to.

I also don't know about the last sentence about not recommending it to developers working on small projects. I don't have tight deadline but I find that it's working for my small project. As long as I'm not doing anything too far outside of CRUD operations translating into a view then I'm fine.

I don't think I would power a company with Ember. Though, granted, I don't have the experience to really make a call like that... but I would relay my personal experiences to a single developer looking for advice and suggest it for them if they're used to Rails or Django or some other massive convention over configuration back end framework.

Re: The State of JavaScript – Survey results

#199

Post by dwaltrip » Mon, Oct 03, 2016, 9:43 PM UTC

djokkataja wrote: post #85

vlunkr wrote: post #64

For the life of me I can't understand why webpack has become the de facto build tool. It's so much more complex than anything else I've tried. I understand it's supposed to be faster, but still, I wouldn't bother with it until your build times actually start to become a nuisance.

I switched from browserify to webpack when I started writing ES6 on the client because the browserify build times with ES6 were slow enough that they felt disruptive to my workflow (somewhere between 10-30 seconds, I don't remember the exact amount). I'm not sure if that's improved now for Browserify, but it's the kind of thing that you're not likely to switch back from once you have a working setup.

I use watchify [1] for incremental builds. The initial build is still long (10 - 30 seconds, as you said), but with each change after that the build updates in [1] https://github.com/substack/watchify

Re: The State of JavaScript – Survey results

#200

Post by fail2fail2ban » Mon, Oct 03, 2016, 9:45 PM UTC

ng12 wrote: post #132

fail2fail2ban wrote: post #127

Earlier quoted context omitted.

> Web application development is hard Replace JavaScript with Java in all browsers and make it much easier, dependable, predictable and reliable.

Well yeah, that'd be great. But the unfortunate reality is Javascript is the lingua franca of the web and we have to make due until there's a reasonable alternative. Furthmore, it's not even JS that's really the problem. It's the entire JS/DOM/CSS stack.

I like the DOM, basic CSS is fine. The twisted stuff some people do with CSS I'm not fine with but yeah I know. JS isn't going away, what irks me the most is the naivety around trying to push it to the backend. It doesn't belong in the backend when the frontend story is so messed up.