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

201–210 of 357 posts

Re: The State of JavaScript – Survey results

#201

Post by nogridbag »

epmatsw wrote: post #3

Super interesting. Lots of data there. Two things that stood out from a quick once-over: Vue is doing better than I expected. PostCSS is less adopted than I expected.

I've been toying with Vuejs 2.0 for a few days. Thus far I'm very impressed with it. The docs are a quick read and the whole framework feels really intuitive.

I'm a big fan of Vue's single file components where you can keep a component's HTML template, CSS, and view model code together in one file. In React, I tended to use lots of inline styles. I also like that I can use templates for the majority of the simple cases while still having the full power of a React like render function (with JSX support) if needed.

Re: The State of JavaScript – Survey results

#202

Post by errozero »

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 worked on an Ember project once, the first JS framework I ever used. It really frustrated me that I had it had to use Babel to convert the ES6 into ES5. For some reason, on my laptop, that took about 10 seconds, so every time I wanted to check if some new code worked as expected, there was this long delay. There were a lot of other issues I had with it too.

I love working with straight Javascript (ES5), jQuery and template engines like handlebars. I can design things in a way that works for the project and can quickly just refresh the browser to check my changes.

Re: The State of JavaScript – Survey results

#203

Post by shados »

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.

Yes, yes it can. And because it can isolate tests and reset the environment, you don't really have to be (very) careful about what you do in your tests so order doesn't matter. It makes it really hard to fail there.

Re: The State of JavaScript – Survey results

#205

Post by shados »

rajington wrote: post #136
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 love Jest, but thought the 59% satisfaction with Jest was unfortunate... probably super-early adopters?

Jest used to be very meh. Also, Jest by default would cater to more "purist" unit testing. Everything mocked, everything isolated, runs in node, no browser.

A lot of people in the frontend world equates unit testing with Selenium tests (aka: integration tests) and get really ruffled/confused by "pure" unit tests.

Now Jest changed the defaults to what most people expect, which will confuse them less, I suppose.

Re: The State of JavaScript – Survey results

#206

Post by wreft »

OhSoHumble wrote: post #198
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…

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

"Ah, maybe you're right. I think I'm used to configuration over convention "

I think you meant the reverse.

Re: The State of JavaScript – Survey results

#207

Post by OhSoHumble »

errozero wrote: post #202
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 worked on an Ember project once, the first JS framework I ever used. It really frustrated me that I had it had to use Babel to convert the ES6 into ES5. For some reason, on my laptop, that took about 10 seconds, so every time I wanted to check if some new code worked as expected, there was this long delay. There were a lot of other issues I had with it too. I love working with straight Javascript (ES5), jQuery and…

There really is something to be said about simplicity. I love getting Flask/Sinatra/Spark/microframeworkhere and then just rendering a server side template that gets manipulated client side by jQuery. It's hard to move away from that sometimes.

As far as conversion, I don't notice transcompilation times. I'm at Ember 2.8 and whatever other versions that were setup.

Re: The State of JavaScript – Survey results

#208

Post by shados »

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.

because real webapps, that actually do stuff that can make money and keep users happy, are complicated.

Even now, Webpack is kind of feature anemic compared to what the real world needs. We just do with what we have. Or in the case of companies with $$$ to hire devs to work with it, we just build a shitload of plugins and loaders.

Re: The State of JavaScript – Survey results

#209

Post by OhSoHumble »

wreft wrote: post #206
OhSoHumble wrote: post #198

Earlier quoted context omitted.

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

"Ah, maybe you're right. I think I'm used to configuration over convention " I think you meant the reverse.

You are correct! Edited. Thank you for pointing that out.

Re: The State of JavaScript – Survey results

#210

Post by spion »

darksaints wrote: post #72
aidos wrote: post #52

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

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…

The right way to get rid of mutable state is to replace it with a stream abstraction, which declaratively models how the state changes in response to events. That would be cyclejs: http://cycle.js.org/

Too bad that this model doesn't work well with React. React models the UI as a (mostly pure) function from props/state input to DOM output, however in reality the UI is a stream containing both DOM states and input events. The minimal modification would be to select the input events that a component would like to expose in its event stream, in a similar manner to Elm: https://guide.elm-lang.org/reuse/checkboxes.html

Post reply on HN