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

271–280 of 357 posts

Re: The State of JavaScript – Survey results

#271

Post by rhizome »

alasdair_ wrote: post #242
erikpukinskis wrote: post #195

Earlier quoted context omitted.

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…

>"everything that happens in your Ember app is deeply tangled in Ember internals which are very complex." and >"it's fundamentally at odds with what I would consider the Node Ethos, which is small packages that do one thing cleanly." You could substitute "Ember" with "Microsoft Windows" and "Node" with "UNIX" and be just as correct. I wonder how frequently this design/philosophy decision comes up.

If I understand the saying correctly, this idea might be contained in the aphorism, "encapsulation breaks inheritance."

as a service!

Re: The State of JavaScript – Survey results

#272

Post by pixelhandler »

joshowens wrote: post #215
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 suspect that we didn't get enough Ember responders, because I do think they have a reasonable sized community. 9k responses is likely not enough to draw a reasonable conclusion that it isn't popular. I wish we could have paired up npm downloads or some other stat besides some of this data...

Been using ember productively for years; didn't even see the survey link

Re: The State of JavaScript – Survey results

#273

Post by steveax »

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…

We have a pretty large Ember app that consumes a variety of data from many sources (clojure services and middleware). I find I rarely have to "fight" the framework, but often have provide overrides through the various lifecycle hooks. Usually these patterns are well established and documented, but it does mean learning a pretty large API.

Re: The State of JavaScript – Survey results

#274

Post by increment_i »

For me, the beauty of JS was in its simplicity - there were wacky edge cases for sure, but here was a C-like language that you could use to build a project that almost anyone could understand. When Node first came out I was over the moon - wow, I can run processes on the machine from JavaScript?! Unreal.

It seems like I'm constantly keeping up with the complexity of the ecosystem, which is taking a toll on my productivity. This is probably my problem more than any specific failing of the evolution of the language, but, I like to ship.

Just my 2 cents to the discussion.

Re: The State of JavaScript – Survey results

#275

Post by bbcbasic »

increment_i wrote: post #274

For me, the beauty of JS was in its simplicity - there were wacky edge cases for sure, but here was a C-like language that you could use to build a project that almost anyone could understand. When Node first came out I was over the moon - wow, I can run processes on the machine from JavaScript?! Unreal. It seems like I'm constantly keeping up with the complexity of the ecosystem, which is taking a toll on my product…

I don't get this. You are not forced to use ES6 features or ReactJS if you don't want to.

Just like you can use vanilla PHP, should you desire.

Re: The State of JavaScript – Survey results

#276

Post by mateuszf »

EugeneOZ wrote: post #214
Illniyar wrote: post #131

Earlier quoted context omitted.

That's technically true, but realistically false. Just like people used to say that you don't need to use JSX to write React. What's the point of using a heavy duty, opinionated framework without embracing it completely? that's just bound to get you into a whole lot of hurt.

You broke my hope to start using React. JSX smells too much for me. But thanks for the info, anyway.

That's typical for people who didn't use React yet. In practice JSX is awesome.

Re: The State of JavaScript – Survey results

#277

Post by cpojer »

mmmpop wrote: post #192
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.

Hey! I'm Christoph and I work on Jest. We wrote a blog post about how we are making Jest fast: facebook.github.io/jest/blog/2016/03/11/javascript-unit-testing-performance.html

If your test is fully CPU bound and limited to one core, it probably won't be faster with Jest. If you split it up across multiple files, it will parallelize tests.

Re: The State of JavaScript – Survey results

#278

Post by somlor »

saosebastiao wrote: post #197
indexerror wrote: post #186

Earlier quoted context omitted.

> 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 var…

> If you haven't mutated states, you don't have an interactive UI.

React allows you to treat DOM mutation as an expression of current app state.

This doesn't mean that your state itself has to mutate. It's entirely possible to structure a React (and/or Redux) app with fully immutable state, copies of which represent change. (Whether copies are done efficiently, e.g. via persistent data structure algorithms, or naively, e.g. via a deep clone, is secondary).

I'm befuddled where you're getting the impression that immutable data structures themselves require mutation.

Re: The State of JavaScript – Survey results

#279

Post by cpojer »

solidr53 wrote: post #114
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.

I used Jest early on, it was nice, but I quickly started to encounter problems related to how new it was. It's way better now, so maybe I will switch back to Jest from enzyme.

You can use Jest together with enzyme! We posted a big community update together with Jest 16 which should highlight a bunch of ways that you can test with Jest.

https://facebook.github.io/jest/blog/2016/10/03/jest-16.html

Re: The State of JavaScript – Survey results

#280

Post by zachrose »

alasdair_ wrote: post #242
erikpukinskis wrote: post #195

Earlier quoted context omitted.

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…

>"everything that happens in your Ember app is deeply tangled in Ember internals which are very complex." and >"it's fundamentally at odds with what I would consider the Node Ethos, which is small packages that do one thing cleanly." You could substitute "Ember" with "Microsoft Windows" and "Node" with "UNIX" and be just as correct. I wonder how frequently this design/philosophy decision comes up.

I hear very distinct echos of Rich Hickey's talk, Simple Made Easy.

In that talk, "easy" is defined as being nearby, familiar, or otherwise "at hand" to the person who is involved.

This is different than "simple", which is presented as an orthogonal concept meaning roughly "one operation" not tangled or interleaved with neighboring concepts.

This is a clear and useful way to think about simplicity in software (1). I think it's fair to say that the "do one thing well" aspect of the UNIX philosophy is a pretty good match to Hickeysian (?) simplicity. I haven't worked with Ember, but I think it's safe to say that Rails makes things "easy" that actually introduce significant interleaving to your app. The two examples I can think of are both about ActiveRecord: extending AR gives your classes an enormous protocol, and AR hooks deeply braid persistence to something whatever else it is that you're doing.

1) If you wanted to talk about simplicity as it relates to, say, product design you might be way off. When we talk about a product being simple, what we usually mean is that it integrates (folds together) many complex dimensions such as ergonomics, manufacturing, aesthetics, cultural signs, etc. into a single solution.

Post reply on HN