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

JavaScript Fatigue

medium.com

Post reply on HN
Print view View original

21–30 of 42 posts

Re: JavaScript Fatigue

#21

Post by e12e »

BinaryIdiot wrote: post #7

I certainly can appreciate most of this post. I've used so many different frontend (angular, polymer, ExtJS) and backend (express, hapi, restify) frameworks and the various common building tools (grunt, gulp) that it's almost impossible to become great at all of them and for a new comer who maybe only used one or two of those frameworks it can be painful getting started. I've started using less and less frameworks as…

I still refer back to this excellent post from 2014:

http://blog.keithcirkel.co.uk/how-to-use-npm-as-a-build-tool...

And the still active, linked, github repo:

https://github.com/keithamus/npm-scripts-example

For playing with js/css(processors)/webpack things. I never quite understood the facination in the js community with build tools that don't quite replace npm. It just seems like an unwelcome source of extra clocs in the toolchain.

I was also somewhat pleasantly surprised at the simplicity of the setup for the angular2 (beta) tutorial[a] -- even if it manages to pull down a 100mb of dev dependencies (dist dependencies are much more sane). And even if the particular tutorial stops (or did a few weeks ago) before it actually shows how to interact with any kind of external storage/db/api...

[a] https://angular.io/docs/ts/latest/quickstart.html

[ed: actually meant quickstart+:

https://angular.io/docs/ts/latest/tutorial/ ]

Re: JavaScript Fatigue

#22

Post by k__ »

jondubois wrote: post #15

I have used many frontend frameworks (Backbone, Knockout, Angular, CanJS, React, Polymer). I find React to be overly complex/bloated. It sucks you into a whole new universe which probably shouldn't exist in the first place. At first, you think that React will take the complexity out of building apps. Soon enough you realize that React on its own isn't enough; you have to follow particular programming patterns like Fl…

Well, I think in comparison to Polymer, Angular and Ember it has a really tiny API and easy to grasp concepts. Yes Polymer uses components too, but I found it a bit clunky in the past (used it ~2 years ago).

But yes, stuff like Flux isn't really easy. I use Redux and it took me much more time to grasp than Ember-Data or something.

Re: JavaScript Fatigue

#23

Post by andrewingram »

I think the last few years, 2015 in particular, have been about finding the right patterns to enable development of robust and performant JavaScript apps. It's feeling more and more like most of the gaps have been filled in, with just a few things remaining.

Remember, before frameworks like Django and Rails came along, state-of-the-art backend web development was pretty horrendous. We're still in the wild west stage for front-end, which is arguably a much more hostile development environment. It doesn't really matter if your backend toolkit is 100mb, on the front-end it absolutely does. The backend doesn't also have to deal with new browser releases having bugs that spontaneously break your website.

But I think we're honing in on the right patterns, it's felt to me that whilst there's been a lot of churn in which individual libraries we should be using, there's increasing stability in the approach they take. I'm hoping that in a little more time, the Django's and Rails' of the front-end will start to appear.

Re: JavaScript Fatigue

#24

Post by jbverschoor »

Fully agree.. Javascript "stacks" are just that. Stacks of unrelated libraries which have to be stitched together using competing tools that do the same and cannot describe their own USP.

Re: JavaScript Fatigue

#25

Post by cozuya »

jondubois wrote: post #20
raquo wrote: post #19

I don't get the point of this article. It posits the usage of small independent tools as a problem, and then provides solutions to the problem that are not much more than prepackaged combinations of these tools and therefore were made possible entirely by these tools being small and independent. But these tools are apparently also bad because you need to think to use them, and write config files to tell them what you…

The article makes perfect sense; React is bloated - It has too much tooling, too much complexity, too many ways to do anything and no single way to do it all! In other words, conceptionally, it's about as simple as that tangled mess of jQuery logic you wrote 10 years ago. React without JSX is just horrible. I don't know why they even bother mentioning this approach in the beginner tutorials - The code would be comple…

While I agree React without JSX is terrible and React with JSX isn't too great anyways ("className" vs "class"? "defaultChecked" vs "checked"? everything has to be wrapped in a parent or it errors??) it really doesn't feel bloated to me. I do almost everything inside of class method functions I define or inside of the render itself - if you're heavily leaning on stuff like shouldComponentUpdate that really feels like an antipattern regardless.

Re: JavaScript Fatigue

#26

Post by cam- »

s_kilk wrote: post #16
CloudYeller wrote: post #11

It's scary that if you don't jump on some kind of framework bandwagon, you'll be half as productive as framework devotees within 4-5 years. When I joined my current team in 2015, they were still using Python Paste and jQuery for everything, while I was well-versed in Angular + a modern Python server framework. Armed with my modern libraries, I could do more in 1 day than an average teammate could in a week. In other…

> What will happen when an average framework's half life is 1 year? Or 6 months? I think that's the point where everyone will just give up on frothy frameworks and the pendulum will swing back toward more stable and well-worn libraries. I mean, we're already having that discussion right now, so I don't think it'll even get that bad.

Java went through this in the late 1990s and early aughts. Now everyone pretty much uses Spring.

Re: JavaScript Fatigue

#27

Post by luiscarli »

I see the multiplicity of tools and libraries as a result to the fact that we have not yet arrived at a good stable solution for the unique problems that interactive front-end applications have today.

If we had good and stable solutions, new libraries and tools would have a very difficult time to get traction, just for the sake of being new and doing things different.

The javascript stack today is a reflection of the complexity of the problems it needs to deal with.

We can still use jquery and write code directly on script tags of html page, zero tooling problem and complication. Most front-end developers don't do that anymore because it does not solve the problems for developing complex web applications.

A clear winner may one day arise and dominate and simplify the stack, but it's also a possibility that the complexity and multiplicity of the problems the front-end deals with don't sustain one clear winner.

Re: JavaScript Fatigue

#28

Post by sotojuan »

Egregore wrote: post #9

I think Meteor might be the solution to some of these problems: it's easy to set up, you can start working in few minutes. Also it's very easy to work with React from Meteor: https://www.meteor.com/tutorials/react/creating-an-app

Another solution is ember-cli[1]

[1] https://guides.emberjs.com/v2.2.0/getting-started/ember-cli/

Re: JavaScript Fatigue

#29

Post by bttf »

This article is actually highlighting (indirectly) the strengths of Ember.js and its ecosystem. As an Ember dev this article made me appreciate the way the development of ember tooling and the library itself are both intertwined, and that best practices are constantly being implemented into the tools used across all developers, core maintainers and simple users alike.

Re: JavaScript Fatigue

#30

Post by onewaystreet »

jondubois wrote: post #15

I have used many frontend frameworks (Backbone, Knockout, Angular, CanJS, React, Polymer). I find React to be overly complex/bloated. It sucks you into a whole new universe which probably shouldn't exist in the first place. At first, you think that React will take the complexity out of building apps. Soon enough you realize that React on its own isn't enough; you have to follow particular programming patterns like Fl…

You can do everything you do here in Polymer in React. The complexity of React comes from being able to do a lot more. With choice comes complexity.
Post reply on HN