JavaScript Fatigue or My History with Web Development(alexkras.com)
alexkras.com
JavaScript Fatigue or My History with Web Development
https://www.alexkras.com/my-history-with-web-development-or-javascript-fatigue/
162 comments
It's a myth that developers follow trends because they're cool.
The reason one picks up a new JavaScript technology is because it is a better and smarter way of working.
Wave after wave of innovation is bringing better and smarter ways of doing things.
There seems to be some sort of vague idea that JavaScript programmers are following new libraries and frameworks like there is a Solid Gold Hit Parade of JavaScript and they all jump onto the number #1, and next month there is a new #1 so everybody changes to that simply because it is the new #1. That would be stupid.
I use ReactJS because it is a great way to program and gives and application an excellent and functional structure. I use ES2015 and ES7 because they make JavaScript very much more powerful than ES5. If something radically better comes along then damn right I'll switch to it if I can, because "better" means smarter, easier, faster, more powerful - some combination of those to a greater or lesser extent.
The JavaScript community desperately needs a fresh wave of innovation - but this wave must be about simplification - ideally the almost complete removal of all the pain associated with configuration of JavaScript build tools, which right now is excruciatingly and unnecessarily complex and painful - create-react-app has started this process and sets the standard for other tools moving ahead - the right amount of configuration is zero.
It is necessary to use a bunch of painful JavaScript configuration and build tools in order to get your stuff to run. Waves of better, simpler and smarter build tools overrun the previous generation because they have found simpler and easier and more powerful ways to work.
Lets just drop the idea that JavaScript programmers are a bunch of airheads who follow the latest trends whilst they pull on their flared pants and fancy hairstyles.
The reason one picks up a new JavaScript technology is because it is a better and smarter way of working.
Wave after wave of innovation is bringing better and smarter ways of doing things.
There seems to be some sort of vague idea that JavaScript programmers are following new libraries and frameworks like there is a Solid Gold Hit Parade of JavaScript and they all jump onto the number #1, and next month there is a new #1 so everybody changes to that simply because it is the new #1. That would be stupid.
I use ReactJS because it is a great way to program and gives and application an excellent and functional structure. I use ES2015 and ES7 because they make JavaScript very much more powerful than ES5. If something radically better comes along then damn right I'll switch to it if I can, because "better" means smarter, easier, faster, more powerful - some combination of those to a greater or lesser extent.
The JavaScript community desperately needs a fresh wave of innovation - but this wave must be about simplification - ideally the almost complete removal of all the pain associated with configuration of JavaScript build tools, which right now is excruciatingly and unnecessarily complex and painful - create-react-app has started this process and sets the standard for other tools moving ahead - the right amount of configuration is zero.
It is necessary to use a bunch of painful JavaScript configuration and build tools in order to get your stuff to run. Waves of better, simpler and smarter build tools overrun the previous generation because they have found simpler and easier and more powerful ways to work.
Lets just drop the idea that JavaScript programmers are a bunch of airheads who follow the latest trends whilst they pull on their flared pants and fancy hairstyles.
I'm sorry but no, that's not a myth at all, and innovations aren't coming in waves. It's mostly a mistaken perception of the sheer volume of action in the JS sphere, most of which is not innovation at all.
My feeling with the ever growing list of fotm js frameworks that are now firmly dead and buried in the ground is this:
10 ShinyNewJSFramework = 1
20 Use framework
30 Do conference speech about how much better it is than JQuery
40 Hit problem X
50 Find ShinyNewJSFramework is nigh impossible to debug
60 Eventually come to loathe framework because of problem X
70 ShinyNewJSFramework += 1
80 GOTO 20With React, Redux, Babel, Webpack, I would say there are a lot of innovations coming in through there, and the plugin system is being moved from angular, jquery, gulp to these, if you're writing old javascript to target ES5 compliant browsers more power to you, targeting the next version ES6 increased in volume a lot just recently the version is literally called ES2015
The long view of the innovation in React is that it is a tool enabling a change in pattern from "separating concerns of the view layer" to "modular components that get fed data" which is definitely a shift in the way we have previously worked with the frontend and I find very cool. It was also specified in the Web Components spec that is set to become a browser native technology, so React and friends will hopefully be replaced by native components and maybe we can all start focusing our efforts on building standard libraries of re-usable code that will be easily portable, and we can all forget the JS Gold Rush ever happened.
This is honestly the direction I see us going. Angular has also created a component concept nearly identical to React, the only difference is implementation details. It's a natural way to go, because it decreases cognitive load.
I am intrigued and ponder the idea of there being "JS Standard Libs" and wonder which ones will initially get picked for the honor. I don't think it will be React or Angular but definitely "something" like them, even if it is a version of Web Components.
That'll also mark a huge change in performance and download metrics, because if your browser already has your framework built in, your delivered code base is suddenly a fraction of what it was. And then there will be more opportunities there, too - dynamically providing the framework where needed in a separate code split, vs. a browser that does not need it.
We're just at the beginning, really. Browsers stalled for 15 years and have shifted into a period of innovation again.
I am intrigued and ponder the idea of there being "JS Standard Libs" and wonder which ones will initially get picked for the honor. I don't think it will be React or Angular but definitely "something" like them, even if it is a version of Web Components.
That'll also mark a huge change in performance and download metrics, because if your browser already has your framework built in, your delivered code base is suddenly a fraction of what it was. And then there will be more opportunities there, too - dynamically providing the framework where needed in a separate code split, vs. a browser that does not need it.
We're just at the beginning, really. Browsers stalled for 15 years and have shifted into a period of innovation again.
Segmentation fault. Core dumped.
$ ls
brain.coreFor me Vuejs is one example of the "no innovation" part.
My journey has been JQuery -> Angular -> React with background noise of Node.js
I've specifically tried to avoid Choo/Vue/Whatever until there has been real traction in the job market and the community behind that framework. BUT the move from each 'framework' to the next has been a revelation in how to do things better.
I feel comfortable now that React is delivering an ecosystem that is going from strength to strength and has brought a maturity to the front-end javascript ecosystem that was missing. Huge props to the community for that.
I've specifically tried to avoid Choo/Vue/Whatever until there has been real traction in the job market and the community behind that framework. BUT the move from each 'framework' to the next has been a revelation in how to do things better.
I feel comfortable now that React is delivering an ecosystem that is going from strength to strength and has brought a maturity to the front-end javascript ecosystem that was missing. Huge props to the community for that.
Yep definitely, either way React is here to stay and it is in large part not due to Facebook, but to the maturity of the community that has supported it. I'm consistently impressed by their level of professionalism.
I hope that, at least, the new technology is better than the old one. But I have some objections:
- why can't old libraries/frameworks/things evolve, instead of forcing a breaking change? In many other languages evolution seems to preferred to revolution; in JS, evolution seems to be the norm.
- Is that "better and smarter way of working" THAT MUCH BETTER AND SMARTER? When working JS, it seems that a complete overhaul of an application (or of an ecosystem) is required every very few years. Ultimately, software development should lead to business value; does the improvement in generated business value justify the costs associated with such a tech twirl?
- why can't old libraries/frameworks/things evolve, instead of forcing a breaking change? In many other languages evolution seems to preferred to revolution; in JS, evolution seems to be the norm.
- Is that "better and smarter way of working" THAT MUCH BETTER AND SMARTER? When working JS, it seems that a complete overhaul of an application (or of an ecosystem) is required every very few years. Ultimately, software development should lead to business value; does the improvement in generated business value justify the costs associated with such a tech twirl?
>> Is that "better and smarter way of working" THAT MUCH BETTER AND SMARTER?
Absolutely yes. ReactJS is an application architecture that is a complete rethink of how to structure client side applications, and it is an architecture that is being applied outside JS and the browser because it is so much better. The fundamental concept of one way data flow from parent to child through the application requires a start from scratch approach, and would be severely compromised were it to be implemented as an "additional" evolution of some existing application framework such as AngularJS. Yes - that much better and smarter.
ES2015/ES7 are radically better languages that make hugely important changes to JavaScript. Yes - that much better and smarter.
Transpilers make it possible to run ES2015/ES7 even on browsers that support only ES5 - that is amazing - yes - that much better and smarter.
Build tools such as minifiers and packers and uglifiers perform magic to shrink and optimise code for a range of benefits including end users performance - Yes - that much better and smarter than sending a chunk of raw JS to the browser.
In short, yes, JavaScript is experiencing a continuous wave of really major and significant improvements that justify ditching the previous generation entirely.
I will say however that breaking changes give me the shits abut for the most part I am willing to endure them - I simply must assume that the changes are for the better because I don't have time to really understand every single change in every library that goes into my application - no JavaScript developer does - nor indeed does any Python developer try to understand every change to all the Python libs that they use.
Absolutely yes. ReactJS is an application architecture that is a complete rethink of how to structure client side applications, and it is an architecture that is being applied outside JS and the browser because it is so much better. The fundamental concept of one way data flow from parent to child through the application requires a start from scratch approach, and would be severely compromised were it to be implemented as an "additional" evolution of some existing application framework such as AngularJS. Yes - that much better and smarter.
ES2015/ES7 are radically better languages that make hugely important changes to JavaScript. Yes - that much better and smarter.
Transpilers make it possible to run ES2015/ES7 even on browsers that support only ES5 - that is amazing - yes - that much better and smarter.
Build tools such as minifiers and packers and uglifiers perform magic to shrink and optimise code for a range of benefits including end users performance - Yes - that much better and smarter than sending a chunk of raw JS to the browser.
In short, yes, JavaScript is experiencing a continuous wave of really major and significant improvements that justify ditching the previous generation entirely.
I will say however that breaking changes give me the shits abut for the most part I am willing to endure them - I simply must assume that the changes are for the better because I don't have time to really understand every single change in every library that goes into my application - no JavaScript developer does - nor indeed does any Python developer try to understand every change to all the Python libs that they use.
These are good points. In my experience other platforms have the same tooling as JS has been getting over the past few years.
Look at Android for comparison:
- ReactJS: React Native, also any overall architecture like MVVM or MVP.
- ES2015/ES7: JDK 7/8
- Transpilers: Kotlin
- Minifiers/packers: proguard and others
- Gulp and co.: gradle
- Other libraries: android has a number of libraries to handle network requests, image loading, animations etc.
What I'm trying to put across is that JS has transitioned from a language that would show and hide elements of the DOM to a serious language used everywhere.
A good developer takes the time to understand the tooling around their platform and language.
Look at Android for comparison:
- ReactJS: React Native, also any overall architecture like MVVM or MVP.
- ES2015/ES7: JDK 7/8
- Transpilers: Kotlin
- Minifiers/packers: proguard and others
- Gulp and co.: gradle
- Other libraries: android has a number of libraries to handle network requests, image loading, animations etc.
What I'm trying to put across is that JS has transitioned from a language that would show and hide elements of the DOM to a serious language used everywhere.
A good developer takes the time to understand the tooling around their platform and language.
There's a very good point here - JS is being used for way more than just showing and hiding DOM elements anymore. It is becoming a full application language, and to that end requires the features that full application development requires, not just on frontend, but in Node as well.
I have just inherited a project written in 100% ES5 and I had forgotten how obscenely verbose JS <= ES5 really was. Every extra line of code is a liability and will slow down app development. Language features support precision and conciseness and that in turn promotes enterprise-level development. A toy language (old JS) can never support a full in-browser application.
I have just inherited a project written in 100% ES5 and I had forgotten how obscenely verbose JS <= ES5 really was. Every extra line of code is a liability and will slow down app development. Language features support precision and conciseness and that in turn promotes enterprise-level development. A toy language (old JS) can never support a full in-browser application.
If you're willing to use transpilers, why stick to JS at all, when you have a wealth of languages available?
Scala, Purescript, Haskell, Elm, ...
Scala, Purescript, Haskell, Elm, ...
Because JavaScript
1. By far, has the largest ecosystem.
2. If you use a linter, a typechecker (TS or flow), and transpile your code (TS or babel or both), JavaScript is actually a pretty nice language to work in.
Sure it's a chore to set up all the initial tooling, and learn the ins and outs. However, once you're past that, it's usually not worth it to switch.
1. By far, has the largest ecosystem.
2. If you use a linter, a typechecker (TS or flow), and transpile your code (TS or babel or both), JavaScript is actually a pretty nice language to work in.
Sure it's a chore to set up all the initial tooling, and learn the ins and outs. However, once you're past that, it's usually not worth it to switch.
1. The ecosystem is available via bindings too (to most transpiled languages)
2. It's still far from the state of the art in PL design and missing:
* Nice static typing with type inference
* Nice guarantees about null access
* Nice guarantees about interop between client and server
* ...
2. It's still far from the state of the art in PL design and missing:
* Nice static typing with type inference
* Nice guarantees about null access
* Nice guarantees about interop between client and server
* ...
>It's a chore to set up...and learn...
>However, once you're past that, it's usually not worth it to switch.
That is somewhat circular and can be said of virtually anything. That is, for every minute you invest in a tech, the degree to which it is worthwhile to switch to another tech diminishes. I'm speaking primarily about tech like frameworks that is aimed at making us more productive.
The exception might be a truly revolutionary new tech that sharply boosts productivity, but also has a very low learning curve. However, that scenario seems particularly unicorn-ish where JS frameworks are concerned.
>However, once you're past that, it's usually not worth it to switch.
That is somewhat circular and can be said of virtually anything. That is, for every minute you invest in a tech, the degree to which it is worthwhile to switch to another tech diminishes. I'm speaking primarily about tech like frameworks that is aimed at making us more productive.
The exception might be a truly revolutionary new tech that sharply boosts productivity, but also has a very low learning curve. However, that scenario seems particularly unicorn-ish where JS frameworks are concerned.
The closer the transpiled language to JS the lower the impedance mismatch. Whatever language I write in, I may need to dive into debugging it as JS. Whatever language I write in, I likely have to use/adapt JS code samples from libraries and dependencies written in JS. More often than not that's a paper-cut; Haskell often has a huge impedance mismatch from x86 assembly but you can still debug it pretty well and FFI into assembly libraries with varying levels of ease based on library documentation.
But especially when you are working with other developers and a mixture of skill levels, impedance mismatches are useful paper-cuts to try to minimize.
But especially when you are working with other developers and a mixture of skill levels, impedance mismatches are useful paper-cuts to try to minimize.
That argument can be used to justify using assembly because you would sometimes have to drop down to assembly level when debugging native code.
I mentioned that. There are still programmers that do justify using assembly that way, and many historically. There are many programmers that just C/C++ over C#/Java/et al for very similar reasons.
I agree, it's not a strong argument, but it is an applicable argument to the discussion. There are trade-offs in every decision, and this is a consideration in those trade-offs.
I agree, it's not a strong argument, but it is an applicable argument to the discussion. There are trade-offs in every decision, and this is a consideration in those trade-offs.
Well, to be fair, the difference is that with Python (or basically any other langauge) a change in a library may introduce a bug, but you won't have to throw away the library or even substantially change your code, save perhaps for some temporary work-around- and the bug will most probably be fixed eventually.
With javascript, as far as a I can tell, "change in a library" means you do indeed throw out the library and adopt a new one, then write your entire code again from scratch and repeat the cycle next year. To me, that sounds like madness and just makes me happy I don't have to deal with all this.
With javascript, as far as a I can tell, "change in a library" means you do indeed throw out the library and adopt a new one, then write your entire code again from scratch and repeat the cycle next year. To me, that sounds like madness and just makes me happy I don't have to deal with all this.
Well the problem lies in exaggerations of not-actually-using-javascript crowd. If the "cycle" would be five years, would it still be that bad? If the previous framework would be of the very first generation of actual workable JS frameworks, and new one brought major improvements, would it still be that bad?
Reality is very different from these discussions.
Reality is very different from these discussions.
Some of that can be compared to trying to find innovative ways to eat the soup with a fork.
That's so true. There was an article on HN recently on how advanced desktop app development tools were many years ago; how quickly you could build a fully functional and quite advanced application. When you have that background, the current state of JS resembles C on DOS in the early nineties. With the exception that there are far, far more complications that could have been be abstracted so that developers can focus on developing the app and not the underlying stack.
Nostalgia is overrated.
You can with a 10 line HTML file and linking a few CDNs make an interactive application that can reach 1 billion people with no install and no buffer overflows. That's magic. The 90s wish they could do that.
You can with a 10 line HTML file and linking a few CDNs make an interactive application that can reach 1 billion people with no install and no buffer overflows. That's magic. The 90s wish they could do that.
It depends what you create. If it's business apps for your customers, they might not care about availability to 1 billion people, but will appreciate several other things (such as rapid modifications) that more often than not are not so trivial to implement in modern web apps.
Could you point us to said article? A few keywords to search, at least. Thanks.
I'm sorry, now when I'm re-reading the said article, it looks like what I meant were some related comments:
https://news.ycombinator.com/item?id=13650730
Several people complain that the voids space after Delphi[1] has never been filled in with something that would come close in the speed and easiness of development of desktop applications.
[1] not that it doesn't exist, but it doesn't count anymore, mostly because of its exorbitant price
I can't find it either, just spent over 30 minutes searching.
Yeah Clearly NODE.JS was not picked because it's cool but because of its single threaded poor performance (talking about the cool years of node.js)
Compared to Python or Ruby, NodeJS has phenomenal performance. The single threaded argument is also flat out wrong, given that you have clustering or web workers to take advantage of every core. It's also completely misleading even within a single core, as non-blocking nature of JS will accomplish on a single core what otherwise behaves as threading would.
the cool years of node are just beginning with AWS Lambda and other cloud services that help node.js scale easier
Wait, maybe I am dumb, but why do you need AWS Lambda to scale Node.js better? You use something like Lambda which is build to handle one request per instance to scale something which is single threaded anyway?
Say I have an endpoint that has to parse a giant JSON object, which can take 100ms to parse... if that locks the thread it can block another request. With lambda I would just make one lambda function for each route and routes won't block each other.
JavaScript is unlike other languages, it take the big 4 (Chrome, Safari, Firefox and IE/Edge) to come to an agreement to get something done.
And standardization takes many years to reach mass adoptions. No language come close to such a mess. Even Python 2 to 3 migration wasn't as complex.
Yet, they move fast, faster than those languages that are controlled by one authority.
Frameworks are important because at the lower level, things are not as simple to get done as those language with only one authority.
They API agreed by the authorities will definitely be thin. So the community step up with frameworks.
And standardization takes many years to reach mass adoptions. No language come close to such a mess. Even Python 2 to 3 migration wasn't as complex.
Yet, they move fast, faster than those languages that are controlled by one authority.
Frameworks are important because at the lower level, things are not as simple to get done as those language with only one authority.
They API agreed by the authorities will definitely be thin. So the community step up with frameworks.
It's not an issue with JavaScript it's that the Dom has always been horrible. It's actually slowly improved but not enough to do without the need for frameworks for complex front end applications.
I think that's the real problem. Most JS frameworks wouldn't be needed if the DOM was designed for what it's used today.
Yes yes yes. Simply creating nested elements and getting references to each of them is such a huge pain, and it's a huge part of why frameworks are needed.
You would think creating, say, a form with a button and a textarea, and getting references to those things would be simple, but it's crazy painful in vanilla JS.
You would think creating, say, a form with a button and a textarea, and getting references to those things would be simple, but it's crazy painful in vanilla JS.
I never understood the craze over React. I tried it, and I didn't like it. It may work for Facebook's use case, but to me it looks like a lot of people are unnecessarily rebuilding their front ends with React just because it's hot.
A lot of our industry hires based on buzzwords. For web developers, it pays to have React experience in their resume. Doesn't matter if the app they built didn't need it at all.
Depends where, though. I'm based in the South, Alabama, and most of the jobs here want C# or Angular (1x... specifically). I rarely, rarely see React mentioned.
Of those who want JavaScript experience, it's usually followed with "Do you have any .NET experience?"
Of those who want JavaScript experience, it's usually followed with "Do you have any .NET experience?"
Yeah same back home in Texas (Houston, not Austin). NYC and SF are different stories :-)
Facebook's use case happens to mirror a great deal of web products currently.
Certainly not in scale.
That's true, but React doesn't directly deal with those problems (and certainly not the parts specific to Facebook).
> To me, it is incredible that the frameworks matter THAT much in the JS world
It's not the JS world, it's the browsers world. I think a better comparison is iOS vs Android vs web development.
It's not the JS world, it's the browsers world. I think a better comparison is iOS vs Android vs web development.
Is webassembly ever going to help in this regard? Seems like it could.
This also has to do with browser compatibility. Vanilla Javascript sucks so hard because it's so difficult to write non-trivial stuff that just works. This is the whole raison d'être for JQuery. This is mainly because the different browsers don't coordinate and there is no official standard. It should have been obvious from the start that this is a recipe for disaster.
That conclusion made me laugh. In the early to mid 90s, I was working on 3D interactive software. The video drivers and chips had advanced so much in one year that all of the lovingly handcrafted assembly I had written over that time was useless. I thought to myself, "what an unstable industry to build a career in". I also made comparisons to accounting, medicine, and law, thinking perhaps I had made a wrong choice.
Turns out that adapting to rapid change is a critical aspect to this career choice. It is also a problem for businesses, which you start to grapple with as you move up the chain of command. The mistake is wistfully hoping that things would slow down enough for you rest on your hard-won knowledge, as in other fields. There is no competitive advantage in aging technology.
Turns out that adapting to rapid change is a critical aspect to this career choice. It is also a problem for businesses, which you start to grapple with as you move up the chain of command. The mistake is wistfully hoping that things would slow down enough for you rest on your hard-won knowledge, as in other fields. There is no competitive advantage in aging technology.
There can be a competitive advantage in aging technology. For instance, suppose you were writing an app that makes heavy use of scientific or ML libraries in python, but your UI is a mainly layout and forms with admin, login, accounts, and so forth. I could easily see huge advantages to keeping it in python, using Django, with a bit of CSS and javascript sparsely applied where needed.
Some of this comes down to personality, too. A lot of people talk about how people were abandoning ruby and rails once it was no longer the "new hotness". Plenty of us (who like rails) came to it somewhat reluctantly, only after the benefits were very clear and the initial chaos had started to subside. We, the reluctant ones, just tend to be a bit quieter about things. I think we're reluctant because we see greater danger and risk in a constantly evolving set of technologies, and we don't like spending a lot of time figuring out how to get a drop down list to populate, not when there's limited time and there's value to be added on the back end.
I've been at this for a while, and I'm getting more and more ok with sticking with an aging technology - even when I know the technology is becoming obsolete. Right now, it's pretty clear to me that web based UIs in the future will be more asynchronous and elaborate, but there will be a lot of false starts and dead ends as we get there. Remember spring mvc, spring di, iBatis, hibernate, tapestry, pico, tiles struts, struts 2...? Yes, the old request-response servlet with jdbc was unlikely to remain a choice for new development, but honestly, I think it might have been a good idea to stick with it for a while and stay out of that mess. Yeah, you'll need to change and adapt, but that doesn't mean you need to jump into the swirling mess.
...unless you do! There are, of course, remarkable opportunities when a new technology hits, and if you wait for it to settle down, you may often find that others have too great a lead. You just really need to figure out if that's you. Because otherwise, you may find that instead of improving the accuracy and speed of some critical calculations your users need to improve their supply chains, you instead spent all your time figuring out how to asynchronously update a drop down list depending on where they clicked on a map. And a round trip to the server and an extra second to load that drop down list might not have been all that big a deal compared to the actual business use of your app.
Some of this comes down to personality, too. A lot of people talk about how people were abandoning ruby and rails once it was no longer the "new hotness". Plenty of us (who like rails) came to it somewhat reluctantly, only after the benefits were very clear and the initial chaos had started to subside. We, the reluctant ones, just tend to be a bit quieter about things. I think we're reluctant because we see greater danger and risk in a constantly evolving set of technologies, and we don't like spending a lot of time figuring out how to get a drop down list to populate, not when there's limited time and there's value to be added on the back end.
I've been at this for a while, and I'm getting more and more ok with sticking with an aging technology - even when I know the technology is becoming obsolete. Right now, it's pretty clear to me that web based UIs in the future will be more asynchronous and elaborate, but there will be a lot of false starts and dead ends as we get there. Remember spring mvc, spring di, iBatis, hibernate, tapestry, pico, tiles struts, struts 2...? Yes, the old request-response servlet with jdbc was unlikely to remain a choice for new development, but honestly, I think it might have been a good idea to stick with it for a while and stay out of that mess. Yeah, you'll need to change and adapt, but that doesn't mean you need to jump into the swirling mess.
...unless you do! There are, of course, remarkable opportunities when a new technology hits, and if you wait for it to settle down, you may often find that others have too great a lead. You just really need to figure out if that's you. Because otherwise, you may find that instead of improving the accuracy and speed of some critical calculations your users need to improve their supply chains, you instead spent all your time figuring out how to asynchronously update a drop down list depending on where they clicked on a map. And a round trip to the server and an extra second to load that drop down list might not have been all that big a deal compared to the actual business use of your app.
> as in other fields
Well maybe it isn't a field after all. Maybe it's "pop culture" like this cranky old guy says https://www.youtube.com/watch?v=FvmTSpJU-Xc.
Well maybe it isn't a field after all. Maybe it's "pop culture" like this cranky old guy says https://www.youtube.com/watch?v=FvmTSpJU-Xc.
[deleted]
It was said million time here. But if you don't like trying new stuff, learn one stack and stick to it. Nobody is forcing you to try new stuff and then talk about js fatigue. Personally I'm exact opposite, I love where js is headed and like all the new stuff and stacks coming. No fatigue at all for me.
> Nobody is forcing you to try new stuff and then talk about js fatigue
This is just not true. I recently had a discussion at work where I was flat out asked "how do you expect to learn new things if you don't try new libraries?". Coming up with a solution yourself (assuming these libraries are even introduced to solve an existing problem, which is sadly not always true) was not seen as an acceptable answer...
The options appear to be assimilate into this culture, or find a new industry to call home. Front-end dev doesn't appear to be for people that care more about a lean, pragmatic stack than a trendy one.
This is just not true. I recently had a discussion at work where I was flat out asked "how do you expect to learn new things if you don't try new libraries?". Coming up with a solution yourself (assuming these libraries are even introduced to solve an existing problem, which is sadly not always true) was not seen as an acceptable answer...
The options appear to be assimilate into this culture, or find a new industry to call home. Front-end dev doesn't appear to be for people that care more about a lean, pragmatic stack than a trendy one.
Your work buddies have it wrong. You don't need to "try" new technology, you simply need to "learn" it. When something new pops up, see what people on HN are praising/hating. Hop on StackOverflow and see what the noobiest questions are for a taste of the installation and compatibility issues. Read some of the questions with multiple replies but no accepted answer to see how toxic or hepful the community around it is. If the new tech has an official forum/chat, hop in there and browse around for a bit. You'll pick up pretty quickly if a new stack, DB, or framework is worth using or not... you don't even need to touch it.
Scientists publish papers so other scientists don't have to run the same experiments over and over. We have HN, SO, and other developer communities for that purpose. Read, learn, watch, wait. "Try" at the point you think it sounds so perfect, you have to try it.
Scientists publish papers so other scientists don't have to run the same experiments over and over. We have HN, SO, and other developer communities for that purpose. Read, learn, watch, wait. "Try" at the point you think it sounds so perfect, you have to try it.
Your comment makes me realise there should be a way to categorize technologies solely based on stackoverflow post metadata analysis (number of questions, number of answers, answer scores repartitions, time between question and answers, etc..)
also average activity on github. Get a feel for how issues and PRs are handled.
Sentiment analysis on issues/PRs would be nice there too.
Sentiment analysis on issues/PRs would be nice there too.
Coming up with your own solution when it isn't informed by other solutions just means you are building another poor alternative.
Frankly these frameworks and libraries are all very similar and they do very similar things. Once you've learned one you can transition to the others quickly (it's the same way with old web frameworks, MVC frameworks are all the same with minor tweaks). They are worth evaluating though because some of them do one thing better than others, might as well borrow it where possible.
I love learning new technology because even if I don't end up using framework x or y, I can pick up the best parts and use it in my own work which becomes simpler and more expressive as a result. I don't want to keep building websites from 2005. There have been some real advances and it's fun touse the best parts.
Frankly these frameworks and libraries are all very similar and they do very similar things. Once you've learned one you can transition to the others quickly (it's the same way with old web frameworks, MVC frameworks are all the same with minor tweaks). They are worth evaluating though because some of them do one thing better than others, might as well borrow it where possible.
I love learning new technology because even if I don't end up using framework x or y, I can pick up the best parts and use it in my own work which becomes simpler and more expressive as a result. I don't want to keep building websites from 2005. There have been some real advances and it's fun touse the best parts.
Yes, you're building a poor alternative. But you learn far more than you ever would just by using the existing libraries, by virtue of learning what not to do.
Using other's tools is trading off knowledge for development time. It's often a good trade to make, but to pretend that learning the API surface of library #34341 is going to improve your skills more is wrong.
Using other's tools is trading off knowledge for development time. It's often a good trade to make, but to pretend that learning the API surface of library #34341 is going to improve your skills more is wrong.
Nobody said learning API surfaces is the right way.
Most of these frameworks offer fairly simple APIs that are frankly pretty trivial to learn --- the key is to learn the application architecture and why it's different than the alternatives.
Anyway, I think we can agree that exposure to other people's thoughts, and also coming up with your own thoughts, is probably the most fruitful way to learn.
Most of these frameworks offer fairly simple APIs that are frankly pretty trivial to learn --- the key is to learn the application architecture and why it's different than the alternatives.
Anyway, I think we can agree that exposure to other people's thoughts, and also coming up with your own thoughts, is probably the most fruitful way to learn.
What you're touching on is a change in dev in general, especially in certain parts of the stack (like much of front-end).
That is, devs have become more assemblers than coders. I think this is due to the explosion in OSS, with all of the libs, frameworks, etc.
On balance, I believe it's made us more productive, but the time spent writing logic has gone down vs. the time spent learning, assembling, integrating, etc. So, devs are expected to keep up on all of the latest tech, tooling, etc.
Of course, the demands of agile development just pours gasoline on it.
That is, devs have become more assemblers than coders. I think this is due to the explosion in OSS, with all of the libs, frameworks, etc.
On balance, I believe it's made us more productive, but the time spent writing logic has gone down vs. the time spent learning, assembling, integrating, etc. So, devs are expected to keep up on all of the latest tech, tooling, etc.
Of course, the demands of agile development just pours gasoline on it.
>It was said million time here. But if you don't like trying new stuff, learn one stack and stick to it. Nobody is forcing you to try new stuff and then talk about js fatigue.
You'd be surprised -- since even single stacks change all the time. Try using React Router and keeping it stable.
Heck, even React changes paradigms (from mixins and factories, to ES6 classes and pure components, to fibers, etc). And from pure React, to coming up with Flux, 4-6 flux alternatives, the Redux dominating, etc.
And let's not get started with things like Angular to Angular 2 et al...
You'd be surprised -- since even single stacks change all the time. Try using React Router and keeping it stable.
Heck, even React changes paradigms (from mixins and factories, to ES6 classes and pure components, to fibers, etc). And from pure React, to coming up with Flux, 4-6 flux alternatives, the Redux dominating, etc.
And let's not get started with things like Angular to Angular 2 et al...
I would not be. React Router 4 is awesome. Wish I had time to write down why. But if you have reason not to upgrade, you can stay on version 3, which is still supported. Same with Angular. Of course there will be examples you're right, but not those two. ;-)
> Nobody is forcing you to try new stuff
Well, except for employers
Well, except for employers
It's usually the developers who push for a switch to the next shiny thing, employers just want a project done in the time and budget.
The flipside is that they hire expensive professionals and then don't trust their judgement - instead forcing them to use inadequate tooling for the problem. Also related to some enterprise companies selling software solutions to management instead of tech people.
[deleted]
Quite often the decision to use new tech is made by CTOs, tech leads and senior devs. The majority of jobs are for plain old "one part of a team" dev roles. If you don't have the experience to jump into a role that commands respect, and the industry is trending towards tools that are overengineered or unsuitable for the problem at hand, then it's perfectly possible to find yourself in a position where you either learn how to do the job poorly or find yourself unemployed.
Unless someone high up has seen a powerpoint with the newest buzzwords and tells the dev department to get on the bandwagon.
Business people are often targets for advertising a technological change. In fact, I think big-contract software firms don't target engineers as priorities for advertising, but rather aim straight for business folks.
If my employer wants to pay me for spending time learning that stuff (and making newbie mistakes in their code), then I guess I can live with that.
If they don't and still expect me to follow whatever their whim of the day is, then I'm glad I'm in an industry where I can safely say I'd need to look for another job then.
If they don't and still expect me to follow whatever their whim of the day is, then I'm glad I'm in an industry where I can safely say I'd need to look for another job then.
Same here. We should remember that JavaScript is a language and React/Angular/Vue are just frameworks/libraries. The latter come and go, the former stays.
Sometimes I just think that for JavaScript developers is simply difficult to choose, so someone created the "JavaScript fatigue". Even Java has a lot of frameworks and libraries to choose from, but I don't see any fatigue there.
Probably we should just be less open to temporary fashions.
> Nobody is forcing you to try new stuff and then talk about js fatigue.
If you read the conclusion, the author is actually very positive about the entire experience.
If you read the conclusion, the author is actually very positive about the entire experience.
“My dear, here we must run as fast as we can, just to stay in place. And if you wish to go anywhere you must run twice as fast as that.” - Lewis Caroll, Alice in Wonderland
Coming up next, WebAssembly for strong obfuscation.
Coming up next, WebAssembly for strong obfuscation.
Proprietary code blobs running in everyone's browsers. God what a recipe for absolute carnage...
Javascript already does that. If you look at any website nowaday you will find minified JS that is impossible to understand.
What's the difference with a binary format at this point ?
It does not change the fact that those blob are executed in a sandboxed environnement with a permission system.
At least WebAssembly is more efficient and will make it finally possible to use staticly typed langage for web developpment.
A minor point: To be fair, minified JS is not exactly a hard barrier. Conventional minification is just removing extraneous whitespace, newlines, comments, etc.. Except for the lost comments (which are definitely a pity if it's well-commented code), it's easily restored with an unminifier.
Is WASM really a proprietary code blob? Or the WebAssemsblers will be proprietary code blobs? Isn't it being done by guys at Mozilla, Google and folks. Or are you confusing Assembly lang that is used with different CPUs and this.
If so try this:
[1] https://auth0.com/blog/7-things-you-should-know-about-web-as...
[2] https://gotechster.com/2017/04/web-assembly/
[1] https://auth0.com/blog/7-things-you-should-know-about-web-as...
[2] https://gotechster.com/2017/04/web-assembly/
We had that before with native plugins and extensions. We can also install random programs on any OS. It's really not a big deal.
The only winning move is not to play.
All this great "progress" and "innovation"...and yet, have you been out there lately? The web? Everything just barely works, and I haven't the slightest illusion that I'm using anything but a patchwork networked application. Most times I'm trying to kill or avoid whatever the hell this page is trying to do and just get my text or content, or submit the stupid form.
I feel like if the front-end dev world is so keen on reinventing itself, it should just go all the way...repackaging HTML/CSS/JS in new and interesting forms and frameworks isn't getting anyone anywhere, IMO. Scorched earth, a new protocol for web applications...don't even call it the web anymore...just put on your CS hats and start over...kill the whole thing with fire.
I feel like if the front-end dev world is so keen on reinventing itself, it should just go all the way...repackaging HTML/CSS/JS in new and interesting forms and frameworks isn't getting anyone anywhere, IMO. Scorched earth, a new protocol for web applications...don't even call it the web anymore...just put on your CS hats and start over...kill the whole thing with fire.
The last part of your comment blames front-end developers for the shortcomings of the web platform. I think many would be interested in a more uniform, stable interface. But they're not the ones with the power to change things on the protocol layer.
I think the problem is more common than people think. It takes lots of bad frameworks to establish a single dominant one. It reminds me of the similar issue PHP landscape was fraught with—lack of a framework/approach with no downside.
Figuring which PHP framework to use was a problem of choosing between dozens of options, each with their own mighty cons. Every time a new framework came, it demonstrated an ability to fix all the known problems but time and again it faltered (Kohana, CakePHP, Yii). In the recent times, Laravel has provenly become a better choice than what was available only a few years back. It has grown a community of a considerable size and it's unlikely it would getting supplanted in future.
I am guessing at some point in the future, the landscape would stabilise and a single approach would become the obvious choice for JS just like Rails is for Ruby.
Figuring which PHP framework to use was a problem of choosing between dozens of options, each with their own mighty cons. Every time a new framework came, it demonstrated an ability to fix all the known problems but time and again it faltered (Kohana, CakePHP, Yii). In the recent times, Laravel has provenly become a better choice than what was available only a few years back. It has grown a community of a considerable size and it's unlikely it would getting supplanted in future.
I am guessing at some point in the future, the landscape would stabilise and a single approach would become the obvious choice for JS just like Rails is for Ruby.
You're right, it is common and it's easy to forget that.
Python in 2007 was Django, web.py, Subway, Turbogears, Pylons, Werkzeug, Zope, and a bunch of tools a lot of people have never heard of competing for space. Who needed all of those frameworks anyway?
It took awhile but slowly what works and what doesn't was figured out and we've got better approaches. Web programming circa 2007 was by its nature simpler and despite that the Python community (which is a blip compared to the JS community today) churned out a lot of stuff.
You can still build websites like it is 1999 but you've got a lot of other options now, too. Use the best parts and dip your toes into that stream of new stuff when you feel like it. Competition and progress beat the hell out of stagnation though.
Python in 2007 was Django, web.py, Subway, Turbogears, Pylons, Werkzeug, Zope, and a bunch of tools a lot of people have never heard of competing for space. Who needed all of those frameworks anyway?
It took awhile but slowly what works and what doesn't was figured out and we've got better approaches. Web programming circa 2007 was by its nature simpler and despite that the Python community (which is a blip compared to the JS community today) churned out a lot of stuff.
You can still build websites like it is 1999 but you've got a lot of other options now, too. Use the best parts and dip your toes into that stream of new stuff when you feel like it. Competition and progress beat the hell out of stagnation though.
I hope that never happens. Why? Frameworks solves a generic problem, but you in your project are solving a specific problem, hence you can never solve your problem better than what the Framework allows you to.
Problem is rather developers don't know how to organize their code without the help of the Framework. If they knew, Frameworks would not be needed, only libraries.
One Framework to rule them all will stifle progress, it locks the community into one size fit all mentality and therefore clouds the minds of the developers to not think about the possibilities outside their worldview.
Laravel will, of course, eventually be replaced, as with all frameworks. Current hype now are "micro" frameworks.
So all that effort put into the Framework will be partially lost due to it is locked to that Framework.
Lessons learned ought to be, write reusable framework independent libraries instead.
Problem is rather developers don't know how to organize their code without the help of the Framework. If they knew, Frameworks would not be needed, only libraries.
One Framework to rule them all will stifle progress, it locks the community into one size fit all mentality and therefore clouds the minds of the developers to not think about the possibilities outside their worldview.
Laravel will, of course, eventually be replaced, as with all frameworks. Current hype now are "micro" frameworks.
So all that effort put into the Framework will be partially lost due to it is locked to that Framework.
Lessons learned ought to be, write reusable framework independent libraries instead.
I fell in love with web development over 15 years ago because it was just a request to the browser and an answer.
I've worked on windows applications and just hated it. All this code handling the state of controls depending on the input/action.
Sometimes I have the feeling I'm doing this stuff on the web again which I haven't for over 10 years and it just feels wrong.
I've worked on windows applications and just hated it. All this code handling the state of controls depending on the input/action.
Sometimes I have the feeling I'm doing this stuff on the web again which I haven't for over 10 years and it just feels wrong.
What's difficult about it?
The underlying model is incredibly simple. You have a visual model/datastore that you manipulate and the UI changes as a result. Interactions with the UI drive events which might call out to a server or do a calculation, which in turn changes the view model/datastore and that changes the UI and so on and so forth...
You probably get that, but I've down programming with wxPython, Qt, etc. I've done Django, Rails, Flask, etc. and frontend frameworks are so much more powerful and easier to use than those old models and getting them up and running takes a few minutes. When I see how much difficulty and how much anxiety this new tech is causing people it makes me wonder if the frameworks are just covering up how easy all this stuff is and how powerful it is.
It's really exciting stuff, it sucks if people are missing that.
The underlying model is incredibly simple. You have a visual model/datastore that you manipulate and the UI changes as a result. Interactions with the UI drive events which might call out to a server or do a calculation, which in turn changes the view model/datastore and that changes the UI and so on and so forth...
You probably get that, but I've down programming with wxPython, Qt, etc. I've done Django, Rails, Flask, etc. and frontend frameworks are so much more powerful and easier to use than those old models and getting them up and running takes a few minutes. When I see how much difficulty and how much anxiety this new tech is causing people it makes me wonder if the frameworks are just covering up how easy all this stuff is and how powerful it is.
It's really exciting stuff, it sucks if people are missing that.
Your comment reminds me "how to draw an owl" joke. Yes model is simple. But the devil is in the details and web has a loooooot of details.
[deleted]
Are you still using Django, Rails, or Flask to provide API end points to your front end? If not, what do you use?
Not a big fan of Ruby or Python as the backend server given the choice, there's just a lot of languages that do it better (Elixir, Clojure, Go for example). Django and Rails have a lot of extra stuff you don't need.
But if you just want to get an api up quickly its really hard to beat Flask or even Bottle (not sexy but very simple) and I've never used it but Sinatra is supposed to be great, too. Microframeworks are great.
But if you just want to get an api up quickly its really hard to beat Flask or even Bottle (not sexy but very simple) and I've never used it but Sinatra is supposed to be great, too. Microframeworks are great.
> Django and Rails have a lot of extra stuff you don't need.
Oh yeah your OS and libc too have them, the computer itself has them. You don't need the things you don't need to not exists in order to make use of what you need.
Oh yeah your OS and libc too have them, the computer itself has them. You don't need the things you don't need to not exists in order to make use of what you need.
JavaScript is a small language because it needs browser support and backwards compatibility. A small language that can't change much over time can't afford to have opinions on how to build dynamic interfaces.
Therefore, all the complexity of building interfaces will be in the libraries and because opinions on such complex issues vary, there are many libraries to do the same thing.
Eventually the interior ones are recognized and culled. They typically are supported for quite some time after becoming uncool, it's just that no one wants to work with lame, obsolete tehnology for good reasons.
The solution I see to this are compile-to-JS languages that make it possible to use a different ecosystem of libraries than te JS one, like Scala.js. However, those tools are also still evolving, so one way or another you're dealing with a lot of library churn in frontend development right now, so learn to pick winners and stick to them until it's as weird to use them as jquery for complex UI was in 2012.
Therefore, all the complexity of building interfaces will be in the libraries and because opinions on such complex issues vary, there are many libraries to do the same thing.
Eventually the interior ones are recognized and culled. They typically are supported for quite some time after becoming uncool, it's just that no one wants to work with lame, obsolete tehnology for good reasons.
The solution I see to this are compile-to-JS languages that make it possible to use a different ecosystem of libraries than te JS one, like Scala.js. However, those tools are also still evolving, so one way or another you're dealing with a lot of library churn in frontend development right now, so learn to pick winners and stick to them until it's as weird to use them as jquery for complex UI was in 2012.
While it's easy to get frustrated especially if you are following each twist and turn that js takes, I think if you step back a little, you can see things are getting better as a whole.
For the longest time, js was just a thing I did on weekend or as part of tertiary projects at work. I first used js as a kid for my geocities page, used jquery and YUI for a work projects starting about eight years ago, experimented with Angular, and most recently embraced React and es6.
Almost two years ago, I quit my job and started building a side project in React and Fluxxor for fun. At this point there were a bunch of Flux implementations and no dominant library had emerged. I got frustrated with the build process and then got distracted with other life experiences.
I returned to javascript less than a year later and was amazed at how much better things got. I could do npm install and npm start and there was a good chance things would actually work. I was doing the same google searches but noticed that the documentation was a lot better. I also had a friend this time around and he steered me toward Redux and es6. Javascript suddenly became an enjoyable language for me enough that I plan to focus on it. This is after more than close to twenty years of fits and starts.
For the longest time, js was just a thing I did on weekend or as part of tertiary projects at work. I first used js as a kid for my geocities page, used jquery and YUI for a work projects starting about eight years ago, experimented with Angular, and most recently embraced React and es6.
Almost two years ago, I quit my job and started building a side project in React and Fluxxor for fun. At this point there were a bunch of Flux implementations and no dominant library had emerged. I got frustrated with the build process and then got distracted with other life experiences.
I returned to javascript less than a year later and was amazed at how much better things got. I could do npm install and npm start and there was a good chance things would actually work. I was doing the same google searches but noticed that the documentation was a lot better. I also had a friend this time around and he steered me toward Redux and es6. Javascript suddenly became an enjoyable language for me enough that I plan to focus on it. This is after more than close to twenty years of fits and starts.
I dunno. I'm starting to wonder if writing disciplined code with jQuery for support is a better approach than the framework soup we've been dealing with in recent years. I know, I uttered the "j-word that shalt no longer be spoken" but that's kinda' my point--what's wrong with writing code anymore?
If you use simple, clean modular coding patterns, componentize for reuse, make judicious use of promises, and sprinkle in lightweight templating and routing libraries, etc., you'd effectively have your own mini-framework on which to continue building. After all, frameworks themselves are code under the covers--code that encourages patterns.
Sure, some say it's reinventing the wheel to write JS without someone else's framework. But, it seems to me that the frameworks are re-inventing the wheel. Not only is there a new one every day, but they are even re-inventing themselves (I'm looking at you Angular). Looking at the mere scaffolding alone for some of these frameworks makes me think, "what are we doing to ourselves?". Generate an "empty" project on some of these guys and prepare to be overwhelmed with opinionated cruft. Rolling my own code is not reinventing the wheel, because Angular, et. al. are not the wheels I'd invent in the first place.
Until a framework comes along that truly abstracts away HTML, CSS, the DOM and the rest of the old Web, so that it genuinely allows construction of clean event-driven, componentized applications, I'm not sure I see the benefit of playing the framework du jour game.
If you use simple, clean modular coding patterns, componentize for reuse, make judicious use of promises, and sprinkle in lightweight templating and routing libraries, etc., you'd effectively have your own mini-framework on which to continue building. After all, frameworks themselves are code under the covers--code that encourages patterns.
Sure, some say it's reinventing the wheel to write JS without someone else's framework. But, it seems to me that the frameworks are re-inventing the wheel. Not only is there a new one every day, but they are even re-inventing themselves (I'm looking at you Angular). Looking at the mere scaffolding alone for some of these frameworks makes me think, "what are we doing to ourselves?". Generate an "empty" project on some of these guys and prepare to be overwhelmed with opinionated cruft. Rolling my own code is not reinventing the wheel, because Angular, et. al. are not the wheels I'd invent in the first place.
Until a framework comes along that truly abstracts away HTML, CSS, the DOM and the rest of the old Web, so that it genuinely allows construction of clean event-driven, componentized applications, I'm not sure I see the benefit of playing the framework du jour game.
>Until a framework comes along that truly abstracts away HTML, CSS, the DOM and the rest of the old Web, so that it genuinely allows construction of clean event-driven, componentized applications
So react?
So react?
[deleted]
More like Swing.
Frontend development in JavaScript has become a hellhole.
Projects can have three plus build tools that each take a long time. Massive list of dependencies plus bad dependency management, lack of documentation, everything changes so fast you need to find the correct stackoverflow answer for this week solution to your build problems, build tools depends on other build tools configurations in undocumented ways, reimplementation of the model & business logic of each project, constantly reinvention of the wheel.
And the end result? Web just becomes slower and slower.
Developers today build software that fits their paradigm, not the users experience.
Projects can have three plus build tools that each take a long time. Massive list of dependencies plus bad dependency management, lack of documentation, everything changes so fast you need to find the correct stackoverflow answer for this week solution to your build problems, build tools depends on other build tools configurations in undocumented ways, reimplementation of the model & business logic of each project, constantly reinvention of the wheel.
And the end result? Web just becomes slower and slower.
Developers today build software that fits their paradigm, not the users experience.
That last sentence succintly describes my primary issue with front end developing, and why I'm starting a new job in a few weeks that is almost purely backend.
Most of my recent web work has been trying to manage shared libs and duct taping the build process together. Every feature branch has major shrinkwrap merge conflicts because there is so much module churn.
Most of my recent web work has been trying to manage shared libs and duct taping the build process together. Every feature branch has major shrinkwrap merge conflicts because there is so much module churn.
I am currently working on a Node/React project with 120 first-order dependencies. 120! And it's just a crud app with a few canvas visualisations.
Man... when it's laid out like that, it does seem a bit insane.
By comparison Python's primary web framework in 2012 was Django, and today it remains Django. Despite this relatively glacial pace, there's been a ton of improvement to Django, and the surrounding Python ecosystem. A more conservative development culture can pay off sometimes, since it allows the community as a whole to focus on polishing the existing ecosystem. As opposed to dropping Django when "real time" Websockets were all the rage, there was a concerted effort to include it in the framework with the Django Channels project.
By comparison Python's primary web framework in 2012 was Django, and today it remains Django. Despite this relatively glacial pace, there's been a ton of improvement to Django, and the surrounding Python ecosystem. A more conservative development culture can pay off sometimes, since it allows the community as a whole to focus on polishing the existing ecosystem. As opposed to dropping Django when "real time" Websockets were all the rage, there was a concerted effort to include it in the framework with the Django Channels project.
Don't forget that move towards microservices and Go caused many Django devs to move away from it.
That's certainly true for that particular niche. However Python has certainly come into it's own over that timespan, with the rise of various machine learning approaches. This reinvigoration, seems to have manifested in the web side of the language too, seeing as many models eventually need some form of HTTP server.
Admittedly though the community isn't perfect. There was quite a schism over Python 2 vs 3 for a while. Thankfully it's looking like that may be past us.
Anecdotally the Python community seems more active than ever.
Admittedly though the community isn't perfect. There was quite a schism over Python 2 vs 3 for a while. Thankfully it's looking like that may be past us.
Anecdotally the Python community seems more active than ever.
From the article > How much has medicine, accounting, politics, law, construction, or math changed in that time period?
The webapps that services those industries has changed massively in the past decade. The web has evolved from simple documents to complex applications. The browser is the new app delivery platform, and it's perfectly reasonable that this would bring increased complexity.
Backend development has countless languages, compilers, frameworks, toolchains, CLIs, OSes, containers, etc. - so it's really not that strange to see frontend dev catch up.
What's rather amazing is that there's just 1 language with everything else being frameworks and tools that let you shape it to your needs (and also runs just as well server-side with nodejs).
The webapps that services those industries has changed massively in the past decade. The web has evolved from simple documents to complex applications. The browser is the new app delivery platform, and it's perfectly reasonable that this would bring increased complexity.
Backend development has countless languages, compilers, frameworks, toolchains, CLIs, OSes, containers, etc. - so it's really not that strange to see frontend dev catch up.
What's rather amazing is that there's just 1 language with everything else being frameworks and tools that let you shape it to your needs (and also runs just as well server-side with nodejs).
Can anyone tell me why I shouldn't still just use standard, ECMAScript, and (gasp) jQuery? There's so much churn in the JS world, sometimes it makes sense to just build something, and then optimize it later.
The problem I always have with jQuery is it turns into a maintenance nightmare (read: spaghetti everywhere) and there's a lot of repetition.
I'm sure there are some people with organized jQuery front ends, but it's way too easy to have a mismangled giant ball of mud. Going with a framework you can of course still have a giant ball of mud, but it's a lot harder to get there. Anything component based is a big step up in organization.
My other big issue is 90% of what I'm doing on the front end is ajax calls and keeping the UI state up to date. A framework like Vue makes it so trivial.
I sincerely encourage you to give something like Vue a try. You don't have to adopt it all in, you can use it for just a single on page component and see how you like it. The getting started guide is great - if you have a solid understanding of JS you will be up and running in an afternoon.
I was hesitant like you and as soon as I tried Vue I haven't looked back.
I'm sure there are some people with organized jQuery front ends, but it's way too easy to have a mismangled giant ball of mud. Going with a framework you can of course still have a giant ball of mud, but it's a lot harder to get there. Anything component based is a big step up in organization.
My other big issue is 90% of what I'm doing on the front end is ajax calls and keeping the UI state up to date. A framework like Vue makes it so trivial.
I sincerely encourage you to give something like Vue a try. You don't have to adopt it all in, you can use it for just a single on page component and see how you like it. The getting started guide is great - if you have a solid understanding of JS you will be up and running in an afternoon.
I was hesitant like you and as soon as I tried Vue I haven't looked back.
What's the best way to manage templates in Vue if you don't want ES6-style string literals everywhere and you don't want a build step?
You can do script style templates, e.g.
<script type="text/x-template" id="component-name-template"> <div> {{ msg }} </div> </script>
Then when setting up your component you specify the template property with the id, e.g.
Vue.component('component-name', { template: '#component-name-template' });
Honestly though this sucks if you plan on reusing components. Can I ask why you don't want a build step? The single file components are great.
<script type="text/x-template" id="component-name-template"> <div> {{ msg }} </div> </script>
Then when setting up your component you specify the template property with the id, e.g.
Vue.component('component-name', { template: '#component-name-template' });
Honestly though this sucks if you plan on reusing components. Can I ask why you don't want a build step? The single file components are great.
Thanks. Yeah, I looked at that option too and agree that it does suck. :)
Just didn't want a build step due to complexity. I know it's not that difficult, but wanting to keep it as simple as possible.
I don't really get why Vue opted not to support URLs for their templates. It could be easily managed via co-location of templates with components and/or naming conventions. You actually wouldn't even need to specify the URL. It just grabs it from the component's directory by name.
Anyway, for me, this is a weakness. I get that they want to maintain the single file component model, but I'm not sure it's worth it when your choices are literals, script templates, or an extra build step. OTOH, co-locating a dependent file is no biggie, even if you don't get to claim single file components.
EDIT: I was close to going with Vue for a project a month or so ago. But, wading into it, I realized the build step would be necessary to do it "right". Suddenly, you're downloading plugins, xcode, and all kinds of other stuff, then setting up a build. It just seems a lot for, essentially, single file templates. Granted, several steps are automated, and you're just issuing npm commands, etc. But, I started thinking, "do we really want all of this magic? What if the build just doesn't work one day or we need to reconfigure? Now we're troubleshooting and figuring out the linkages that were created and the other magic.
The whole process was a stark reminder that you're in someone else's world. Maybe I'm too big on control. But, I don't want to be sucked into too many dependencies.
Just didn't want a build step due to complexity. I know it's not that difficult, but wanting to keep it as simple as possible.
I don't really get why Vue opted not to support URLs for their templates. It could be easily managed via co-location of templates with components and/or naming conventions. You actually wouldn't even need to specify the URL. It just grabs it from the component's directory by name.
Anyway, for me, this is a weakness. I get that they want to maintain the single file component model, but I'm not sure it's worth it when your choices are literals, script templates, or an extra build step. OTOH, co-locating a dependent file is no biggie, even if you don't get to claim single file components.
EDIT: I was close to going with Vue for a project a month or so ago. But, wading into it, I realized the build step would be necessary to do it "right". Suddenly, you're downloading plugins, xcode, and all kinds of other stuff, then setting up a build. It just seems a lot for, essentially, single file templates. Granted, several steps are automated, and you're just issuing npm commands, etc. But, I started thinking, "do we really want all of this magic? What if the build just doesn't work one day or we need to reconfigure? Now we're troubleshooting and figuring out the linkages that were created and the other magic.
The whole process was a stark reminder that you're in someone else's world. Maybe I'm too big on control. But, I don't want to be sucked into too many dependencies.
I absolutely had a lot of the same concerns, and I was just as confused as you as to why Vue wouldn't support remote url templates.
That said, once I decided to roll with it, it took about a week* to get it configured how I have it now and have a decent understanding of how/why it was configured. *not a straight week of banging my head into webpack, but some bits of time here and there as I did development
The one other thing that kind of pushed me over the fence into going down the build step route was that I get a minifier, a LINTer and get to use ES2015 (or typescript, or whatever) syntax.
>"do we really want all of this magic? What if the build just doesn't work one day or we need to reconfigure? Now we're troubleshooting and figuring out the linkages that were created and the other magic.
Totally valid concern and I see where you're coming from. Once I got into it, though, I realized the only webpack specific syntax is the configuration; how you link your JS files together is just through import/export statements (ES2015 and beyond module system).
That said, once I decided to roll with it, it took about a week* to get it configured how I have it now and have a decent understanding of how/why it was configured. *not a straight week of banging my head into webpack, but some bits of time here and there as I did development
The one other thing that kind of pushed me over the fence into going down the build step route was that I get a minifier, a LINTer and get to use ES2015 (or typescript, or whatever) syntax.
>"do we really want all of this magic? What if the build just doesn't work one day or we need to reconfigure? Now we're troubleshooting and figuring out the linkages that were created and the other magic.
Totally valid concern and I see where you're coming from. Once I got into it, though, I realized the only webpack specific syntax is the configuration; how you link your JS files together is just through import/export statements (ES2015 and beyond module system).
That's good feedback. Yeah, I was really close. As with other frameworks, I do think Vue surfaces too much "old Web", but I also think it was the cleanest and simplest of the contenders. I could see it making dev at least somewhat more enjoyable, organized, and productive.
>it took about a week to get it configured
Funny, that's about what I thought it might take--a week of somewhat committed effort. Felt like we didn't have that to spare though, and wasn't 100% sure about the ROI on that time. Felt like a roll of the dice.
Now, whether we'd have already recouped that week is an open question, and setting up a structured JS project was also no small task. But, likewise, we now have a good pattern/mini-framework with a component inheritance model. So, we're recouping that investment as I write this., and we're not tied to deep dependencies or magic.
Next time out, I may have another look at Vue. But, I am really hoping for a more componentized-event driven model that completely abstracts the old Web. Even moreso than React, but with more simplicity and only JS or Typescript in the mix. Kind of a Swing for JS is the best analogy I can make.
>it took about a week to get it configured
Funny, that's about what I thought it might take--a week of somewhat committed effort. Felt like we didn't have that to spare though, and wasn't 100% sure about the ROI on that time. Felt like a roll of the dice.
Now, whether we'd have already recouped that week is an open question, and setting up a structured JS project was also no small task. But, likewise, we now have a good pattern/mini-framework with a component inheritance model. So, we're recouping that investment as I write this., and we're not tied to deep dependencies or magic.
Next time out, I may have another look at Vue. But, I am really hoping for a more componentized-event driven model that completely abstracts the old Web. Even moreso than React, but with more simplicity and only JS or Typescript in the mix. Kind of a Swing for JS is the best analogy I can make.
I've been a web developers for 5 years like the author, and, I as well, went through the jQuery, Knockout, Backbone, React, Vue road. On my daily job I use Node & React/Redux, on personal projects, I prototype in Python using bottle and vanilla JavaScript with axios[1].
Before, I wanted to use the latest stack, maybe looking for approval from the "community", something like: "Hey, I'm building a X app with Express, React, React Router, Redux, Immutable..." But by the time I had the basic setup, my motivation was gone (at that time there was no react-starter-app[2]).
So I'd say you should start with whatever you are most comfortable, doesn't matter if it's React or jQuery. The goal, IMO, is to start building stuff.
Now, I just don't care what's the latest JS framework, I don't dislike them, all the opposite, I get excited about them[3], but I focus on what's my best weapon for the job.
- [1] https://github.com/mzabriskie/axios
- [2] https://github.com/facebookincubator/create-react-app
- [3] https://github.com/KingPixil/moon
Before, I wanted to use the latest stack, maybe looking for approval from the "community", something like: "Hey, I'm building a X app with Express, React, React Router, Redux, Immutable..." But by the time I had the basic setup, my motivation was gone (at that time there was no react-starter-app[2]).
So I'd say you should start with whatever you are most comfortable, doesn't matter if it's React or jQuery. The goal, IMO, is to start building stuff.
Now, I just don't care what's the latest JS framework, I don't dislike them, all the opposite, I get excited about them[3], but I focus on what's my best weapon for the job.
- [1] https://github.com/mzabriskie/axios
- [2] https://github.com/facebookincubator/create-react-app
- [3] https://github.com/KingPixil/moon
Remember that part of being an experienced developer is having the wisdom and knowledge to select the right tool for the right job. Sometimes that's the hot new cool shit. Oftentimes it's something much more mundane.
If you project calls for "standard, ECMAScript, and (gasp) jQuery," then use them! Just be aware of the benefits and trade-offs.
If you project calls for "standard, ECMAScript, and (gasp) jQuery," then use them! Just be aware of the benefits and trade-offs.
I think alot of people forget this. How many frameworks have I passed over, because I knew they were a trend, before I selected something like React to develop with?
It's a fine balance, choosing between a technology you know and "always be learning". Experience guides how much of the bandwagon you jump onto.
The funny part is, that in no other industry is there this expectation that things be plain, simple and easy. We, as developers, are blinded by our desire for instant gratification that is uncommon in other industries.
My mom, as a paralegal, never complained that the path to completing a case took 47 different filings with each page printed in triplicate, whose versions changed depending on the dates in the case. It just.. IS. Sure it can be better. But the expectation that it be, in an almost petulant way, is what I'm talking about here.
It's a fine balance, choosing between a technology you know and "always be learning". Experience guides how much of the bandwagon you jump onto.
The funny part is, that in no other industry is there this expectation that things be plain, simple and easy. We, as developers, are blinded by our desire for instant gratification that is uncommon in other industries.
My mom, as a paralegal, never complained that the path to completing a case took 47 different filings with each page printed in triplicate, whose versions changed depending on the dates in the case. It just.. IS. Sure it can be better. But the expectation that it be, in an almost petulant way, is what I'm talking about here.
For small projects, this is definitely still OK. Green browsers don't really need jQuery any more, but if it's what you're comfortable using and it gets the job done, then use it.
Large projects or team projects, you will want to use something with more structure.
Large projects or team projects, you will want to use something with more structure.
Some of the newer frontend frameworks are so small that it really doesn't benefit you to use jQuery even for small projects. It lacks structure and it's way too easy to start manipulating state though the dom when you could have reusable components and a decent structure with a few extra lines of code.
You can, but it requires a lot of discipline, and the code you're left with is not particularly fast or elegant.
Still, if you must: create classes to represent components, with methods used to manipulate markup, and plug those methods into a simple pub/sub event bus. This will work for very simple apps, but ask yourself - how simple will your app remain?
Still, if you must: create classes to represent components, with methods used to manipulate markup, and plug those methods into a simple pub/sub event bus. This will work for very simple apps, but ask yourself - how simple will your app remain?
I'd say it depends on whether you're fundamentally serving documents or an application. The new breed of js frameworks probably isn't the right choice for Wikipedia, and jQuery probably isn't the right choice for Spotify player. A generalization, for sure, but that is how I tend to think about it.
No one is seriously saying you can't. If your problems are simple enough to be solved with plain js/jquery, feel free.
I don't get all this tooling and framework hate - no one is forcing you to choose anything, it's an open buffet, and you can choose as much as you want from wherever you want, for free.
I don't get all this tooling and framework hate - no one is forcing you to choose anything, it's an open buffet, and you can choose as much as you want from wherever you want, for free.
I think he/she is saying the opposite: that people who don't use frameworks get the hate, and there is a lot of pressure to pick a framework.
Not an invalid point. Mention jQuery here, or anywhere, and witness the response.
Not an invalid point. Mention jQuery here, or anywhere, and witness the response.
Man, building UIs that way was so painful in so many little ways. You can still do it if you like... as long as your code is testable and changeable (sorry but comfort/familiarity isn't everything)
Jquery was a 'patch' to standardise js and the dom across browsers. It's no longer really needed because both native js and the dom have caught up.
How do you end up with like six "build systems" for web applications? What even is there to build? Why can't you concatenate all javascript and run it through a minifier with a shellscript?
I haven't done webdev since 2010 and now that I look at it, it just seems so bizzare.
I haven't done webdev since 2010 and now that I look at it, it just seems so bizzare.
Yours do that if you want, but then you might have customers using large parts of the code base that other don't have access to so you want to use code splitting. You probably have some images and want them to look good on all screens but also want them to be a small size so you use image srcset but you need to output 6 images for all the sizes. If you're using svgs you might want to inline these. I mean it goes on and on really, just look at all the headings within the webpack docs if you want more insight. I can understand why it seems crazy and perhaps it is more crazy than I think but if you want you can just concatenate all the scripts, if you want more bells and whistles then you can too
> code splitting
That should only take a few lines in a Makefile.
> output 6 images for all the sizes
That should only take a few lines in a Makefile.
JSTARGETS = foo.js bar.js
build-js: $(JSTARGETS)
foo.js: foo_main.js lib_a.js lib_b.js
cat $< > $@
bar.js: bar_main.js lib_a.js lib_x.js lib_y.js
cat $< > $@
> output 6 images for all the sizes
IMAGES=( baz quux )
IMGSRC=(patsubst %,src/images/%.jpg,$(IMAGES))
IMGSML=(patsubst %,build/images/%-small.jpg,$(IMAGES))
build/images/%-small.jpg: src/images/%.jpg
convert $< -resize 25% $@
build-images: $(IMGSML)In fact this is exactly what early JS build systems looked like. When I worked at Bing this was exactly what the production deployment script looked like (at a simple level).
It no longer does. The tools move on because the uses get more complex. See the sibling reply here for a good reason why.
It no longer does. The tools move on because the uses get more complex. See the sibling reply here for a good reason why.
The main difference is that the JS source is being parsed, and most of the build steps operate on the AST. This is what allows things like transpiling modern language features to more broadly supported versions, doing dependency resolution, pruning, and automatic splitting (imagine your Makefile with 300 js files). Remember that JS does not yet have a built-in module system - simply pasting source files together means you'll be rolling your own.
Yep, alot of people forget that - because JS is delivered to the browser and not preemptively downloaded (or executed in a compiled form on a server), there's NO opportunity to do things like optimization, tree shaking, etc. that other JITs do, or compiled languages do.
And the moment you accept that it is necessary (and why wouldn't it be - languages are for developers, not computers, and that means they by necessity will include cruft), you require a build system to at the very least, run the optimizer and minimizer.
It seems like a trivial problem but it isn't. We are long past the days when JS was only used to make an image blink.
And the moment you accept that it is necessary (and why wouldn't it be - languages are for developers, not computers, and that means they by necessity will include cruft), you require a build system to at the very least, run the optimizer and minimizer.
It seems like a trivial problem but it isn't. We are long past the days when JS was only used to make an image blink.
Minify [1] is a great alternative, specially if you use Go. For simple case, you don't need Node ou NPM at all.
[1]: https://github.com/tdewolff/minify/tree/master/cmd/minify
[1]: https://github.com/tdewolff/minify/tree/master/cmd/minify
One thing I like about JS is that you don't need to compile or build anything. I get it that you will need to bundle everything in production, but I am baffled that bundling can't be automatically done. The process should be transparent to developers.
if you use ES6+ and target not so capable browsers, if you use JSX you need to compile. And while you can write React without the JSX it is not something anyone would enjoy.
Why I've never seen any Ember.js dev writing about javascript fatigue? Because healthy community, matured framework, happy developers never felt that. Ah, and there are plenty of jobs with much higher salaries.
> I’ve only been a full time web developer for the past 5 years. It’s barely enough time to start calling myself a “senior” Software Engineer.
Offtopic, but when does one start to be "senior" then? I've been coding for the past 17 years or so, including about 6 years professionally. Do I get to be a "senior" dev now? How do I convince my boss?
Offtopic, but when does one start to be "senior" then? I've been coding for the past 17 years or so, including about 6 years professionally. Do I get to be a "senior" dev now? How do I convince my boss?
Ask your boss if you can get a promotion / raise and if they deny you that, then ask if at the very least you can have a new title, then use that on your resume for your next job.
Offtopic, but when does one start to be "senior" then?
It differs massively from company to company. Where I'm currently working the guideline is 10 years relevant professional experience plus either significant project management experience or having an area where you can generally be considered an expert in your field.
I've also worked at places where people 3 years out of school are considered senior.
It differs massively from company to company. Where I'm currently working the guideline is 10 years relevant professional experience plus either significant project management experience or having an area where you can generally be considered an expert in your field.
I've also worked at places where people 3 years out of school are considered senior.
Every time I read an article like this I wonder: "Where are all the three.js users? Am I the only one? And am I the only one not suffering from JS fatigue?"
...and that's why so many devs secretly (or not so secretly) hate JS
[deleted]
I really don't understand this hate for Angular 1. I think till date it is among one of the best things to happen to the web after jQuery. Yes, I think jQuery is great and Angular 1 is fantastic for making website super quickly and maintaining them.
I can't stand Angular 1 the framework or the language.
I also credit them with promoting modern web development and producing a realistic expectation that browsers can actually present some really cool, sophisticated applications. It is largely because of Angular 1 (and other, less known libraries) that we currently are seeing an explosion of innovation. I may not have liked the framework, but I cannot deny the incredibly powerful (and in my estimation, positive) effect it had on the industry.
I also credit them with promoting modern web development and producing a realistic expectation that browsers can actually present some really cool, sophisticated applications. It is largely because of Angular 1 (and other, less known libraries) that we currently are seeing an explosion of innovation. I may not have liked the framework, but I cannot deny the incredibly powerful (and in my estimation, positive) effect it had on the industry.
You're right about that.. It's still my favorite framework even though I too have my pet peeves (no lazy loading, really?).
Anyway, what are you currently using? Why?
Anyway, what are you currently using? Why?
Implementing unit tests always seemed excessively painful, especially when compared to React/Redux.
In my experience it wasn't that hard writing unit tests for Angular 1 modules. They have a pretty solid testing framework built for it.
Hard isn't really the right term, more just annoying, because you have to mock out everything and the kitchen sink. To be fair, I can't think of a frontend framework that had any real unit-test framework before Angular. So it was an improvement at the time.
Another option to avoid this JS fatigue is to switch to a different web development job. Get a job which focuses on backend and APIs.
Or you can even take it further and go focus on more networking / sysadmin / devops area. Les fatigue there.
Or you can even take it further and go focus on more networking / sysadmin / devops area. Les fatigue there.
My advise is when you care about your "career" stick to the one with the largest user base (or depending on your location). Learn it, love it, embrace it. Then experiment with whatever you want to.
Just a thought, but: you don't have to write JavaScript. There are lots of other languages than JS, and lots of areas of programming other than the web. So it's really, really possible to not write JS if you don't want to. Just think, you could be free! Forever!!!!!
I'm curious about the statement "React has become the champion"
I've recently moved from ASP.NET MVC/jQuery to Angular4. I'm extremely happy with the transition and I intend to stick with Angular. After not worked with React (yet), what am I missing?
I've recently moved from ASP.NET MVC/jQuery to Angular4. I'm extremely happy with the transition and I intend to stick with Angular. After not worked with React (yet), what am I missing?
These days I split my time between React & Angular 4. I love Angular as much as React. Both very cool platforms to work on, if you are happy there, stick with it! There are tons of jobs these days on the new Angular.
Nothing, its mostly hype. If Angular works for you, you are not missing much
Oh not another one of these
I have "JS Fatigue" fatigue
I have "JS Fatigue" fatigue
I fully agree with the OP. I used Bootstrap/jQuery, Ext JS, D3, Highcharts, Angular and React. Each of these felt right for a period of time. Now, I'm using my experience to put the best features of all these into my own commercial framework called CxJS - https://cxjs.io/
In other environments (e.g. Python, Java) nobody expects you to know everything about the specific libraries used in a company; once you know the language and a bit about the technologies (e.g. work on Linux, on a webapp or a desktop app), you're good, you'll pickup the details while working.
Forcing a technology change because it's not the "latest and greatest big, shiny thing"... I find this is a slightly disturbing trend in frontend development.