But no, I never get to read that, just complaints about how the whole community is dumb. Really? That seems unlikely. I don't believe this is pointless tech churn, akin to fashion. It really feels to me, at least, that there is a direction that the tooling is heading. I'm not sure what it is, but I feel like if that's where these conversations were focused (instead of just rejecting the current state of things) we could figure it out.
Yeah, it's frustrating as shit, we needed to all be pissed about it for a bit, but let's have a productive conversation.
Okay, I'll bite.
With a web browser, a DOM, and Javascript, where do you see this all heading that's full of truth and beauty?
Where does the churn end if it's not pointless?
Cause you've got a web browser that was designed to view pages of linked information that has now been pressed into service as a ad-hoc run-time for building applications, a DOM that is so poorly implemented that most everyone tries to abstract it away at some point, and a language that is universally regarded as one of the worst ever.
Is that what you build on for the future? Cause then I do see it being pointless tech churn because your fundamental building blocks are too seriously flawed.
If the future is programs that people can download and run on their computer on demand you'll need a good run-time, language agnostic, compiles to binary, sandboxed, with a well defined UI system not based on document display. There's no web-browser, DOM, or Javascript in sight.
If you had such a thing this thread of conversations wouldn't even be happening. I sincerely hope that someone smarter than me comes up with that (yes, Java was a close but no cigar) and we gravitate away from the morass we have now.
The web app platform represents one of the largest, if not literally THE largest, explosions of programming and application development ever seen in the history of humankind. It also represents one of the most open and portable computing environments ever developed. It incubated a revolutionary and indispensable app for indexing, searching, and retrieving an unprecedented staggering corpus of human knowledge (Google.com); apps that have enabled hundreds of millions of people to effortlessly publish their writing, videos, pictures, etc globally and instantly (Twitter, YouTube, WordPress, Blogger, etc etc); apps that make it trivial to find most of the people you have ever known and to collapse time and space to communicate with them (Facebook, Gmail, etc etc); apps that enable you to select virtually any product imaginable and have it delivered, usually within 24 hours if needed (Amazon, Ebay, etc etc); not to mention probably millions of other more obscure apps to handle amazingly specific mundanities of office life, travel, entertainment, citizenship, finance, etc etc etc.
To look at all this and land on the conclusion that JavaScript and the web stack are fucked up‚— "a language that is universally regarded as one of the worst ever" — period, full stop, EOM, throw them out — seems aggressively contemptuous and beside the point.
It's sort of like looking at a raging party filled with some of the most interesting people you've known and some of the most interesting people you've ever heard of and complaining about the type of speakers being used to play the music.
I can't speak for the OP but I think that's roughly what they were getting at.
(Also, side note, Tim Berners Lee may perhaps have conceived the web as a place for documents, but he also seems to have since then embraced it as an application platform, not that his opinion or original vision should in any way confine what the web becomes. http://venturebeat.com/2013/03/09/tim-berners-lee-sxsw/ )
"When I first came here, this was all swamp. Everyone said I was daft to build a castle on a swamp, but I built in all the same, just to show them. It sank into the swamp. So I built a second one. That sank into the swamp. So I built a third. That burned down, fell over, then sank into the swamp. But the fourth one stayed up. And that's what you're going to get, Lad, the strongest castle in all of England."
Well, WebAssembly is on the way, so you won't have to use JavaScript. WebGL means you could, I guess, skip over the DOM entirely if you wanted to. None of this is fantastic, of course, but it's where we are.
Programs that people can download on demand existed, and still exist, yet the web is more popular. It's cross-platform, you don't have to install anything, updates are instant. What cross-platform UI are you going to use to address Windows, Mac, iOS and Android together?
To put it more succinctly, the "truth and beauty" for me is that it works, and it works today. I'm far happier iterating on that than noodling around imagining the perfect code execution environment that, as far as I can see, has no hope of existing any time soon.
At this point, this is argument is 100% false. Browsers of today aren't the browsers of the 90s. Chrome came out in 2008 and has ALWAYS been designed to run applications, and an entire operating (ChromeOS) is based on the idea that the browser isn't just a system built for viewing linked documents, but a valid application platform.
This is a case of the evidence not fitting the theory well, so people complain about the evidence. If the browser/DOM/HTML/JS ecosystem "technically" is terrible, but in practice dominates the competition, then there is something about it that is better. This is not a fallacy, but a simple supply and demand argument.
You just described Windows 10's UWP.
This is not pointless, but it is pretty uncontrolled. Basically, there is a natural tendency for engineers to want and rewrite old stuff, once all the flaws of once-cherished yesteryear solutions are glaring. Normally, engineers don't have a freehand in ditching old projects and rewriting from scratch, so they have to maintain what exists.
But with all the startups and the site redesigns, now they can, and they do. Why not--it's fun, it replaces old solutions that showed their limits, and the scope is somewhat limited; it's just a website, after all. Moreover, everyone can jump in and create their foobar.js lib or framework; the core node/JS is pretty easy.
> It really feels to me, at least, that there is a direction that the tooling is heading.
It is quite uncertain. Progress is made when you build on previous work, but here it is mosly about saying that the old solution doesn't work eventually, so let's do it this way instead. It looks a lot like infinite recursion, with pretty thin state.
Just as some examples.... we've moved some pages to vanilla jQuery to Angular and have gained orders of magnitude more stability (read: basically no state-inconsistency bugs in newer pages).
If you're faced with vanilla javascript in the DOM and have any amount of complexity to it, then you should be using angular/react, if not for your sanity than for the sanity of the one who will need to maintain your code (read: you in 3 months).
If you're knowledgable enough to know that your use-case doesn't work with the newer tools, then more power to you. But the productivity gains from moving away from your jQuery spaghetti code to one of the more managed frameworks is well worth the rewrite time.
I don't know much about going from Angular to React, or Backbone to Angular though.... the choice of framework is likely dependent on what kind of user interactions dominate your app and subjective comfort.
But if you're careful, you can actually transition apps slowly over to Angular and I assure you, you could get rid of so much of your custom-written (probably not well tested) DOM management code it's not even funny.
It is a symptom that the platform is woefully broken, hence the multitude of solutions to try to make it workable. Neither of which work particularly well, so there is always room for one more to 'solve' it slightly differently.
The same story played out during the early 2000s, before rich JavaScript applications were really an option, with non-JS based web frameworks. In Java alone there was Struts, WebWork, Wicket, Tapestry, JSF, Spring MVC, and countless others, each one sucking more than the other. They are all pretty much dead now because people realized the insanity of trying to build a GUI using a page request based approach.
This problem will not be fixed because JavaScript itself is the problem. It simply is too limited a language to be used for large and complex applications. The proof of this is that JavaScript is used for exactly zero non-browser runtime environments (discounting node.js whose only appeal is to use the same language on the server as in the browser).
The attempts to compile down to JS is the best we can currently do, which is why the best and most complex JavaScript applications that have ever been made have been done this way, but obviously a native solution will be the better solution.
The best bet would be an intermediate layer, a kind of JVM for the web, on which a thousand languages could run. That is bound to be a long way out though, so we have at least a few more years of pointless JavaScript framework churn.
Electron? Atom? Slack? React Native? Espruino?
Also, there are plenty of non-web Node.js applications, e.g. https://github.com/sindresorhus/awesome-nodejs#command-line-...
> This problem will not be fixed because JavaScript itself is the problem. It simply is too limited a language to be used for large and complex applications.
I agree, and Facebook (Flow), Google (Dart, TypeScript, and probably others), and Microsoft (TypeScript), agree with us.
> The best bet would be an intermediate layer
See: WebAssembly[2], the successor to asm.js (sometimes called "the bytecode for the web").
Interestingly, it was, as you've pointed out, never resolved. Instead, it all became obsolete. I personally left javaland and started writing with Rails (even the non-web stuff I generally started using Python rather than java).
I suspect that we're heading down that road again. I think the modern javascript frameworks are the product of very intelligent and talented people, but my gues is that something interesting and "unanticipated" will sweep this all aside.
To risk a prediction, I think that other languages transpiled to isomorphic javascript will provide a new approach that will allow excellent languages like ruby and python to be used to write an entire web app again.
Until then? I wish I'd had the conviction to avoid MVC frameworks in the early 2000s. It's easy to feel like you're doing things the "old way", but I wasted a lot of time chasing java frameworks only to abandon the entire enterprise a year or two later… of course, it wasn't entirely my decision, it's hard to go against the grain, since you're rarely the only developer on a team.
I believe Qt's QML also uses JavaScript.
This discussion is often brought up in relation to React/Redux/Babel/Webpack, and people thinking they have to completely master all of them to start making websites, when the reality couldn't be further from the truth.
Twitter had an amusing quip of the topic last week:
> If you’re feeling overwhelmed by Slack or React (judging by the HN front page this week), I politely suggest you re-evaluate your life.
There may be that. There's also:
a) Some of us are old enough to have mortages/kids/parents to support/houses needing renovation/desire a balanced life. We value skills that stay useful, and don't have the free time to keep learning variants of the same again and again*
b) Companies we work at/for value stability. They look at IT choices on a 5+year horizon; they don't have VC money to burn to 'rewrite' when JavaScript framework X no longer works. Which am I more likely to get sacked for? 1) Not using the cool thing and us missing out, or 2) using the cool thing and having to explain in 18 months time that we need another $20,000 to rewrite it into the Next Cool Thing?
Before you write us off, please do a 360 and see what the field looks like from other perspectives.
* I didn't say 'don't have time to learn'. We learn - but what we learn is evaluated carefully, and we have a much wider field to learn (Programming/Management/PM/Negotation - just a few of the core work-focused skills)
[Edited for formatting]
I believe there is a fundamental lack of understanding about web development - mainly HTTP and HTML. These technologies are simple which is why most developers don't bother to learn them. Being a developer both before and after putting in an effort do deeply understand the foundations of web dev, I can tell you my experience was like turning on the lights after struggling in the dark.
Basically what I found is that web app development was designed to work great in specific ways. If you don't know this and try to get it to work in a way that it was never meant to, you're gonna have a bad time. Sadly, every front end framework and many JavaScript libraries fall into this category. They focus on bending the natural web development paradigm into some other form. Which one will "win"? None - there's no right way to do something wrong. The real question is when we will stop falling for the pitch of the snake oil salesmen.
I assure you, there is no functionality that any of the frameworks bring that does not already exist and can be implemented in much simpler, maintainable and architecturally sound ways. Do not believe what the Framework charlatans claim. I can disprove every claim with real, working code examples.
Another reason we are inundated with poor frameworks is there is no other good entry point for developers new to web application development. Nobody wants to (or should have to) read the HTTP spec when they just want a simple CRUD app.
In summary: the reason these JavaScript frameworks exist is 1) Easy starting point for beginners 2) Make web development more like desktop/OOP/whatever the average developer is used to. There there cannot be a "good" web architecture until one is based on how web development actually works, not how we think it should work.
Please do. I am interested in seeing more detail in your post.
I studied industrial automation and I see it as a automation system a bit. To make it simple I compare it to i.e. temperature control. There are many things influencing temperature in a room. Yet we want certain temperature in this room. We try to maintain good temperature and "good" can have multiple meanings. But everything in environment changes constantly and even if nothing changes we still have inertia.
That illustration probably is not that helpful. What I try to say is that it is probably almost impossible to tell where we are heading. We can recognize some general trends for a while, maybe even few longer term. This is very complex system, we see things as we go. In case of this system if we would commonly start to believe that system is heading in certain direction for sure, because of feedback loop it would change this direction.
Maybe what I want to express is just that I think that I should read more on systems and game theory.
I didn't have time to make this post shorter, sorry.
I think part of it is because of the proliferation of JS in recent years, whereas many people still have this notion of copy/paste Javascript "skiddies". Even among new grads with significantly less experience, I often hear some voicing concerns that "web developers are not real programmers", or there's "nothing hard about front-end work", "CSS is only for designers", or "only people who can't do CS become web developers".
On the other hand, yes, new frameworks are appearing every day, and it's obvious this is a huge source of frustration; but we do we need to chase every new framework? Is it actually true that an application written in X framework HAS to be re-written every 2 years instead of a pure jQuery-based application? What is preventing you from continuing to use Angular v1, that you have no choice but to port everything to v2? (also worth noting that you can port only parts of your app to v2 and run them in tandem but I digress)
I don't want to start another flame war here (which seems to be a common trend these few days), but how many people do you know that has a deep understanding of the costs of DOM reflows and how to mitigate/minimize them? As a full stack developer who has done quite a bit of front-end work the past few years, I can tell you: not many.
Okay, so maybe you say: "For X and Y application that knowledge isn't important." That very well may be the case, but how about those that build richer and more complex interfaces that (maybe) involves thousands or even hundreds of thousands of elements on the page? What then? Has no one ever seen the absolutely abysmal jank and (lack of) performance some JS apps have?
Is it really so horrible that we have to bash and nitpick on every single thing someone makes in the web community? Is it wrong for your kid to come home one day, exclaim "look what I drew today!", and show you a horrific picture of you looking like a gorilla? Or maybe it's okay that a lot of people are very working hard to do away with the hairy pain points we have currently, make it harder for you to shoot yourself in the foot, and maybe introduce some (small) pain points of their own inadvertently? Maybe it's possible that we're not all perfect humans with perfect ideas?
I'll give a quick example of what it's been like for my experience/or the experience of people I've worked with with jQuery/Angular/React.
jQuery: I want to update this element, okay I'll add a class or id as an identifier and query the DOM. Then I'll change the text in here. Oh but now I want to add another element to this list here (but I haven't cached the selector because I haven't learned that yet), let me query that element, create a new element, then append it.
Angular: I want to update the text on this element, okay, I'll change it in $scope, or the template directly. I also need to add a list item, okay, let's just .push() the new record in our $scope variable and it'll appear since we already told Angular to iterate on this model.
As for DOM updates? Well, I may or may not know it, but Angular is going to update it for me on the next $digest cycle which happens in intervals or can be triggered manually, after doing a dirty check for $scope/$watch.
React:
Similar to my thought process with Angular, I update the list item in our model with setState, and React will do its virtual DOM diffs and update for me, or maybe it doesn't update because shouldComponentUpdate told it not to. And it only touches the elements necessary on the actual DOM.
Perhaps it doesn't seem like a big difference, but after working with all 3, speaking from personal experience: once you have to return to doing pure jQuery, you realize how forced and unnatural everything now feels.
Give it five minutes: https://signalvnoise.com/posts/3124-give-it-five-minutes
It will settle down. Mostly as the devs grow a bit older and wiser, and as the end users start to rebel a bit harder - already non-tech people are publically lamenting js-heavy sites, wondering why so slow to load and run.
Lean js is happy js.
I've used "one function" libs before, and i'll continue to. The most recent example is a small lib that added Array.prototype.reduce to browsers that don't have it. It's 31 lines total (un-compressed, un-minified, un-anything)
Installing that small, well tested, and standards compliant function using a single npm command is significantly better than trying to do it correctly myself (which would most likely take an hour or so just to look over it's exact functional requirements, and it would most likely have subtle bugs), half-ass it and write my own "not quite reduce but close-ish" that i now need to use everywhere and need to train new hires on because "I didn't want to install a 31 line lib, so now you have this non-standard system that's buggy in it's own strange ways", or copy-and-paste the code from somewhere muddying the legal status of my codebase.
Coding in Ruby, C# or whatever is about learning the standard library as much as the syntax.
So much of the churn is caused by the constant rewriting of basic functionality (e.g. date handling), if we had a bigger and standardised standard library, we wouldn't need half of the packages
Everything points into the opposite direction, unfortunately.
> Babel has worked it’s way into the standard Javascript toolchain, and now most builders include it as a first-class plugin
Which version of Babel, 5? or 6? Because there's a lot of incompatibility issues right there and I think it is just as symptomatic of the typical JS fatigue issues which aren't really discussed.
I'm not as optimistic as the author about the future. The fatigue is real - and the value proposition of having to throw code away every year isn't that great. The JS build toolchain and steps are just plain old insane; and neither durable nor resilient. 4-6 month old code bases become antiquated vs a few years ago when you could expect 4-6 years max.
BTW, I'm pretty sure C had the same kind of explosion 30+ years ago... Obj-C started off as a set of macros in the late 80's/early 90's. But it wouldn't be proper JS engineering if a wheel wasn't reinvented along the way.
It utterly nuts how we are expected a learn a full-stack like Mongo/Angular/Backbone and then 6 months later is like NO we need AWS/React/Redux now!
It's my oldman opinion that IT has become too much like fashion and not enough like engineering, but that's what oldmen think so who cares.
Make a framework? Post it on github, go to a conference, write some blog posts, get your framework its own conference, ?, profit! (now I'm thinking of that Southpark guitar hero episode but with famo.us as Stan) There's incentive to put out new tools for the producers of those tools.
On the user side it's easier than ever to learn new tech and framework. I'm learning Clojure and in a few weeks I've asked at least five questions about libraries and frameworks on stackoverflow and slack that have been answered by the authors of those tools. It's 3am on a Tuesday/Wednesday and there are still people helping each other out all over the internet, writing how-to blogs, answering Stack questions. As an aside, for all the weird pathologies of this profession and our community I think that's pretty awesome.
My point is that even though the continuing learning burden might be volumetrically much larger, I'm not sure it's significantly more difficult.
I live under the assumption that you don't have to. The thing you should figure out is: finding a stack that suits your needs (and the needs of your customers) best. If you find it, is is perfectly reasonable to beeing a bit more conservative and stick with it. On the backend for example I used rails for years, and with good reason. I am not planning to switch, but I am open enough to consider my options and experiment with other stuff. I know there are (maybe pretty good) alternatives: enterprisey Java-frameworks; good old django; nodejs; experimental stuff with erlang or haskell.
I think the frontend/js-world is not so much different. You don't have to know every framework, because it is the latest hot shit... It is not wrong knowing the strenghts and weaknesses of new frameworks, but you don't have to use and adopt to everything thats new.
Your second example of AWS/React/Redux is also a little weird since AWS is a cloud platform and it offers around 50 or so products. You can run a CGI based web app programmed with Perl in EC2 if you wish, and you can do that as easily as 15 years ago if you learned it back then.
As a younger web developer sort of a guy, I'd say that the current situation is not something where you have to be learning a whole new set of tools every 6 months. You can still easily find a job if you know for example Angular 1.x, some CSS, and understand how to create a stateless JSON API using whatever language you are comfortable with. Betting on the strongest horses of the front end side has had you learn two different technologies (both in the same language) in the past four years, I'd say that's not too much asked. In the back end cloud platforms have really taken over, but it's not really that different from 15 years ago when people ran their own hardware. Linux is still the king, now you can just choose whether you want to be in 100% control of the infrastructure or actually make your life easier by purchasing a PaaS (e.g. heroku, beanstalk).
Most of the JS library tools seem to encourage keeping code outside of source control which is pure crazy. It might work tolerably for a evergreen SaaS application, but you still have way too common complaints from developers that they couldn't build because someone else's server was down (NPM has trouble weekly). What is even worse is the encouragement to use a library/font/etc that is hosted in a CDN so the uptime of the app is also dependent on the uptime of the CDN hosting the library.
Interesting. We deploy daily, always fresh from NPM at each deployment stage and have never had an issue with NPM. We had one legacy dependency downloading from github (ugh) which caused an issue the last time it went down, but we quickly sorted that out.
I'm not really familiar with any popular build toolchain libraries written for 5 that haven't been updated to work with 6. It's not like a Python 2/3 scenario, or even an Angular 1/2.
Ember is matured and production ready for years now. You can focus on your product. So, as an Emberjs dev never felt that problem than other js developers. Dont experiment, start using the best tool out on the market... no more crying only happiness. ;)
I'm using mithril.js right now for a side project, with basic ES5 and no build tools. Mithril has a tiny API but still offers surprising amounts of power.
I'm enjoying the simplicity of everything. It's been nice spending way less cognitive energy to understand how all the pieces fit together =) I may have to add some tooling in when I deploy the finished project, but I'm going to keep it as minimal as possible.
Yup, it doesn't make sense to keep chasing the perfect solution. Developers wouldn't be suffering from fatigue if they focused on "done is better than perfect".
I also do a lot of work in Angular and React (this year) and all the tooling, build, best practices change every couple of months.
A lot of people complain about Ember's learning curve, but the things you learn _stay relevant_. Personally I'd rather invest in that kind of knowledge than learning yet another arbitrary build system.
Today there is huge demand for the ability to develop desktop standard applications inside the browser. At some point in the last few years we hit a tipping point where the potential to do this was unleashed. I am not sure exactly what the technology was that tipped us over, maybe a combination of several. Was it fast JavaScript performance, AJAX, client side frameworks or NodeJS? Whatever the cause the dam has broken.
In a few years the winners will emerge. But it is impossible to know if the current leaders are going to win or if another champion will appear tomorrow.
I intend to enjoy the ride and look forward to the improved productivity and capability of web apps that results from the chaos.
It's not a knock, the younger people usually bring the enthusiasm and fresh ideas to the table- but that enthusiasm and zest hasn't been sobered with a decade of real world experience and a more analytical/engineering background and schooling.
Look at Windows desktop apps. If you wanted to make a native Windows desktop line of business app in 2000, you would use Win32 APIs. In 2002 or so, you were supposed to use WinForms. And then it was supposed to be WPF. And then Silverlight. And then WinRT.
We pretend to like it just because it's the only meal we get to eat if we don't want to starve.
> Today there is huge demand for the ability to develop
> desktop standard applications inside the browser.
> We talked again last night, and he said that he’d chosen RequireJS. By now, his company had built a massive codebase around it –- “I guess we bet on the wrong horse there.”
What makes RequireJS the wrong horse? Is it not doing what it was originally doing? Do you need more from it? How do you build 'a massive codebase' around a module spec? I'm guessing here the person thinks Webpack is the right horse - Webpack supports the AMD spec RequireJS uses if they felt the need to switch (which I can't see why you would), which would minimise whatever changes needed if you had the urge to 'churn'.
I think people need to stop getting so anxious about doing what all the 'cool kids' are doing.
So it's not so much about whether a given tech works for your project or not (being honest, server-side rendering + dash of jQuery is probably more than adequate for a lot of sites going full-on React+Redux right now) but fear of your skills becoming obsolete. Given the shit-show hiring is right now with its resume filtering and whiteboard hazing (witness every other week on HN) that's not an unfounded fear. So in order to have something on our resume that we used React in our last job, we use React for our current project...and so contribute to the problem.
I've always approached it as "if the DOM is too slow, I must be trying to do far too much. Scale it back and re-think the problem"
But you know what? My site works with IE8+. I can deploy code without much thought as to what is going to break. My deploy script takes 15 seconds. I don't have to rewrite anything every 3-6 months. I can update something that hasn't been touched in 2 years and it works exactly as expected.
I'll welcome all you bleeding edge javascript hippies back with open arms. But you have to use the side door. https://s-media-cache-ak0.pinimg.com/736x/f0/10/a3/f010a3aad...
It will still crumble in super complex interfaces though. Which in my experience don't pop up that often, and when they do it's only on one or two pages.
http://meta.stackoverflow.com/questions/308875/new-navigatio...
Disclaimer: I was one of the developers.
I've had to do a fair amount of complex UI and, frankly, I don't see why people stress so much about it. I rarely end up with more than a screen's worth of event handling code (which is a small amount of pasta, really), and things flow around fairly intuitively if you've any experience building non-web UIs
It feels like a lot of this language churn is purists reinventing the wheel. In previous comments I've ripped into specific aspects of this complaint, and an alarmingly large proportion of responses boil down to, "well, but I can't have feature XXXXXXXX or YYYYY with your stack! it's worthless!" XXXXXX is usually something like syntax highlighting, or intellisense, or some other triviality. Nobody EVER mentioned maintainability, or simplicity, or elegance, or any of these other, broader principles, without also providing a dissonant opinion.
Well you know what? I can write clean, performant, raw javascript and jQuery and I am damn proud of it. I don't need your stupid, always-changing tech. It sucks; I'm 31, but the only people I can relate to here are the old men. GOML, you kids are cray-cray
This is a factor taken for granted far, far too often.
I don't know the answer.
I've basically ignored the boom in the web ecosystem for 10 years and have even less interest in getting in to it than 10 years ago.
I'd be interested to know what the problem actually is, because I certainly don't want to have anything to do with the mess until someone comes up with something solid.
I ignore all of the .NET and C ecosystem and I have absolutely no interest in them for many reasons, but that's not saying much about anything. Just because you don't care about Javascript doesn't inherently make it's ecosystem so bad.
Wheat still grow on a seasonal base. Tourism is still yearly based. A car will last you years. telco CPE are lasting for years. Bank terminals are for years. Robots in factories last decades. Peacemakers are intended to last ages. Users do not really like to have their interface changed without any reasons to do simple tasks.
Browser ecosystem is just running amok in terms of speed diversity and complexity.
At the end, when we code it is for a business value. And for businesses web technologies are mostly expenses that grows faster and increase faster than economical growth. At one point this is condemning software business value in times of recession when people need to cut on costs to survive.
JS fast pace == a lot of manpower to keep application just up to date. It is a continuous growing bleed in the budget.
It is not the fatigue of the coder or sysadmins one should fear. But the fatigue of the business customers bored to pay for diminishing returns. Individual customers may still follow. But losing business customers will happen first.
Plus like it or not, updating browsers is not always as easy as you think it is. We all know of these legacy application that requires to keep a certain browser, and of new application requiring different one and the complexity of handling all these browsers. I used to have 6 browsers to code and test.
This is killing the business of coding and there is no "magic library" that will change the seasonality of the activity and the need for companies to keep their costs in control.
Industry out of IT requires for boring stable LTS technologies. The opposite of the offer of modern IT.
When offer does not meet demands ... company fail.
If ever USA or Europa, India, China announce a recession in 2016 or 2017 there will be blood in the IT.
It is all about costs and prices and making benefits at the end.
Or if you want language proper at some point node allowed keywords to be used as properies.
Given the way mozilla teams are still working I guess it can still happen.
EDIT and add the memory leaks and the change of performance that happens from time to time in new releases.
I was just working on getting a react-redux TODO template ready and number of things I had to read up on was enormous. https://github.com/rahulkmr/react-redux-todo
I had to read up on react, then on redux, then on es2015/babel, then on browsrify, then on gulp, then on eslint, then on sourcemaps, then on flow, then on react-router...It was a lot of effort, but I am liking it so far. The important thing is we can build applications in ES2015 which is a better language than the browser's js implementation and still get to debug it on the browser(sourcemap and specific devtools). My impressions of react-redux so far is it makes implementing a TODO list harder, but it will be better suited for applications with lot of state.
True there are conflicting choices and advice, but I think all this will stabilize in a year or two and despite the naysayers, the future seems bright. And it's not a take-it-or-leave-it deal - if you are happy with Backbone, keep using it. You can choose to just integrate gulp,babel and browserify for es2015 goodness. You might not like react but like how redux does state management - just integrate that in your existing application.
Most of the tools are orthogonal to your framework choice. Use tern for completion and analysis, use eslint for linting, use browerify/webpack to pack your assets...
You didn't 'have' to do any of these, especially for a project of this size. I can now understand why people might feel fatigued when they needlessly create overly complex solutions.
Where did I mention I had to do any of these for a project of this size(or any size), and since when TODO list is a project?
The purpose of the template is to prepare a template(duh) and understand how and where each library fits in.
I predict eventually we'll come full circle and get something like ASP.NET forms with Javascript controls that spans both frontend and backend.
What do you think?
I think that the core feature of JS and Lisp is the fact that there's no concept of "compile time". Declaring classes, methods, even entire language concepts like promises happens entirely in runtime, and the language is soft to touch that every programmer with a healthy dose of curiosity and love for his craft is trying to build his own OOP system on it at some time.
This softness allows for incredible freedom for a programmer, and incredible speed of development of the language. But freedom is dangerous, both when you work with code written by others (often idiots, either only in the eyes of maintainer or completely objectively) and when you just support your own codebase that you wrote several years prior. Would anyone expect anything else from language with such capabilities?
The first Lisp compiler was finished in 1960.
Naturally Lisp has the idea of 'compile-time'.
> Declaring classes, methods, even entire language concepts like promises happens entirely in runtime
Let's see. I have a file with these contents:
(defclass foo () (a b c))
(defmethod bar ((a foo) (b foo))
(+ (slot-value a 'a)
(slot-value b 'b)))
$ sbcl
This is SBCL , an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.
SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses. See the CREDITS and COPYING files in the
distribution for more information.
* (compile-file "compile-test.lisp")
; compiling file "compile-test.lisp" (written 16 MAR 2016 07:34:51 PM):
; compiling (DEFCLASS FOO ...)
; compiling (DEFMETHOD BAR ...)
; compile-test.fasl written
; compilation finished in 0:00:00.020
#P"compile-test.fasl"
NIL
NIL
Let's see if sbcl knows about the class:
* (find-class 'foo)
debugger invoked on a SIMPLE-ERROR:
There is no class named COMMON-LISP-USER::FOO.
Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.
restarts (invokable by number or by possibly-abbreviated name):
0: [ABORT] Exit debugger, returning to top level.
(SB-PCL::FIND-CLASS-FROM-CELL FOO NIL T)
0] 0
But we can load the generated machine code:
* (load "compile-test")
STYLE-WARNING: Implicitly creating new generic function COMMON-LISP-USER::BAR.
T
* (find-class 'foo)
#<STANDARD-CLASS FOO>
*
> Would anyone expect anything else from language with such capabilities?
Lisp has a lot of code bases which are large and maintained for 2 or more decades. Common Lisp has especially been designed to support compilation in various forms and to support the development of complex/large systems. One gets a lot of support from compilers like sbcl for doing so.
stackoverflow : jquery + anything else? map.google.com : ? facebook : ? React (?)
I don't think progress will stop at React. Soon enough, we will have drag-and-drop web app builders - They will allow us to build web apps where all data will be live-bound in realtime. Adding new pages/functionality will be trivial.
Software developers won't stop until the tools become so convenient that they take over our jobs completely - We will be replaced with app designers and entrepreneurs.
What reasons are you're dropping your old libraries/frameworks in favor of the new ones?
If an unstable API is a big problem for your use case, why not just stick with the old library or just not update the dependencies?
Also, when you check the project out and it was relying on global npm packages to build and the system you're working on has been updated in the last few months and now all of a sudden your grunt file doesn't run or your CSS minimizer complains about your Ruby version. God forbid you build multiple JS projects in one CI server!
ES6 is a new version of the language under discussion, Babel is a tool to allow you to compile code written in the new version into the old version. The other 4 examples are all closely related to each other, if you use JSX and FLUX you use React, if you use Redux you probably use React.
In other words while I believe fatigue exists and is probably warranted, these were bad examples of what would cause the fatigue.
Javascript fatigue is self inflicted.
1. ECMAScript is called that because Sun (now Oracle) owns the JavaScript trademark, not because anyone wanted to be diplomatic.
2. JavaScript language evolution was not primarily driven by the Firefox team. Mozilla didn't start until 1998, by which time pre-ES5 standards were mostly done. There was an effort called JS2, led by Waldemar Horwat (then of Netscape) which didn't result in a standard. Other SpiderMonkey JS extensions were mostly not adopted, or adopted in ES6 in heavily revised form.
3. The creation of the spec was driven in significant part by Microsoft, whose internal spec documents formed the initial basis for ES1.
4. The "harmony" name came entirely after the end of ES4.
5. None of the design of classes, modules, or other major ES6 features comes from ES4. Smaller features such as `let` were present in ES4, along with very different class systems, namespace systems, and other features.
6. Neither JScript versions nor Spidermonkey's JavaScript versions ever had a significant impact on JS on the web.
7. Unlike ES4, ES6 is backwards compatible. ES6->ES5 compilers are not needed to make it backwards compatible.
And to what end? What website have I gone to that just knocked my socks off because they used framework X or library Y. None. And one year from now they'll toss it out for whatever else catches their short attention spans.
So much wasted effort.
GWT came way before CoffeeScript, in 2006.
So then some high brand developer heads up a project, it gets a lot of attention because a big name company adopts it, and then we're off to the races.
Before you know it, our simple little dynamic prototypal SCRIPTING language has Classes and typing and build systems and cascading transpilers.
I'm not saying we should go back to the bad ol' days of writing kitchen sink code for MVCs a billion times, but why do we need Typescript, Flow, Babel, Dart, Coffeescript, and Clojurescript? Why?