JavaScript Fatigue(medium.com)
medium.com
JavaScript Fatigue
https://medium.com/@ericclemmons/javascript-fatigue-48d4011b6fc4#.m0c2f9fe5
41 comments
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/ ]
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/ ]
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.
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.
have you tried dagger 2 ?
I think it makes a good job at dispelling the magic as much as possible.
>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.
I used to like gulp because it does give you something like that. It lets you write your custom build task with an arbitrary input->output transformation and gulp will just drive it.
That said, it's quite... heavy... for what can be considered to be basically something that takes a list of tasks and their dependencies and runs them in the appropriate order. That's essentially the functionality of async.auto() from caolan/async, so for kicks I made my own build tool that wraps async.auto's functionality into a similar task() function. It's lightweight (only depends on caolan/async) and serves me quite well in the hobby project I use it in.
I used to like gulp because it does give you something like that. It lets you write your custom build task with an arbitrary input->output transformation and gulp will just drive it.
That said, it's quite... heavy... for what can be considered to be basically something that takes a list of tasks and their dependencies and runs them in the appropriate order. That's essentially the functionality of async.auto() from caolan/async, so for kicks I made my own build tool that wraps async.auto's functionality into a similar task() function. It's lightweight (only depends on caolan/async) and serves me quite well in the hobby project I use it in.
Today I started a rebuild of my website as a technical exercise.
1 working day in, and I haven't written a single line of actual html.
Do a search for "require" on npm. There are 90,000 npm packages. There's "require-dir", and "require-directory" then "require-all". Some are shims for require on the frontend, rather than for the backend.
Every other build tool has its own ecosystem of tools that shim around an existing tool. And then webpack's packages notoriously pollute the package global namespace (-loader, and slightly better -webpack-plugin).
Main problem is both the blessing and the curse of Javascript (and slightly mirrors the ongoing popularity of PHP) - there're so many resources available that it's so damn easy to get in. And it's so tempting to build YAJF/J, and even more so nowadays. And as the author mentions - there's very little community curation.
For someone who doesn't sit in the frontend stack everyday, it's quite frankly madness. It's like playing chess with a hydra. The author has problems with the React startup cost - I think it's a problem plaguing the entire js stack.
1 working day in, and I haven't written a single line of actual html.
Do a search for "require" on npm. There are 90,000 npm packages. There's "require-dir", and "require-directory" then "require-all". Some are shims for require on the frontend, rather than for the backend.
Every other build tool has its own ecosystem of tools that shim around an existing tool. And then webpack's packages notoriously pollute the package global namespace (-loader, and slightly better -webpack-plugin).
Main problem is both the blessing and the curse of Javascript (and slightly mirrors the ongoing popularity of PHP) - there're so many resources available that it's so damn easy to get in. And it's so tempting to build YAJF/J, and even more so nowadays. And as the author mentions - there's very little community curation.
For someone who doesn't sit in the frontend stack everyday, it's quite frankly madness. It's like playing chess with a hydra. The author has problems with the React startup cost - I think it's a problem plaguing the entire js stack.
I once tried Yeoman. Angular was the hottest thing ever and I was recommended to use Yeoman to set up a template project. The damn thing downloaded 30000 files into my project. It took a while, but nothing I really noticed until I saw dropbox working for 40 minutes. I just can't take some projects seriously after that.
Anyway, compare your problems and effort to things like this:
Building a tictactoe game in ClojureScript with reagent and figwheel: https://www.youtube.com/watch?v=pIiOgTwjbes
ClojureScript for Skeptics: https://www.youtube.com/watch?v=gsffg5xxFQI
Notice the modularization section that starts around 32m.
Anyway, compare your problems and effort to things like this:
Building a tictactoe game in ClojureScript with reagent and figwheel: https://www.youtube.com/watch?v=pIiOgTwjbes
ClojureScript for Skeptics: https://www.youtube.com/watch?v=gsffg5xxFQI
Notice the modularization section that starts around 32m.
If you're not a front end developer, then why is it a technical exercise to learn all this stuff? Personally, I don't want to learn things that will be obsolete in a few years.
I also rebuilt my website as a technical exercise, but I'm doing it in raw HTML, CSS, and JS. Literally with vim and shell scripts to build it.
I know it can meet the requirements of a personal website, and many other kinds of sites. It probably takes a little longer, but I know it's going to work in 5 years, and I will know how to maintain it.
And I will have more foundational knowledge. Things have changed a lot with HTML and CSS. I learned how to use HTML5 onHashChange. And I did my own "CSS reset" without using any libraries. I wrote my own table sorter with raw DOM manipulation.
I think you need this knowledge to help you use the framework correctly anyway.
I also rebuilt my website as a technical exercise, but I'm doing it in raw HTML, CSS, and JS. Literally with vim and shell scripts to build it.
I know it can meet the requirements of a personal website, and many other kinds of sites. It probably takes a little longer, but I know it's going to work in 5 years, and I will know how to maintain it.
And I will have more foundational knowledge. Things have changed a lot with HTML and CSS. I learned how to use HTML5 onHashChange. And I did my own "CSS reset" without using any libraries. I wrote my own table sorter with raw DOM manipulation.
I think you need this knowledge to help you use the framework correctly anyway.
>>If you're not a front end developer, then why is it a technical exercise to learn all this stuff?
There are many reasons. For one thing, a lot of developers are "full-stack" and don't have the luxury of focusing on just the front-end or the back-end. For another, learning new tools, frameworks and methodologies will make you a better overall developer.
>>Personally, I don't want to learn things that will be obsolete in a few years.
Better not work in web development then. It's probably the fastest moving subfield in software and there's no guarantee that what you're learning today won't be obsolete in a few years. So your best bet is to learn as much as you can, rather than putting all your eggs in one basket that you think will last a long time.
There are many reasons. For one thing, a lot of developers are "full-stack" and don't have the luxury of focusing on just the front-end or the back-end. For another, learning new tools, frameworks and methodologies will make you a better overall developer.
>>Personally, I don't want to learn things that will be obsolete in a few years.
Better not work in web development then. It's probably the fastest moving subfield in software and there's no guarantee that what you're learning today won't be obsolete in a few years. So your best bet is to learn as much as you can, rather than putting all your eggs in one basket that you think will last a long time.
Yeah, professional web dev is not for me, though it seems I'm not the only one lamenting the state of affairs. It seems that it's not just the frameworks that are thrown away in 3 years, but sometimes the products built with them too!
I think learning new "frameworks and methodologies" only makes you a better developer to the degree that they are well thought-out. It seems like a lot of JavaScript stuff is basically still in a state of flux, where people are experimenting and figuring things out.
I spent a lot of time learning Python, C++, C, R, bash, OCaml, and HTML/CSS/JavaScript. All those things have lasting value, and I expect to be using them in 5 years, and probably most of them in 20 years.
I would say jQuery has lasting value, since it has an elegant data-driven / document-driven model. I look a new things to understand if they have lasting value. React does seem principled to me, and I was interested in playing with it, although these threads have what dampened the enthusiasm.
I am using HTML/CSS/JS to display statistics and visualizations, and it works perfectly for that. In any case, I do think there is a problem where a lot of front end devs don't actually understand the abstractions the browser presents. It's basically the same problem as Python or Ruby programmers not understanding what syscalls are and writing horrifically slow code.
I think learning new "frameworks and methodologies" only makes you a better developer to the degree that they are well thought-out. It seems like a lot of JavaScript stuff is basically still in a state of flux, where people are experimenting and figuring things out.
I spent a lot of time learning Python, C++, C, R, bash, OCaml, and HTML/CSS/JavaScript. All those things have lasting value, and I expect to be using them in 5 years, and probably most of them in 20 years.
I would say jQuery has lasting value, since it has an elegant data-driven / document-driven model. I look a new things to understand if they have lasting value. React does seem principled to me, and I was interested in playing with it, although these threads have what dampened the enthusiasm.
I am using HTML/CSS/JS to display statistics and visualizations, and it works perfectly for that. In any case, I do think there is a problem where a lot of front end devs don't actually understand the abstractions the browser presents. It's basically the same problem as Python or Ruby programmers not understanding what syscalls are and writing horrifically slow code.
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 words, my team lost a staggering amount of productivity over the past 2-3 years, just because they were hanging onto old ways that were still legit even in like 2011. And it's obvious that the half-life of frameworks is only decreasing over time.
What will happen when an average framework's half life is 1 year? Or 6 months? Humans aren't built to adapt so much, so quickly. I can gain proficiency with a new library in 3-4 months, but what happens when I get tired of doing that? Will I just fade into the background as some high school kid outproduces me 5:1 simply because he was lucky enough to learn FrameWorkABC a couple months ago while I was busy with a personal issue?
Hopefully by that time, the singularity will be so close at hand that we'll have bigger fish to fry, like basic income, or something.
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 words, my team lost a staggering amount of productivity over the past 2-3 years, just because they were hanging onto old ways that were still legit even in like 2011. And it's obvious that the half-life of frameworks is only decreasing over time.
What will happen when an average framework's half life is 1 year? Or 6 months? Humans aren't built to adapt so much, so quickly. I can gain proficiency with a new library in 3-4 months, but what happens when I get tired of doing that? Will I just fade into the background as some high school kid outproduces me 5:1 simply because he was lucky enough to learn FrameWorkABC a couple months ago while I was busy with a personal issue?
Hopefully by that time, the singularity will be so close at hand that we'll have bigger fish to fry, like basic income, or something.
Honest question: what kinds of things are you doing with React/Angular that you can't do with jQuery? (I'm not a front end developer -- though I do write significant amounts of raw HTML, CSS, and JavaScript).
Is it really higher productivity, or is it just keeping up with the latest fashion?
I feel like the vast majority of websites don't need more than a little JavaScript -- exceptions being Google Maps, Google Docs and spreadsheets, etc.
AirBNB is listed here -- honest question: do they really need a lot of JS? I mean mainly it's showing a lot of pictures and providing good navigation and search. Am I missing something? It's basically like eBay in 2000 except prettier, and that was done without a lot of JS.
https://github.com/facebook/react/wiki/Sites-Using-React
Asana might be a good candidate for a real "app" that needs the complexity.
Why is Wired on there? I think news sites are the worst offenders in terms of using unneeded JavaScript.
Is it really higher productivity, or is it just keeping up with the latest fashion?
I feel like the vast majority of websites don't need more than a little JavaScript -- exceptions being Google Maps, Google Docs and spreadsheets, etc.
AirBNB is listed here -- honest question: do they really need a lot of JS? I mean mainly it's showing a lot of pictures and providing good navigation and search. Am I missing something? It's basically like eBay in 2000 except prettier, and that was done without a lot of JS.
https://github.com/facebook/react/wiki/Sites-Using-React
Asana might be a good candidate for a real "app" that needs the complexity.
Why is Wired on there? I think news sites are the worst offenders in terms of using unneeded JavaScript.
>>Honest question: what kinds of things are you doing with React/Angular that you can't do with jQuery? [...] Is it really higher productivity, or is it just keeping up with the latest fashion?
Answer to the first question: nothing. Everything you develop using React/Angular/etc. can be written using vanilla HTML/CSS/JS.
The difference is that, as your pages become more and more interactive, it becomes harder and harder to deal with the complexity. I recently developed a web form that has a little over 1,000 lines of JQuery. After a while, it became really difficult to keep track of various event handlers, when they would fire and how to make sure they didn't interfere with each other. If I were using a framework like React, it would have been much easier. Here's a diagram that outlines this concept: http://imgur.com/dSQTLDE
>>I feel like the vast majority of websites don't need more than a little JavaScript
Websites don't. Web apps do. The distinction becomes bigger and more important every day.
Answer to the first question: nothing. Everything you develop using React/Angular/etc. can be written using vanilla HTML/CSS/JS.
The difference is that, as your pages become more and more interactive, it becomes harder and harder to deal with the complexity. I recently developed a web form that has a little over 1,000 lines of JQuery. After a while, it became really difficult to keep track of various event handlers, when they would fire and how to make sure they didn't interfere with each other. If I were using a framework like React, it would have been much easier. Here's a diagram that outlines this concept: http://imgur.com/dSQTLDE
>>I feel like the vast majority of websites don't need more than a little JavaScript
Websites don't. Web apps do. The distinction becomes bigger and more important every day.
I just have a hard time understanding where all these web apps are coming from, and what the real requirement is. It seems to me that the ratio of problems that require web apps to web sites is more like 1:1000 than 1:10. In other words, I wonder why it seems everyone is using React or Angular, rather than just a few people.
I mentioned Google maps, docs, and spreadsheets as bona fide apps. They require a completely different approach. They are extraordinarily stateful on the client.
What other sites need that? As mentioned, I don't think AirBNB does. How much state does it need on a page? It's basically like a shopping cart, like eBay. You search for properties, and then you book one. (Maybe it is different for listers, I haven't listed).
I get that you need more advanced stuff like React and Angular to manage a lot of state on the client. jQuery gets messy in that case. But I am wondering why apps all of the sudden need this much state. If you break up your app into different pages, then you don't need so much state on each page. The state is in the URI.
In other words, I see a lot of it as self-inflicted pain... the customer didn't actually want all this stuff. They just want to order a meal online or something. I looked through that whole "Built with React" github page, and I am still trying to understand where the requirements for lots of state are.
I don't buy the motivation of keeping everything on one page to save network latency... if you actually profile a lot of web pages nowadays, the rendering time is greater than network time! I'm seeing full seconds reported by Chrome dev tools just to render!!! It doesn't appear that anyone cares about latency, given how slow most web sites and apps are.
I mentioned Google maps, docs, and spreadsheets as bona fide apps. They require a completely different approach. They are extraordinarily stateful on the client.
What other sites need that? As mentioned, I don't think AirBNB does. How much state does it need on a page? It's basically like a shopping cart, like eBay. You search for properties, and then you book one. (Maybe it is different for listers, I haven't listed).
I get that you need more advanced stuff like React and Angular to manage a lot of state on the client. jQuery gets messy in that case. But I am wondering why apps all of the sudden need this much state. If you break up your app into different pages, then you don't need so much state on each page. The state is in the URI.
In other words, I see a lot of it as self-inflicted pain... the customer didn't actually want all this stuff. They just want to order a meal online or something. I looked through that whole "Built with React" github page, and I am still trying to understand where the requirements for lots of state are.
I don't buy the motivation of keeping everything on one page to save network latency... if you actually profile a lot of web pages nowadays, the rendering time is greater than network time! I'm seeing full seconds reported by Chrome dev tools just to render!!! It doesn't appear that anyone cares about latency, given how slow most web sites and apps are.
It's not about latency, but about overall performance. Rendering on the server is slower than rendering on the client, because the server may have to deal with a thousand requests per minute whereas the client doesn't. So you push the logic to the client and let the browser deal with it until talking to the server is actually necessary (e.g. when the time comes to submit the data). Therefore client-side frameworks become a kind of distributed processing of application logic.
Furthermore, you shouldn't take latency for granted. Many users are on choppy mobile connections. Waiting for the server after every action results in a really bad user experience in those scenarios.
Furthermore, you shouldn't take latency for granted. Many users are on choppy mobile connections. Waiting for the server after every action results in a really bad user experience in those scenarios.
I'm not really buying it... Rendering on the server seems like a solved problem to me. Web apps scale.
Sure, you can save servers by offloading work on the client. But I think your server cost is absolutely dwarfed by developer salaries. I guess it depends on whether you have more front end people or back end people. Good front end people seem to be just as expensive and rare as good backend/C++/Unix/distributed systems people these days.
On mobile, most web apps are a disaster. They are certainly a lot worse than light HTML. Never mind waiting for the server on every action -- try getting the app to load in the first place! The Android and Chrome team have numbers on the astronomical rate of user-aborted or otherwise failed page loads on mobile. On mobile, users see the white screen for 5-10 seconds (probably waiting for your 10-50 round trips for your JS, CSS, heavy image assets, and especially third party JS) and then give up.
Sure, you can save servers by offloading work on the client. But I think your server cost is absolutely dwarfed by developer salaries. I guess it depends on whether you have more front end people or back end people. Good front end people seem to be just as expensive and rare as good backend/C++/Unix/distributed systems people these days.
On mobile, most web apps are a disaster. They are certainly a lot worse than light HTML. Never mind waiting for the server on every action -- try getting the app to load in the first place! The Android and Chrome team have numbers on the astronomical rate of user-aborted or otherwise failed page loads on mobile. On mobile, users see the white screen for 5-10 seconds (probably waiting for your 10-50 round trips for your JS, CSS, heavy image assets, and especially third party JS) and then give up.
You are so right!
I hand tuned web apps (vanilla JS5, no libs/frameworks) and opimized them for mobile, and they are very fast.
But most don't care and use bloated JS libraries/frameworks and the end user has to wait several seconds until the 1MB JS file loads over a cell connection or even crash the mobile browser because the site owner thought it is okay to integrate 30 advertisement and analytics third party JS files.
I hand tuned web apps (vanilla JS5, no libs/frameworks) and opimized them for mobile, and they are very fast.
But most don't care and use bloated JS libraries/frameworks and the end user has to wait several seconds until the 1MB JS file loads over a cell connection or even crash the mobile browser because the site owner thought it is okay to integrate 30 advertisement and analytics third party JS files.
> Here's a diagram that outlines this concept: http://imgur.com/dSQTLDE
Did web devs really need a framework to tell them that the second state of affairs is preferred? I have to assume that the reason React was developed in 2015 and not 2008 is something else.
Did web devs really need a framework to tell them that the second state of affairs is preferred? I have to assume that the reason React was developed in 2015 and not 2008 is something else.
> 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.
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.
I mean, it is still 2015, though, right?
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 Flux or Redux (which adds more constraints/complexity).
Then, with all the complex data rendering happening behind the scenes (diffing), you start to realize that REST is no longer a suitable medium for transferring data over the wire so now you have to use GraphQL/Relay.
Personally, I much prefer the approach which Google has taken with the Polymer 'framework' - You can setup models (WebComponents) to hold simple, atomic values and you can wire them all up on the frontend (no diffing necessary) - You get all the live binding awesomeness without the insane complexity.
For example, with Polymer, you can setup a dynamic collection of item IDs and then use those IDs to load the individual properties of each item - You can hook everything up to update in realtime (both the collection and the bound properties for each item).
The Polymer approach is simple and efficient - Also, once the WebComponents standard has been implemented in all major browsers, you will be able to run that code without any special libraries or frameworks.
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 Flux or Redux (which adds more constraints/complexity).
Then, with all the complex data rendering happening behind the scenes (diffing), you start to realize that REST is no longer a suitable medium for transferring data over the wire so now you have to use GraphQL/Relay.
Personally, I much prefer the approach which Google has taken with the Polymer 'framework' - You can setup models (WebComponents) to hold simple, atomic values and you can wire them all up on the frontend (no diffing necessary) - You get all the live binding awesomeness without the insane complexity.
For example, with Polymer, you can setup a dynamic collection of item IDs and then use those IDs to load the individual properties of each item - You can hook everything up to update in realtime (both the collection and the bound properties for each item).
The Polymer approach is simple and efficient - Also, once the WebComponents standard has been implemented in all major browsers, you will be able to run that code without any special libraries or frameworks.
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.
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.
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.
React 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.
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.
The difference is that with a framework, moving to something different (sometimes even upgrading the framework) for a big project is extremely painful.
With libraries, and pretty your own framework custom build for that project, you can upgrade components one after the other and move without breaking everything.
With libraries, and pretty your own framework custom build for that project, you can upgrade components one after the other and move without breaking everything.
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.
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.
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.
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.
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 want from them.
This doesn't make any sense. The ecosystem is working as it's supposed to be working.
Am I missing something here?
PS: Not sure why you would pick on React for tooling complexity. You can use it with one <script> tag and no JSX, just like angular or jquery or whatnot. If you also want to use ES6, JSX syntax, have your code linted, hot module reloaded, uglified, your sprites auto-generated, and all your assets packaged for efficient distribution that's not react, that's a lot of independent feature requests that require astonishingly minimal boilerplate to get running considering the value you're getting. All of that is completely optional too. If you look at how typical real-world react and angular projects look, they would be very similar in terms of build tools used.
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 want from them.
This doesn't make any sense. The ecosystem is working as it's supposed to be working.
Am I missing something here?
PS: Not sure why you would pick on React for tooling complexity. You can use it with one <script> tag and no JSX, just like angular or jquery or whatnot. If you also want to use ES6, JSX syntax, have your code linted, hot module reloaded, uglified, your sprites auto-generated, and all your assets packaged for efficient distribution that's not react, that's a lot of independent feature requests that require astonishingly minimal boilerplate to get running considering the value you're getting. All of that is completely optional too. If you look at how typical real-world react and angular projects look, they would be very similar in terms of build tools used.
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 completely unreadable.
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 completely unreadable.
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.
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.
Every language / framework has its tooling options but javascript has a lot and no standard/preferred ways. Like with standards, it seems that tooling problems are solved by creating new / more tools.
I have a strong Python background and I'm overwhelmed by the tools available for just building / managing javascript and making it usable. With python (for example) you don't need additional tools for managing/defining/importing modules, building/compressing/minifying code or adding additional language features.
The solution for me was to switch from Angular (where I had to make all choices myself, which I wasn't capable to do) to Ember(-cli) that is making the choices for me. And the lack of such a tight integrated supported set of tools is what is and will keep me from moving to other frameworks in the forseable future.
I have a strong Python background and I'm overwhelmed by the tools available for just building / managing javascript and making it usable. With python (for example) you don't need additional tools for managing/defining/importing modules, building/compressing/minifying code or adding additional language features.
The solution for me was to switch from Angular (where I had to make all choices myself, which I wasn't capable to do) to Ember(-cli) that is making the choices for me. And the lack of such a tight integrated supported set of tools is what is and will keep me from moving to other frameworks in the forseable future.
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
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/
[1] https://guides.emberjs.com/v2.2.0/getting-started/ember-cli/
>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.
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.
As people,tools and runtimes move to ES6 modules things will get better and people will no longer have to use these dreadful frameworks. I for instance try to experiment directly with virtual dom and dom diffing, without using anything else.
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.
It's time to stop the madness:
http://intercoolerjs.org/
http://intercoolerjs.org/
...because the solution to JavaScript fatigue is yet another new JavaScript framework.
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.
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_.