State of the Art JavaScript in 2016 • Hacker News Board

Re: State of the Art JavaScript in 2016

#121

Post by shados » Sat, Mar 12, 2016, 3:10 AM UTC

clouddrover wrote: post #118

shados wrote: post #111

Earlier quoted context omitted.

We had a discussion about this in my last team. It really comes down to the JS community being divided in 2. You have the first group, of which most of us were part of at least at some point: developing in our language of choice and being "forced" to use JavaScript for some frontend stuff, in the same way we kind of have to use SQL in some form when hitting a database. That group generally wants to touch JS has littl…

> That group generally wants to touch JS has little as possible then forget about it. WebAssembly will be the thing which grants that wish. Once there's a compiler for your language of choice that can compile to WebAssembly the need to use JavaScript will be kept to a minimum.

Bingo. And that, IMO, will be it. The problem right now is that people have no choice. They can use compiled to JavaScript languages, but they're ALL leaky abstractions.

Once people can use the tool they want instead of the tool they have to use, things will be a lot better.

One thing about WebAssembly (and compile to JS languages have had that issue for a long time, and still do to some extent) is the tooling. If the debugger doesn't properly handle breakpoints in the original source (for real. Not the garbage that is sourcemaps that can't even properly map variable names), and if people developing in WebAssembly languages still have to think javascript, then it won't be much better.

Re: State of the Art JavaScript in 2016

#122

Post by shados » Sat, Mar 12, 2016, 3:16 AM UTC

rtsao wrote: post #115

STRML wrote: post #18

This article echoes my experience this year and last, moving from a Backbone app into React + Fluxxor, and eventually into ES6 with Babel + Flow + Webpack. It's a huge pain to configure and understand all this tooling, but man is it nice once it's all working. It definitely gives me hope for the web as an application platform. Re: Flow, it's good but nowhere near as developed as TypeScript, but it's getting better. 0…

CSJS author here, thanks for the plug! I think CSJS fairly unique in comparison to the numerous alternatives in that it: 1) Can be used without any tooling whatsoever. It's just plain JS. 2) Doesn't reinvent the wheel. You can use regular CSS (normal syntax, pseudo classes, media queries) and regular JS (variables, modules) together, allowing you to use the best of both worlds. I loved the ideas behind CSS Modules bu…

What's the story for tooling though? I haven't looked at CSJS much, just the readme, but it seems like the CSS bit essentially is a string, so you don't get the same kind of tooling you can from either CSS files or javascript objects, because it's all strings.

Am I just missing something obvious?

Re: State of the Art JavaScript in 2016

#123

Post by utku_karatas2 » Sat, Mar 12, 2016, 3:55 AM UTC

pkrumins wrote: post #114

Ok, I've had enough. I'm making a prediction that the entire JavaScript ecosystem will collapse. This just doesn't make any sense. None of this is nice. It's all ugly and complicated. There's no beauty to these tools. There are no fundamental tools either. Everything is evolving too quickly. You've a choice of 25 frameworks, libraries, tools that change every day and break between versions. The complexity is growing…

JS scene desperately needs a moratorium on tooling just like Python did on language features 5-6 years ago.

Actually the language also needs a total freeze in features. ES5, ES6, transpilers, this and that and bla bla. I used to love language geekery, not so much after a few years of JS exposure. And now there is WebAssembly which is supposed to be a "game changer". Fuck that. I don't want the game to change anymore, I just wanna play.

Or perhaps, I'm just getting old.

Re: State of the Art JavaScript in 2016

#124

Post by eranation » Sat, Mar 12, 2016, 4:00 AM UTC

> The learning curve is very flat

So if the graph's x axis is time and y axis is the amount of stuff you learn, then a flat learning curve means that you gain very little added knowledge as time goes by. And a steep learning curve means that you learn a lot in a small amount of time.

It always confused me why is it backwards.

Re: State of the Art JavaScript in 2016

#125

Post by ellius » Sat, Mar 12, 2016, 4:07 AM UTC

Can anyone tell me where to start on all of this as a self-taught beginner? I feel like I follow tutorials well and get basic apps up and running via tutorials. I've even built some basic tools in use by a handful of people at my job with Node and Meteor. But the minute I try to dive into React and some of these more professional tools in the ecosystem, I find myself totally lost.

Re: State of the Art JavaScript in 2016

#126

Post by melvinmt » Sat, Mar 12, 2016, 4:15 AM UTC

Is there a boilerplate repo somewhere with all these frameworks and tools combined? Would love to dig more into this but configuring them all together would take me days.

Re: State of the Art JavaScript in 2016

#127

Post by shados » Sat, Mar 12, 2016, 4:17 AM UTC

janfoeh wrote: post #119

shados wrote: post #101

Earlier quoted context omitted.

Most people don't need these things. And more and more companies have devops and infrastructure teams that can deal with that. We're still in a world where every team is a snowflake (the closest things to breaching that was Rails and other server side MVC frameworks similar to it). Once the tech slows down a bit, you'll probably see better solutions. That being said, dealing with legacy code always always suck.

I'd wager a bet that most people using JS today are nowhere close to having devops and infrastructure teams, but are still single people in their bedrooms copying and pasting stuff from Stack Overflow trying to make their online flower shops work. For the life of me I cannot remember who it was, but somebody once essentially said that Javascript had the quality of allowing anybody to bring to life what's in their hea…

The reality is that these tools, eventually, are used by businesses trying to build stuff efficiently.

If we were to have a hackathon, and I could use the stack I have at work (which contains some of these tools, plus our own secret sauce), I'll trash anyone who's using script tags on a page.

Things like webpack, commonjs, npm, etc, are ways to bring that to everyone.

If you're making a little one off or a small project, then anything you're comfortable with will work. Heck, go and use a tool just because you like the logo. It won't make much of a difference.

Re: State of the Art JavaScript in 2016

#128

Post by arxpoetica » Sat, Mar 12, 2016, 4:25 AM UTC

No mention of WebSockets...

Re: State of the Art JavaScript in 2016

#129

Post by qaq » Sat, Mar 12, 2016, 4:49 AM UTC

clouddrover wrote: post #118

shados wrote: post #111

Earlier quoted context omitted.

We had a discussion about this in my last team. It really comes down to the JS community being divided in 2. You have the first group, of which most of us were part of at least at some point: developing in our language of choice and being "forced" to use JavaScript for some frontend stuff, in the same way we kind of have to use SQL in some form when hitting a database. That group generally wants to touch JS has littl…

> That group generally wants to touch JS has little as possible then forget about it. WebAssembly will be the thing which grants that wish. Once there's a compiler for your language of choice that can compile to WebAssembly the need to use JavaScript will be kept to a minimum.

Y but you will have to support JS for 10+ years regardless

Re: State of the Art JavaScript in 2016

#130

Post by georgefrick » Sat, Mar 12, 2016, 4:51 AM UTC

I'm not a fan of these discussions at all. We're all supposed to have been using X framework at X time period. In the enterprise we can't just keep rewriting all the god damn applications.

For us contractors, we have to answer to clients we had 2 years ago about why their app is in Backbone.

I mean, damn; we have to build software here and we aren't all Facebook. You might get warm and fuzzies from constantly starting over and feeling like you've chosen the right framework, but it's immature.

Oh, we got it right this time! React is a paradigm shift! We've quickly forgotten we were saying this with Angular bindings. Oh your model based stuff is crap, this has TWO WAY BINDING, it's a paradigm shift!

Now, I'm using Angular. I could recite the Backbone source code, we had a few small libraries and we built huge apps and they worked (and they were built with Grunt and it worked fine, but hey, move it all to Gulp! now! Paradigm shift!). In this case I was expecting it. I waited six months and Web Pack came along.

We're going to go ahead and build our app in Angular 1.x with TypeScript and Web Pack and test it with Jasmine.

This article is NOT correct. This hasn't been 'decided', there is no clear winner. You can't simply list the features of something as "amazing" and "where it's at". You are arguing finality here and you main data point is "coolness factor". It's not correct, it's not objective, and it isn't high quality, long term; well thought out software development practice.