Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

State of the Art JavaScript in 2016

medium.com

Post reply on HN
Print view View original

111–120 of 306 posts

Re: State of the Art JavaScript in 2016

#111

Post by shados »

increment_i wrote: post #107

Whenever these kinds of JS commentaries pop up on HN nowadays, I notice two distinct camps of commenters emerge: Those who are obviously steeped in the JS scene and are delighted to argue the finer, more sophisticated points of it, and those who take their best look, step back, and criticize this convoluted house of cards - and of course proceed to be downvoted into the Stone Age as the latest casualty of HN censorsh…

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 little as possible then forget about it. Ideally making it as close to their language of choice as possible (similar to ORMs for database).

Then there's the other side, people who are running away with it and pushing it as far as possible. That also comes with some problems (JS fatigue, millions of frameworks, etc).

But generally, most comments will fall in one of the 2 categories.

Re: State of the Art JavaScript in 2016

#112

Post by natrius »

bottled_poe wrote: post #94
Lazare wrote: post #15

I agree with 90% of this. React, Redux, ESLint with airbnb config, npm, webpack, lodash, ramda, fetch, css modules...absolutely. I disagree with the breezy assertion that types don't matter, and the offhand dismisal of TypeScript. And saying that "TypeScript tries too hard to make JavaScript like C# or Java" reveals, in my view, a fundamental failure to understand what TypeScript does. I also think the author is a bi…

mocha, ava, expect, chai, painless... honestly what the fuck is this. I'm not a javascript developer - is the ecosystem really so fragmented? What a nightmare.

It's not so bad. You just pick the most popular thing or use the recommendations in articles like this one. The ecosystem is harder to dive into than any other language I've used, but you only dive in fresh the first time (or after you've done something else for two years).

Re: State of the Art JavaScript in 2016

#113

Post by natrius »

finishingmove wrote: post #31
Lazare wrote: post #15

I agree with 90% of this. React, Redux, ESLint with airbnb config, npm, webpack, lodash, ramda, fetch, css modules...absolutely. I disagree with the breezy assertion that types don't matter, and the offhand dismisal of TypeScript. And saying that "TypeScript tries too hard to make JavaScript like C# or Java" reveals, in my view, a fundamental failure to understand what TypeScript does. I also think the author is a bi…

Although the article covers a lot of things and provides some arguments (credit where it's due), the fashion in which the choices are made suffers from a kind of tunnel-vision favoritism. Claims like, "Everyone should use React. Period. Now!" just make me question the merits of its proponents. The JavaScript community is really infamous for this...

React is a paradigm shift in UI development. If you've never tried it or a library inspired by it, that's why you're questioning the proponents. We're trying to spread the gospel that some folks found a better way to do things. Yes, I believe it is a mistake for any UI developer to delay learning React. It's fine to choose other tools later.

Re: State of the Art JavaScript in 2016

#114

Post by pkrumins »

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 and the ecosystem is getting extremely fragmented.

Instead of just writing your application, you're in despair trying to choose the right tools, panicking about not being able to understand them, and then then you spend weeks learning them. You end up writing application that is glitching and you've no idea how to fix it because you depend on a dozen different tools. Worst part is that you don't even need them. You've been tricked by peer pressure into using them.

When you've a complex, fragmented ecosystem, and developers are in stress because they can't understand and learn tools quickly enough, then the only logical conclusion that it will collapse, and only a few technologies will survive that will get mass adoption, and everything else will be forgotten.

Re: State of the Art JavaScript in 2016

#115

Post by rtsao »

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 but wasn't sure about the complexity of re-implementing a new module/variable syntax into CSS. Why not just use what is already provided in JavaScript?

Re: State of the Art JavaScript in 2016

#116

Post by shados »

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…

The ecosystem exploded because of a few core advances (ES6 finally coming out, Babel coming into light, the CommonJS approach to modules, the rebirth of functional programming on the frontend, etc).

This is behind us now. If you sit in forums, chat rooms and other JS centric communities, you'll see that the dialog is pretty different.

It's no longer "Let's build a new tool!" (oh there's some of that, but they rarely hit the spotlight). It's "How do we make this tool work in this edge case we didn't think of".

There's still a framework every other day, but they're usually built on top of the core things now, and no one really pay attention to 99% of them anymore.

If you remember the early days of Java and SOAP with the new SOA framework a day, this is pretty similar. It's settling down.

Re: State of the Art JavaScript in 2016

#117

Post by leeoniya »

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…

Good ideas get standardized.

Ideas from Coffeescript made it into es6, Promises, fetch, etc. Once there are sufficient standards that solve the pain points, the fragmentation will go away. JS is playing catch-up because it was pointless to advance the language when IE didn't even support the existing standards and had 90% market share. Now it has to distill all the good ideas from the past 2 decades and other languages in short order. The chaos is understandable.

Re: State of the Art JavaScript in 2016

#118

Post by clouddrover »

shados wrote: post #111
increment_i wrote: post #107

Whenever these kinds of JS commentaries pop up on HN nowadays, I notice two distinct camps of commenters emerge: Those who are obviously steeped in the JS scene and are delighted to argue the finer, more sophisticated points of it, and those who take their best look, step back, and criticize this convoluted house of cards - and of course proceed to be downvoted into the Stone Age as the latest casualty of HN censorsh…

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.

Re: State of the Art JavaScript in 2016

#119

Post by janfoeh »

shados wrote: post #101
hoodoof wrote: post #34

Earlier quoted context omitted.

I'm trying to program an application, not Webpack. If there are plugins that solve some problems then why aren't they part of the default config of webpack? I'm not programming for the fun of programming build tools, I just want the damn thing to work. Zero interest in working out how to make webpack work. This is the problem with javascript build tools - they think I care enbough to want to work out how to configure…

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 head, no matter their skill and experience level. You could almost mash the keyboard until it worked.

For me, this is a democratizing quality which is fundamental to the spirit of the web, and I would be more than happy to give up generators and class keywords for it.

I've recently spent over six hours trying to build and use a JS library, fighting with package managers, build systems and transpilers, whereas earlier all I would have need to do was download a file and include a tag. We're not moving in the right direction.

Re: State of the Art JavaScript in 2016

#120

Post by jschrf »

terda12 wrote: post #90
Kequc wrote: post #73

A huge amount of this stuff is bloat, to me. It seems like this is a collection of libraries that largely were picked out of the problem that is javascript bloat today. Use typescript and just write it to do whatever you want it to do. You don't need React, or any of this stuff. Chai is good for testing. But as far as deploying a production application, there should be literally no dependencies. You don't need them.…

I disagree. I think React is a no brainer for any SPA. Try doing a full fledged SPA admin panel in pure javascript. It's madness. But with React you can separate everything else into components and it becomes clean and beautiful.

That's just considered good practice. React brings nothing new to separation of concerns. In fact, it works against it.
Post reply on HN