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

181–190 of 306 posts

Re: State of the Art JavaScript in 2016

#181

Post by mbrock »

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…

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

Um. That applies to all software... but not especially to React and Redux. Or what are you comparing with?

Is there anything in particular you dislike about React, or Redux, or Babel?

I don't think this ecosystem is going to "collapse" at all. Something else will come along, as always. Until then, it's a fine set of tools.

You don't need to feel despair about choosing tools.

Spending weeks to learn an ecosystem of dynamic web programming... yeah, what's wrong with that? How quickly would you prefer to learn?

I learned to use React in a couple of days, for what it's worth. It's remarkably straightforward and the API surface area is small.

Redux is such a simple idea that I accidentally invented nearly the same thing before I even knew about Flux: put your app's state in a global immutable object, then use values to represent actions that transform the state. It's not ugly or complicated.

You don't need to be tricked by peer pressure either. You can be as conservative and cautious as you wish.

Why all this... whining?

Re: State of the Art JavaScript in 2016

#182

Post by Joeri »

hughes wrote: post #70
alextgordon wrote: post #60

> Unless you’re working on a legacy application or have 3rd party libraries that depend on it, there’s no reason to include it. That means you need to replace $.ajax. > I like to keep it simple and just use fetch. It’s promise based, it’s built in Firefox and Chrome, and it Just Works (tm). For other browsers, you’ll need to include a polyfill. I laughed. Is this satire? There's no reason to have X, therefore you nee…

Have you ever started a js app thinking you don't need jQuery? It usually goes great until you need to make a request. One look at `XMLHttpRequest` and suddenly including a 92kb (unminified) library starts to sound appealing. I'd happily include a 9kb (unminified) polyfill and work off the assumption that I can remove it a few years down the road.

Odds are a single retina icon in your app is larger than jquery. Worrying about javascript code size is like worrying about the drag of a car bumper sticker.

Re: State of the Art JavaScript in 2016

#183

Post by girvo »

utku_karatas2 wrote: post #123
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 don't understand this argument at all. You don't have to be on the bleeding edge. In fact I recommend against it for nearly all cases. If you want to write standard ES5, and skip all this stuff, you can! There is no one holding a gun to your head telling you to keep up "or else".

I pick and choose the tools I need. Some are new, some are old. This goes for any language I use, too, not just JavaScript.

Re: State of the Art JavaScript in 2016

#184

Post by anantzoid »

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…

> You've a choice of 25 frameworks, libraries, tools that change every day and break between versions.

And this is what the author has said too, and then presented a list of tools for different purposes to one doesn't fall into analysis-paralysis.

Since past few months, JS community and settling down and tools are getting stable and long lasting. Surely, new ones are being developed everyday, but a standard is being set with React-Redux-Webpack family.

Maybe a new generation of JS tools will come up when Web Assembly becomes mainstream, but until then, I think React is here to stay.

Re: State of the Art JavaScript in 2016

#185

Post by sklivvz1971 »

Every post that lists a set of tools is eventually going to be completely wrong.

1) This is the author's favorite setup in 2016. With all due respect, what is the lasting value of this information?

2) There is no "best" architecture. It depends on what problem one is solving. The author does not specify that, making their conclusions likely completely wrong in most cases. Yet, the language they use is in absolute terms.

3) 99% of JavaScript simply enhances static HTML pages. Yes, even in 2016. You probably don't even need jQuery, although it's likely to be available already.

4) It curiously evangelizes the "latest and greatest" frameworks, thus incurring in novelty bias -- new frameworks have less apparent problems because many side effects become apparent years later, once the codebase is mature.

Re: State of the Art JavaScript in 2016

#186

Post by andybak »

f1hybrid wrote: post #158
natrius wrote: post #113

Earlier quoted context omitted.

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.

I come to HN regularly for advise. Should I be taking yours? I'm a web dev by proffession. React is a paradigm shift? Kind of like the paradigm shift 20 years ago where we said "separate your markup from your style, you'll be better off, promise"? Using css felt right, right from the start. I should really learn React? Mixing js and html in a react flavor does not give the the same sense of being on the right track.

> separate your markup from your style, you'll be better off, promise

I think the benefits of this were undeniable but not quite for the reasons everyone thought. At that point html was such a mess that imposing ANY structure on it would have been an improvement. CSS saved us from nested image-table-slicing hell.

Separating markup from style is one way to structure a complex document but it's not the only way. However it's better than 'no way'. But don't cargo-cult it.

Re: State of the Art JavaScript in 2016

#187

Post by pedrokost »

Mc_Big_G wrote: post #59

Ember barely gets mentioned and includes each "piece of modern web applications" OUT OF THE BOX with a great support community. I love not making all of those decisions and doing all the integration BS work. Ember feels like the worst kept secret.

Fully agree. Recently, I have discovered a new reason to use Ember. I have an Ember app I built, but only have a few hours a month to maintain it. Using the Ember stack makes it trivial for me to quickly (and almost painlessly) upgrade as needed, and focus the little time I have on building features. Reading this article made me cringe at the thought of using the proposed stack for this app, having to follow the development of each of these components separately, and fixing the glue between them when things go sour.

Ember gives me confidence, that I can keep maintaining the app with very low effort, especially now, that the Ember community is releasing a LTS version.

Re: State of the Art JavaScript in 2016

#188

Post by JDDunn9 »

spriggan3 wrote: post #162
JDDunn9 wrote: post #139

Earlier quoted context omitted.

Absolutely. React creates a dependency at the worst possible place, the view/component level. That's the one part of your code that should be the most re-useable. How many times do we have to re-write the same image galleries? The only clear winner can be vanilla JS web components, especially custom elements. A temporary polyfill is fine, but we need to say no to the extra dependencies like React and Polymer that tra…

> The only clear winner can be vanilla JS web component It cannot work since some browsers have different support for different features. You think people stopped using Android 2.x or old iphones ? So you end up with polyfills and since polyfills become dependencies you end with abstractions akin to frameworks, even worse since you now need to maintain your own mess. Javascript isn't scoped in an HTML page, that's it…

The custom element polyfill is 2KB gzipped. All browsers are on board with supporting it. No, polyfills are not akin to frameworks, and yes, I am building a large SPA using just custom elements (no framework) and it's amazing.

Re: State of the Art JavaScript in 2016

#189

Post by JDDunn9 »

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.

I am currently building a large SPA in pure javascript (custom elements mostly) and it's wonderful. It's great to work with real components instead of React's hacked kinda-sorta-components.

Re: State of the Art JavaScript in 2016

#190

Post by Sacho »

f1hybrid wrote: post #158
natrius wrote: post #113

Earlier quoted context omitted.

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.

I come to HN regularly for advise. Should I be taking yours? I'm a web dev by proffession. React is a paradigm shift? Kind of like the paradigm shift 20 years ago where we said "separate your markup from your style, you'll be better off, promise"? Using css felt right, right from the start. I should really learn React? Mixing js and html in a react flavor does not give the the same sense of being on the right track.

> Mixing js and html in a react flavor does not give the the same sense of being on the right track.

But you're not mixing js and html. JSX is not html, it's a DSL to express a tree-like structure. In that sense, it's like mixing js and...dom creation logic.

The reasons I'm aware of to avoid mixing html and js fall into roughly two categories - separation of concerns(don't mix business rules, state management, control flow etc with presentation) and concerns of encoding(building strings of html makes for poor development, debugging, brittle code, and so on).

Since React is just a view layer, it does not impose an entangling of concerns. You can do everything within React components, or separate things on your own or via some other framework.

Meanwhile, the gains from manipulating a DOM or a Virtual DOM are immediately obvious. Even the most popular libraries like jQuery advocate using a more structured approach than simply concatenating strings(e.g. jQuery's whole DOM creation and manipulation lib - although it does make tradeoffs and still allows plenty of html through). The (Virtual) DOM tree naturally allows for composition, compared to the complexities of composing strings of html together.

The paradigm shift from React isn't so much React itself, but the ecosystem it (subtly, or not so subtly) pushes alongside with it. Immutable state and pure rendering functions force you to think through the states and edge cases of your application that would otherwise remain as subtle bugs. Components with a clean life cycle(as opposed to angular 1 directives) allow for easy composition. The virtual dom allows you to divorce your framework from html and the browser, and transplant it to other devices.

By the way, the separation of markup and style was a fight for a semantic web. Web apps, which are React's primary use-case, generally sidestep that concern. The theoretical benefits of separating markup and style are still the same today, but the expectations placed on a web site have increased tremendously, and you must juggle those benefits with others.

Post reply on HN