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

311–320 of 357 posts

Re: The State of JavaScript – Survey results

#311

Post by vcarl »

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…

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

Odd, I have the opposite impression. I view a lot of web developers as the self taught, figured it out for themself kind of folk. I see React as a counterpoint, pulling in ideas from more academic or enterprise-y parts of the field (functional programming, significant tooling, emphasis on correctness).

Re: The State of JavaScript – Survey results

#313

Post by inimino »

at-fates-hands wrote: post #142
inputcoffee wrote: post #44

I appreciate that for the next year when there is a framework war I will have a link to shut it down. Typically a newbie will ask about which framework they should learn. There will be a bunch of "it depends" and "try them out" responses, and then someone will take pity and pick a clear direction based on their experience. Well and good. But this way the newbie can learn from the actual experience of lots of other pe…

>> Typically a newbie will ask about which framework they should learn.. Honestly the easiest way to learn this is to contact your local recruiters and ask them to send you some openings for FED positions. In nearly every one, you will see which JS framework is the main one they use. In my recent experiences (the last two or three years) most corporate environments are using AngularJS, while the smaller startups are…

Seeing what developers prefer and recommend is a better way to get in front of the trends than looking at what codebases companies are (stuck) maintaining.

Unfortunately the JavaScript ecosystem is frothy enough that a lot of junior developers are inevitably going to waste time learning technologies that will be considered obsolete by the time they have mastered them.

Seeing what people are hiring for is of course a useful signal too but it's easy to become a COBOL programmer if that's the only thing you look at.

Re: The State of JavaScript – Survey results

#314

Post by inimino »

at-fates-hands wrote: post #142
inputcoffee wrote: post #44

I appreciate that for the next year when there is a framework war I will have a link to shut it down. Typically a newbie will ask about which framework they should learn. There will be a bunch of "it depends" and "try them out" responses, and then someone will take pity and pick a clear direction based on their experience. Well and good. But this way the newbie can learn from the actual experience of lots of other pe…

>> Typically a newbie will ask about which framework they should learn.. Honestly the easiest way to learn this is to contact your local recruiters and ask them to send you some openings for FED positions. In nearly every one, you will see which JS framework is the main one they use. In my recent experiences (the last two or three years) most corporate environments are using AngularJS, while the smaller startups are…

> there's apps and sites out there which still need supporting.

When a technology is less popular than it used to be, there's also a glut of experienced talent in that technology. That's why trends matter more than just a point snapshot in choosing what to learn, if you're looking at employability.

Re: The State of JavaScript – Survey results

#315

Post by DonHopkins »

anewhnaccount wrote: post #267
kuon wrote: post #129

Earlier quoted context omitted.

I second that. My experience shows it is a state machine, but I have not see any formal study of it.

Well everything that happens in a real computer is an FSM. There's a finite amount of memory and therefore a finite number of states.

That's playing fast and loose with the literal every-day definition of the words "finite", "state" and "machine".

There is actually something in computer science with a precise mathematical definition called a "finite state machine," [1] that is not simply any machine that has a finite number of states.

When you use that term, you're not just talking about what it can do, but also what it can't do, because "finite state machine" implies that it's just a finite state machine, not a pushdown automata, and not a Turing machine.

With a Turing machine, you can implement a finite state machine or a pushdown automata, but Turing machines and pushdown automata are more than just finite state machines.

That said, user interfaces typically use lots of finite state machines at different levels (hierarchical, and unrelated), but they also require more powerful machines like pushdown automata and Turing machines (for validating email addresses, for examples).

If all you had to program user interfaces were finite state machines, but no Turing machines, you would be a very frustrated programmer, and your users would be unhappy to have such a brittle inflexible user interface.

[1] https://en.wikipedia.org/wiki/Finite-state_machine

Re: The State of JavaScript – Survey results

#316

Post by inimino »

ufmace wrote: post #176

Nice article. I started a new hobby Rails project a couple of months ago and was a little surprised to see that even Rails 5 still defaults to Coffeescript. Googled around a bit and decided to drop it, as it seems to be more or less abandoned these days, which this survey seems to confirm. I wonder if/when Rails will switch to ES6 or something?

CoffeeScript was designed by and for Rubyists, so it makes sense that they'd be the last to drop it.

Re: The State of JavaScript – Survey results

#317

Post by DonHopkins »

rifung wrote: post #154
arxpoetica wrote: post #112

Earlier quoted context omitted.

I'm really interested in what you're saying about UIs as state machines. Do you have any articles/references to back this up? Genuine curiousity here.

The person you're replying to didn't specify whether UIs are represented as state machines which are finite or infinite, but I'll assume finite since infinite automata are more powerful than Turing machines so they presumably can represent something which is made by a computer. UIs in general can not be represented by finite state machines. An example is a page with a button which when pressed adds something to the p…

I'm not sure an "infinite state machine" [1] is actually a "thing" the same way a "finite state machine" [2] is a precisely defined mathematical concept in Automata Theory [3]: one level of the classes of automata more powerful than combinational logic and less powerful than pushdown automata and Turing machines.

In my mind, there is no question that finite state machines alone are not powerful enough to define practical real world user interfaces, which require the power of a Turing machine. The fact that most user interfaces incorporate many finite state machines at different levels doesn't mean that finite state machines alone are sufficient.

That's why we program browsers with JavaScript, not FSMML or FSMON.

[1] http://c2.com/cgi/wiki?InfiniteStateMachine

[2] https://en.wikipedia.org/wiki/Finite-state_machine

[3] https://en.wikipedia.org/wiki/Automata_theory

Re: The State of JavaScript – Survey results

#318

Post by DonHopkins »

saosebastiao wrote: post #301
rifung wrote: post #297

Earlier quoted context omitted.

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.

Read any real-world user interface specification like Apple's classic Macintosh Human Interface Guidelines [1]. It specifies all kinds of complex behaviors, like how pull-down submenus don't pop up immediately as you move the cursor over them, and how dragging and dropping text handles the white space at the beginning and end of the selection, or how adjusting the end of the selection in mixed right-to-left and left-to-right text works, which is much too complex and nuanced and ad-hoc hacky to describe with finite state machines, and require a Turing complete machine to implement.

Even if it were technically possible to restrict yourself to a FSM, you would end up going insane and producing exponentially explosive unmaintainable finite state spaghetti machines.

There's a huge uncanny gap between what you can elegantly describe with a clean mathematical abstraction like finite state machines, and what real human beings expect and perceive to be easy to use in a real world user interface.

The polish of a good user interface is the result of millions of tiny little scratches, and in practice that requires the power and flexibility of a Turing machine (and not one stuck in the Turing tarpit like Brainfuck) to make all of those tiny little scratches and cover all the edge cases and special circumstances, because finite state machines are just too clumsy and not powerful enough to conveniently cover that much ad-hoc messy fractal detail.

[1] http://interface.free.fr/Archives/Apple_HIGuidelines.pdf

Re: The State of JavaScript – Survey results

#319

Post by inimino »

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…

The Web has been a very popular development platform for a long time, but that time has been characterized by intense competition between browsers. It's a bit different from most platforms which are clearly dominated and guided by a single player.

So it's a bit more of a "wild west" and it does represent wasted productivity if you look at it that way. You can also see it in a more positive light as a tradition of taking ownership of the tooling and continuously improving it. Because there's no central authority setting a course for the future, progress is through competition among solutions developed by the community.

Re: The State of JavaScript – Survey results

#320

Post by civilian »

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 just started an internal IT tool ...

I think a lot of your ease of use comes from it being an internal IT tool. It's allowed to be clunky, you probably don't have many eyes from marketing/design/product on it-- and if they have seen it, they don't care too much.

Design & product want to be able to do some crazy stuff sometimes. And they're justified in that wish, our frameworks should work with anything that is possible in a browser. Your protests of: "oh well, that's not exactly how the Ember/Rails framework works.." will be met by glazed-over eyes. I really just agree with `erikpukinskis` here, but I think it's an important note that I think you'd have a really bad time if this app was consumer/client-facing.

Post reply on HN