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

301–310 of 357 posts

Re: The State of JavaScript – Survey results

#301

Post by saosebastiao »

rifung wrote: post #297
saosebastiao wrote: post #182

Earlier quoted context omitted.

I didn't specify finite or infinite, and you're right that FSMs alone aren't sufficient to describe all UIs. But they are sufficient to describe nearly all interactive UIs. Your infinite button example still has a finite state, but it's not modeled explicitly, and would probably be a good idea, for very practical reasons, to do so. If it really goes on forever, you'll eventually run out of memory, whether that memory…

Interesting. I hadn't heard of hierarchical state machines. Thanks for the reply. If you don't consider the infinite button example, then what other kind of UI can not be described by a FSM?

I've certainly never found a common UI pattern that isn't describable with FSMs, but you could probably think of a few toy examples of non-terminating state. Anything involving recursion, exponential, or asymptotic behavior for example could theoretically involve infinite states. Again, likely of no practical use.

Re: The State of JavaScript – Survey results

#302

Post by bschwindHN »

fail2fail2ban wrote: post #200
ng12 wrote: post #132

Earlier quoted context omitted.

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.

Backend JS is not perfect by any stretch of the imagination, but if you limit yourself to plain data and functions and write simple code, it can really work nicely for getting stuff done and iterating on an idea.

Re: The State of JavaScript – Survey results

#303

Post by bjornstar »

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...

I think it's because Ember forces you to do everything The Ember Way. Sure they're technically writing JavaScript, but it only works in the context of Ember. Ember makes it extremely painful to use standard JavaScript libraries so it's not surprising that Ember developers don't respond along with the rest of the JavaScript community.

Re: The State of JavaScript – Survey results

#304

Post by bostonvaulter2 »

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 wish PostCSS had a good story for variables. As it stands it is just super poor. I use some PostCSS but sparingly.

Re: The State of JavaScript – Survey results

#305

Post by bostonvaulter2 »

davidjnelson wrote: post #244
tomatsu wrote: post #71

Earlier quoted context omitted.

Anecdotally, CS appears to have lost quite a bit of popularity while TS gained some. RedMonk seems to confirm these trends. TS grows while CS stagnates: Q1 2016: http://sogrady-media.redmonk.com/sogrady/files/2016/02/lang-... Q3 2016: http://sogrady-media.redmonk.com/sogrady/files/2016/07/lang....

Ts seems awesome but it looked like kind of a pain with separate ts and js files, mandatory type definitions not being present for lots of dependencies, and back when I looked at it seeming pretty all or nothing. I like flow. The people that built ts are brilliant too though. Curious if anyone has a good comparison between flow and ts. I've heard ts has improved a lot lately.

> mandatory type definitions not being present for lots of dependencies

That is the biggest detriment to typescript in my book. I played around with it for a bit but finding accurate (and up to date!) type definitions for external dependencies was a huge pain.

Re: The State of JavaScript – Survey results

#306

Post by somlor »

saosebastiao wrote: post #300
somlor wrote: post #295

Earlier quoted context omitted.

The DOM can be mutated just fine behind the scenes by React to reflect whatever brand new state has been passed into it. That brand new state can be anything. It can be a single (by definition immutable) integer. It can be a deep clone of an object. This is the ideal intended Redux architecture. Redux reducer(s) receive the state and return either the state untouched, or a non-mutated copy of the state. React reacts…

That is mutable state. Your Redux store is a mutable state container. If your redux store returns a {a:1,b:2}, and then you dispatch an action and it now returns an {a:2,b:1}, then you have mutated your state . It doesn't matter at all if the store's data structures are mutated in place or replaced with a modified immutable updated copy of a previous state, you still have mutable state .

I think I see where you're coming from, but I also think you might be moving the target a bit. I suspect you'd garner less debate if you said, I dunno, just "a dynamic UI app needs a way to model state changes". "Mutate" has a specific meaning, in my mind at least, when discussing variables and data structures. React enables avoidance of direct DOM manipulation, Redux obviates direct state mutation.

Re: The State of JavaScript – Survey results

#307

Post by ng12 »

bcheung wrote: post #175

One thing I have noticed over the years is that the front end community is becoming more and more a "let me google how to do it" kind of community. The tooling ecosystem is so burdensome. Just to get a hello world app with React, Redux, Webpack, esLint, and ES6 takes forever. Sure there are starter boiler plates but they all don't seem to do quite what you need. Before it felt more like a solidly engineered app, now…

I would only use React/Redux for a complex app that's going to be touched by a lot of people. That's where it really shines. Elm is a non-starter in these situations -- I can't seriously propose it for a project because the learning curve is astronomical.

Also, I think simple Hello Worlds are a dangerous thing. They convince you that a tool solves all your problems until three months later when you notice your foot's been blown off.

Re: The State of JavaScript – Survey results

#308

Post by increment_i »

nine_k wrote: post #289
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…

A "C-like language" is a very dubious compliment. Fortunately, JS is built around a different core. Unfortunately, it's built as haphazardly as C has been.

What I mean is that its syntax is classical. Its constructs will be very familiar to those who have taken basic education in modern programming.

As far as your 'different core' argument I'm not too sure what you mean. If you're a Node dev, then JS is just your means of calling OS routines and giving work to threads (in C under the hood, to be sure). If you're a front end person, then JS is a very high level layer again, making calls various OS services, probably in C++ or C.

Re: The State of JavaScript – Survey results

#309

Post by ng12 »

tboyd47 wrote: post #98
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.

Webpack got swept along in the React zeitgeist. Few people who use it really take the time to understand it. It's a pretty slow way to build a project, but that's actually not the main sell. The main sell is in smart asset chunking, and it's pretty darn good at it. That alone earned it a place in my skillset.

Absolutely. Finding out about code splitting was incredible -- I was able to get on-demand loading of resource files working in about ten minutes. One of the most amazing "it just works" experiences I've ever had.

Re: The State of JavaScript – Survey results

#310

Post by SiVal »

foo101 wrote: post #298
Aldo_MX wrote: post #294

Earlier quoted context omitted.

Why shouldn't it? You still need to transpile ES6 to ES5

Thanks for the answer. I was not doubting the survey methodology or results. My question was simply out of curiosity. I would like to request more details on your answer. 1. What kind of ES6 requires transpiling to ES5. I mean, I once tried using Promise and something like Promise.resolve("foo") works just fine. Are there any ES6 constructs that would require transpiling, to work fine on, say, Chrome or Firefox? 2. I…

Here's a little bit for you. Most people prefer the semantics of `let` to `var` for variable declarations in JavaScript. It's how JavaScript should have been designed from the start. It has been officially standard for a year or two and became available in some browsers even earlier.

I want to use `let` (and `const`) for everything and never use `var` again, but I couldn't even do that on my own PRIVATE website (for me alone) until today, because I didn't upgrade my iPhone to iOS 10 until last night, and iOS Safari never supported `let` (or arrow functions or so many other things) before v10 (and Apple won't allow anyone to break their browser monopoly on their platform).

I could just use Android, but I can't switch everyone else to Android, and LOTS of Android and Windows (and even Mac) users are stuck with even older browsers, because they don't know how to (or can't) upgrade.

Are there any ES6 constructs that would require transpiling, to work fine on, say, Chrome or Firefox?

Not on the latest Chrome or Firefox, but that hardly matters in a world where so many people aren't using the latest Chrome or Firefox. The question for a developer is not whether some in their market can run their software but whether some CAN'T.

Is ES6 not completely backward compatible with ES5?

It is (in practice) completely backward compatible, but I suspect you are a little confused about what that means. It doesn't mean "forward compatible". Backward compatible means that a new ES6 browser is still compatible with old ES5 code, which it is. Old ES5 code will keep working. It does NOT mean that my new ES6 code, full of `let` and arrow functions will run in an old ES5-only browser, and there are still plenty of them out there.

As long as you choose to target a market that includes ES5-only browsers (and you may or may not, but if you do), the things that are new in ES6 (Google "what's new in ES6") have to be transpiled to ES5 to run in ES5-only browsers.

Post reply on HN