JavaScript Fatigue
medium.com
JavaScript Fatigue
1–10 of 42 posts
Re: JavaScript Fatigue
#2It's time to stop the madness:
Re: JavaScript Fatigue
#3It's time to stop the madness: http://intercoolerjs.org/
...because the solution to JavaScript fatigue is yet another new JavaScript framework.
Re: JavaScript Fatigue
#4It's time to stop the madness: http://intercoolerjs.org/
Please no. Mixing a markup designed for creating a visual and a scripting language designed to control said visual is painful to maintain and extend. There are too many "gotchas" with the markup structure and CSS itself. Worse yet if something happens with the JavaScript itself and it can't load or loads slowly (because, don't forget, you can make those scripts load asynchronously) what does all that mark-up do? It's going to have a very, very different behavior.
Re: JavaScript Fatigue
#5React has shifted the questions asked by newbies, from which framework to choose, to what tooling to choose to complete the framework. Essentially it's a framework in library disguise.
It's used more as a simplifying term for a family of related technologies, rather than React the library itself.
For experienced coders this doesn't matter too much. More toys to play with. Newbies seem to be having a hard time picking up all those buzz-word ridden notions of the available tooling.
Not everyone can have a deep computer programming background, so they have to be confused and then get it wrong, in order to learn.
It's not React's fault, it can't solve everything. It is what it is, the problem is irrational people, trying to make a front-end messiah out of it.
Re: JavaScript Fatigue
#6>Application developers should not have to become experts in the underpinnings of the library just to use it.
I understand that that is the final goal. But as we introduce new technologies it takes a time and more powerful machines until they can be simplified.
There is a lot of people asking for easy ways to build systems for millions or billions of users. We will get there but we are still not there. It is amazing that it is already so much simpler and cheap than 10 years ago.
If a product with similar features is easier to use makes sense to choose it. But demand simple solutions to complex problems looks like out of place.
Re: JavaScript Fatigue
#7I 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 work on harder and more complex projects. Sometimes I worry I'm toeing the line at becoming the "old kook who hates new frameworks" but I like things to be explicit and simple; for example if I can write a plain script to handle my build process without integrating grunt or gulp I'm certainly going to do that.
> Leverage folder & file-naming conventions for automatically discovering application-specific routes, actions, tests, and more.
Not a fan of this. This is implicit behavior which is almost never intuitive until you're experienced in the tooling that has it. I'd much rather be a tiny bit explicit where there is a list somewhere and I edit that list with patterns or explicit file names. There is no reason there should be "discovery" of such things at _development time_.
Re: JavaScript Fatigue
#8I 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…
Similar to this note: I've done my fair share of using dependency injection frameworks in the Java backend world (e.g. Spring), just to develop a healthy dislike for every DI out there. The magic is nice and good, until it becomes a burden, and a constant question of where certain objects are coming from. It was a pain to see the same design pattern to emerge in the (compiled-to-)JS world, with all of the same problems and complexities.
I wonder if any _good_ pattern had similar lifecycle, winning the minds and then spreading to different domains.
To be fair: I do think DI has value, but I started to prefer explicit over implicit, and most DI stuff is focusing on implicit and magic.
Re: JavaScript Fatigue
#9I 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:
Re: JavaScript Fatigue
#10I 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…
Similar to this note: I've done my fair share of using dependency injection frameworks in the Java backend world (e.g. Spring), just to develop a healthy dislike for every DI out there. The magic is nice and good, until it becomes a burden, and a constant question of where certain objects are coming from. It was a pain to see the same design pattern to emerge in the (compiled-to-)JS world, with all of the same proble…
have you tried dagger 2 ?
I think it makes a good job at dispelling the magic as much as possible.