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.
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 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.
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/ )
People need to realize there's never been a platform like the web in terms of portability and accessibility. Comparing the web to GUI toolkits is like saying that comparing Linux desktops to Mac OS X—Linux environments can never have the polish of OS X because Apple controls the entire stack. Similarly, a GUI toolkit can only be as cross-platform as the vendor makes (which is historically pretty terrible for all cross-platform GUI toolkits). The web is not only a standard, but a standard whose implementation is the price of entry for all new devices.
Furthermore, everyone complaining about the web's shortcomings doesn't have the whole picture—in fact the most difficult thing about a standard of this size is that no single individual or organization has the whole picture of what the standard supports. Sure the web was designed for simple documents and evolved into something for which it was never intended, why is this a bad thing? The fact is that you can never replace the web because A) there is no human power great enough to force adoption, it can only happen by serendipity (just like the web) and B) by the time you were done you would have a whole different set of warts that everyone would complain about. People would do well to remember Gall's Law before condemning web-as-app-platform.
Would everyone is discussing the high quality of the Emperor's new clothes, is it productive to point out that he is, in fact, naked as a jaybird?
> 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.
That's the logical fallacy known as argumentum ad populum, i.e. arguing that because something is popular is is correct.
It is aggressively contemptuous because the current web stack deserves contempt. That is 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.
No, it's more like complaining that each of the interesting people is wearing a blindfold, earmuffs & a gag, with a hobble to prevent him from getting within arm's reach of anyone else and can communicate only by reaching out with a stick or probe and tapping out Morse code messages on other's arms. Sure, all those impressive people are doing a bang-up job of overcoming the absurd limitations of the insane party, but that doesn't make the party one bit less insane.
Being unable to have a conversation about the ecosystem because the language isn't to your liking or preferences speaks to me of a closed-off mindset, which as everyone knows is a great trait for programmers to have /s.
"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."
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 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.
But the problem is nobody stays with anything long enough in the web world to learn it well. 5 years ago, Backbone, Then Knockout. Then Angular. Then Ember. Now React.
Seriously, a dev with 5 years of experience in JS has literally the same 1 year of experience over and over now.
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.
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-...
And to be completely honest, probably sacrificing a bit karma. All of your examples enforce my point of view on JS as a 'use it as minimal as necessary' language else avoid it.
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, 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).
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.
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*
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'm not convinced we found the only developers who like React, but it does seem like there's a certain audience of people (which overlaps heavily with HN) who love to complain about their self-inflicted anxiety.
Great, a real data point! From this and previous comments, I'm guessing the library was React? And from another comment on this page, you haven't bolted-on multiple libraries for form handling, routing etc.
A few questions:
* What is the projected lifetime of the new project?
* Will the code be updated continuously (vs write once & freeze)?
* What does your ecosystem around React look like?
* What library/framework were you using before which you replaced with React?
* Have yoiu committed to using React on new projects for the next.. 24 months?
AFAICT no one in this thread is saying they don't like React, or if $Company paid them to learn it they wouldn't (paid learning time, what's not to love?). It's about the pace of change, reinvention, and expectation to use latest and greatest and be future-proof.
You can have the "cutting edge" features or libraries, or you can stay a bit behind and have one that's stable and will stick around for a while.
People are using features of JS that aren't even in the spec yet then getting burnt out when they break in the future? Using a library at version 0.0.3 and getting upset when 2.4.3 breaks something?
Coding since the 80's in all types of stacks, frontend, backend, native, web, you name it. Whatever the projects require.
Nowadays doing native development just feels relaxing compared to the chaos of web based frontends.
The worst issue for me is how unfocused the efforts are. I experienced issues at a large media company where new features to the public site to improve user experience where delayed for entire sprints because someone in the team became obsessed with the notion that their env was wrong because they were using grunt instead of gulp, or they used a particular Sass processor that relied on Ruby and they could use one that was pure JS.
I quite like writing JS and have done on and off for over 17 years, I just don't understand the constant and wilful reinvention and fragmentation in front end development.
Would you blame the language C++ if the developer was constantly compiling their own compiler from master every single day and spending hours upon hours dealing with that?
I don't really get your point though. Are suggesting that JS fragments and reinvents itself outside of the will of the general populace of frontend developers? How else could the problems in frontend dev arise if not from the culture created by the people?
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.
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.
Please do. I am interested in seeing more detail in your post.
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.
Then when you have all these little libraries, you've got to go down the bundling path (and navigate the bewildering array of almost but not quite the same tools), because making 47 HTTP GETs to grab < 1KB JS files is slow. Theoretically, some of those might be cached, but the churn-rate means that virtually no one will have the exact version of a library that you require pre-cached in their browser.
In short: "bundling" is just JS catching up to how software was deployed for ages. Source maps are equivalent to leaving debugging symbols in the binary, only without performance costs.
I think you are mistaking the language with the browser.
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
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.
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.
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.
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.
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
Everything points into the opposite direction, unfortunately.
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.
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.
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.
This is a factor taken for granted far, far too often.
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.
I've seen some designs that were, frankly, beautiful but it took no more than 5 seconds to highlight the 30 areas that were going to cause massive budget overruns trying to make look exactly right, have decent performance, and work in eleventybillion browsers.
I've certainly appreciated what interesting designers can bring to the table, but we're still a ways away from a lot of traditional designers having a good handle of what their design really means when we're building it. Kind of like the contractor who bitches about the architect for designing an angle that is impossible to hammer into. Sometimes there is a disconnect.
It's a clusterfuck of the sublime and the downright stupid. Any new trendy idea has been rammed in to the new ASP.Net with startlingly high churn for a MS product and bizarre choices like forcing you to program in particular (often undesirable overkill) ways.
So the JS churn model has begun to infect another language as a model to be emulated rather than reviled.
There are great bits, don't get me wrong, but I do wonder how much of their larger audience are actually going to enjoy this. It presently feels like a massive step back for very little gain.
It just feels, looks and smells like the old JavaFactoryHammerWidgetFactoryFactory of the days of old, i.e. over-engineering which means you can't get any actual functionality done as there's more scaffolding than functional code. You end up drowning in utterly useless code that doesn't really do anything.
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.
And it's worth noting that in this case we're talking about a single entity - Microsoft - pushing these changes. In the JS-land, there are many more actors, and every one of them tries to be innovative: this has to result in a lot of changes over relatively short time.
Nothing wrong with it, too. I think that, over time, the ecosystem will converge on a couple of best solutions and that it will be of higher quality exactly because of a "chaos" we're seeing right now.
Then application developers will refer to "jasmin-1.0/jquery" instead of random version jquery. Developer will know, than this version will be supported at 3 years least, with bug fixes only, so he will not worry about incompatible changes in libraries and it dependencies for next X years.
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.
On the negative side for the consumer, the software and whatever data you committed to it will disappear if the company ever decides to stop supporting it or shuts down.
Also you are pretty much forced to be online in order to use it, so if your device isn't in a wifi friendly area and/or you're trying to limit your internet usage for whatever reason (i.e. more productive with less distractions), the software is useless.
And that's a lot easier to lose and a lot less portable than all the stuff I care about in a single folder that I sync with an external hard drive, a usb drive, and dropbox, automatically.
But it's still better than nothing, and I'm glad it's an option now.
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.
7. Unlike ES4, ES6 is backwards compatible. ES6->ES5 compilers are not needed to make it backwards compatible.
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.
Yes, but those developers are not doing front end web development for a living.
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).
Yes yes, I know :)
I played a bit too fast and loose with that particular example but it was late and it was more to make a rather hurried point then to actually engineer a production stack.
But facts are facts, so I appreciate the correction.
For other languages/ecosystems I would agree. However, in the JS world there is a lot of stuff that exists simply to exist. There are typically multiple libraries to do the same thing (in general) but with someone else's opinionated take on it.
Sometimes I feel like the developer of framework B was having a hard time grokking framework A and just decided to roll their own, like framework A, except for the parts they didn't like or understand. Then someone came along and realized that framework B had gaping security issues and was horrifically slow- so they created framework C which is the more secure and performant opiniated take on framework B that was an opinionated take on framework A. But then after four long months the devs behind C no longer maintain it because they've moved on to WebAssembly so a team spins off a fork of C in Coffeescript.
In a lot of other communities they would've just evolved framework A, or C would've pushed some patches back to B. Or D would've taken over for C and there would've been a handoff.
It's effing ridiculous that if I go back to a 5 month old project I will spend all damn day getting a build from source to work.
It's not just the libraries and packages. It's the toolchain, the build pipeline (heaven forbid you look like a grandpa and still use Grunt!), the transpilers. I love that people are creating cool shit all the time, but it really seems like if the code didn't come from their team, they're going to iterate the idea and put out a competing package instead of contributing back to the original. And then we wind up with two unmaintained projects 6 months later...
It really feels like there aren't many people (at least making headlines) that have had to maintain an actual live production system for more than a year or two. It'll be interesting to see what these people are doing 5 years down the road...
Not worth spending energy in worthless battles using tech that might be dead tomorrow.
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.
I was just working on getting a react-redux TODO template ready and number of things I had to read up on was enormous.
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.
> 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.
Don't learn anything else - just learn plain vanilla-React. The site has a onepager.html 'blueprint' to work from.
If people are getting anxious about this, its more than likely self-inflicted from trying to learn 30 things at once that you don't need.
But let's say I did learn all that (in fact, I did recently for a personal side project). It doesn't matter a bit for applying for a job. Why? Because I don't have real work experience using these things. So in order to have that, I have to somehow leverage React into my current job so it can go into my resume.
Sure it does! When I interview people, I tend to give a fair amount of weight in their side projects, because it's something they were actually interested in.
But that's not standard industry practice. Nobody looks at your Github - except maybe at the final stages of the process. In the meantime you have to get through a lot of filters.
My resume has a link to my github and I specifically call out 3 or 4 projects. If you want your side projects to count in an interview, that's probably a good place to start - if nothing else, you can at least use them for buzzword bingo to get past HR ;)
We just built and released a Very Big Project using React, Redux, and React-Router. Smooth sailing. Zero JS-Churn. No one had any issues being overwhelmed. We never went crazy and threw in every hot new library we heard about on Twitter.
And, as I said, it matters not whether I learned these things on my own: to Get the Job you need to demonstrate real-world experience.
Like, it would be a huge plus from a candidate if they even knew the name GraphQL/Relay, but I wouldn't want to work somewhere that expected me to know it completely.
It's also just got a lot faster (3.4 had huge speedups) supports HTML5 components and supports IE back to 7 (while that's not a requirement for me it's nice to know the tools you have will work if you need them to).
There are features in newer libraries I like but taken in balance I like been able to grab the code I wrote 2 years ago and have it still work with knockout's latest version, to me that is it's killer feature.
Also there is this http://knockoutjs.com/spec/runner.html
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"
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.
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.
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 recently ported a larger Qt 4 application to Qt 5. It took one or two hours. (Qt 4 was introduced in 2005.)
Not if you care about performance (to name one tricky aspect). It's all too easy to write a slow app.
very few cases excluded (e.g. scrolling issues on Android of old) it's nothing but a case of bad developers not having a clue. their code will be slow regardless of the framework because they use the wrong data structure, or render on the wrong step. simple as that.
then changing framework means dropping several features until they are ported, which means less code, which means faster code... until all features are back in. then, rinse, apply framework du jour, repeat.
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.
Then after almost 10 year being busy with server side coding and native UIs, got back to it in around 2009.
Eventually got back to native UIs in 2013. Really happy to be back in native UI land.
It is just plain chaotic the tools aren't up to the tooling level we had already in the 90's with RAD languages like VB, Delphi and C++ Builder.
Also having to worry about the build tool of the day is just crazy (npm + bower + yeoman + whatever else is required).
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)))
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
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)
But we can load the generated machine code:
* (load "compile-test")
STYLE-WARNING: Implicitly creating new generic function COMMON-LISP-USER::BAR.
* (find-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 (?)
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.
I have been using these kinds of FrankeinJS in the past.
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 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!
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?
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.
What do you think?