Interesting how we can have so completely opposite experiences. I'm feeling like webdev is just finally geting a tiny bit sane. When I started doing it in '98 or so, it was horrible beyond description. Now, with ES6/7, Typescript, Less and Jade (and the Chrome dev tools), I can actually get some work done instead of fighting the browser at all time.
I would say LOL if only it wasn't so sad.
Edit:
> A SPA will lock you into a framework that has the shelf life of a hamster dump. When you think you need a SPA, just stop thinking.
Seriously? Backbone is super mature, but with a steady trickle of minor updates and fixes. And it isn't really a framework, just a small library.
There are plenty of great use cases for an SPA. A blog probably isn't one, but like with all technologies, part of your job is knowing when not to use it.
It's not just that web development was pretty complicated and terrible back in the day, it's also that web development hits so many more targets and platforms than it did 10 years ago: not just multiple web browsers, but multiple breakpoints and behaviors of those browsers based on the physical constraints of the device.
We should expect a rise in complexity if our ability to reach users has increased accordingly.
> Maybe 1 or 2 pages on your app will have really complex UI, but the other 95% of the app does not.
I guess I wish I had his problems. I work on an app where nearly every page has a complex UI, because it's a control panel for a domain with a lot of inherent complexity. Making manual DOM manipulation calls for every UI change would be a nightmare.
Exactly. For simple sites, I pretty much avoid all frameworks/libraries. However, I use babel/webpack though I really like webpack-dev-server and the full set of es6 features. I disagree with the React statement. I believe it's really simple on it's own. Flux/Redux add a lot of complexity, but confers significant gains. The new site I'm writing for work isn't just some stupid CRUD site - it's a complex UI used to monitor and manage industrial assets. Having the ability to organize long data flows and actions makes the code much easier to read and write, especially for other developers. If I had to manually manipulate the DOM (especially for making everything responsive) I'd go nuts. The thing about these tools are that once you learn them well, they save you a lot of time.
> There are plenty of great use cases for an SPA. A blog probably isn't one, but like with all technologies, part of your job is knowing when not to use it.
99% of the SPA's I've encountered in life had no business being SPAs.
The server side used to be sane. It was where your sanity was when the client side was ridiculous. Now it feels like server side is just a ridiculous as the client side used to be.
I guess that's true; I just finished building an SPA and the server code was saner -- but only because there was so much less of it. But overall the project is messier.
I must admit, I'm a relatively new developer, and I also get overwhelmed by the number of new technologies coming out every day. I can't speak for "back in the day" web development other than things I've heard from older devs. For example, "back in the day" browsers sucked, like really bad. Compatibility issues were expected. For example, "How do I make sure this is compatible with IE7," etc. Although web development is not perfect, nothing really is perfect, and I think we have come a long way. At least, I'm happy I got into web development when everything was so approachable, open source software is so accessible, and places like HN exist where I can constantly learn new shit.
I think the primary reason people are tired of new JS libraries is because there exists a certain kind of pressure that is hard to describe, but I will try. It's kind of like, "I don't want to miss out on the hottest framework"/"I don't want to fall behind current tech." The truth is, we should all ditch this mentality. Use what works for you and learn what you care about learning.
When a new JS library comes out, don't groan, take a quick peek and decide if it's worth it to try to integrate it into your workflow. I think it's great to have options and the options in web development are seemingly neverending. I'm happy I write software for the web, and I think we should all recognize how far things have come. Yet, we should always strive to make the web better for users and developers alike.
My biggest problem with all of the new libraries coming out is that it leaves me with the feeling that nobody want to improve upon what is already out there. I understand that paradigm shifts may require a rewrite. But nobody is shifting every 2 weeks and getting anything done.
When selecting technology, I want to make a decision that will grow with me over the next several years. When perception is that each library of the day will be thrown out in 3 months, falling back to jquery/php is a really attractive option.
This exactly. Sometimes I feel like an old fart still using Django (or Flask if the project is small) instead of some new hotness.
But Django has the DSF behind it moving point releases, bugfixes and major releases in a very sane way. The same absolutely cannot be said for angular (major rewrite in progress!) or a lot of similar projects in the Node.js community.
None of this means Node.js is bad, just that there is something to be said for consistency in development. Now watch as Python/Django devs slowly morph into what Delphi devs used to be ;)
You shouldn't feel like an "old fart" using Django or Flask. I think both are awesome, relevant, and will stick around into the future.
One of the great things about being a programmer is that we know how to program in general. If we have to adopt a new syntax or learn the intricacies of some new methods that's ok, and not nearly equal to the amount of effort we expended to learn how to write code in the beginning.
Keep writing your Django apps. I agree that it's great that DSF is backing a stable and productive framework like Django.
I was working the last year on a Django app. First I hated it, but slowly I started enjoying programming with it. This year I worked mantaining an app with all of this http://teropa.info/blog/2015/09/10/full-stack-redux-tutorial... This supposed to be a simple Web app but, it's a complete mess. I miss Django so much right now.
There are very few people that have the philosophy you describe. In the JS world, I think the Ember team has decided to do that. They have and are improving Ember with new technologies (virtual dom, server-side rendering) but it's still Ember and they take care of backwards compatibility (for the most part).
I'm glad to see another like minded person. I see the massive explosion of web dev tools, frameworks and libraries as a good thing. I think it's strong indicator that things have become approachable. It's easy to create something new and share it with the world.
I find the authors sentiment very similar to that of those who complain about "all of this terrible music." Music is much easier to create and distribute and that means more of it, which, IMHO, is a good thing.
Not even close, I can't tell you the last time I've wasted a day trying to get something to "seemingly" work in IE that worked in firefox. Sometimes fixing it in one place would break the other. It was a nightmare where I'd loose hours maybe once a week. I just don't have those problems anymore. Maybe its because I was a junior dev back when IE5 and IE6 was everywhere... but I lost a lot of time on it.
Perhaps I should clarify -- I am (happily) not involved in web development, and from the developer's side browsers may very well be in pretty good shape these days (I wouldn't really know).
But speaking purely as a user, I think the statement "browsers suck, like really bad" still holds very true.
All this Javascript machinery does so little. Most sites aren't implementing something like Google Earth, which needs heavy machinery to make it go. They're not implementing a multiplayer game in the browser. They're not using WebGL to display and edit 3D engineering drawings. 90% of web pages just display some static text and images with some forms and buttons, just like they did 10 years ago. There's a little more work required to deal with the screen size and form factor between desktop, laptop, tablet, and phone, but mostly it's basic content.
Yet the amount of code needed to do this has increased by huge amounts, and it churns constantly. Something is very wrong here.
The bad part of this is the disappearance of WYSIWYG editors for HTML. You weren't supposed to write this stuff by hand. That wasn't the plan. Tim Bernars-Lee's first browser had an editor. Mozilla had an editor. Microsoft had FrontPage. There used to be good open source editors. There was Nvu (dead)[1], and then Kompozer (abandoned)[2] Now, about the only thing left is Dreamweaver, which you now have to rent by the month. (Is BlueGriffon any good?) You didn't need a "content management system" unless you were constantly publishing new content, like a newspaper.
I've tried BlueGriffon a couple of times, and each time I gave up on it after pretty quickly. One problem was the need for various plugins, the most useful had to be purchased. I wasn't sure enough of the quality and hesitated to make the investment. Besides, documentation was pretty sparse about its UI features, which made it not so easy to use.
Interestingly, I was looking around the net recently for a simple web UI builder. Pickings were quite sparse, either online tools attached to some cloud provider, or elaborate proprietary systems way more than I needed. The ironic thing is that current "front-end tools" still require tediously writing out the UI whether in JSX, JsonML or whatever, pointing up where GUI tools would be most useful.
It's crossed my mind that writing a web UI generator in, say Tcl/Tk, would be possible and quite surprised no one has done it. ATM I don't have the time to pursue such a project, but a small GUI application to produce the "boilerplate" part of the code would be particularly helpful.
This is a great point. If you're running a small site with mostly static content, then you don't need all this dynamic stuff. Yes, it's fun to work with in, in a certain way, but it's like using a nuclear missile to swat a housefly.
Seems like a lot of people being a bit depressed that they're not working on a big problem and hence trying to make even the simplest websites into gigantic software development projects.
The point about WYSIWYG editors is interesting, though I suspect the complexity of generating decent HTML/CSS/Javascript/whatever is what originally killed them. That said, surely someone is able to figure out a decent system now, right? 2015 technology has to be at the point where a program can figure out how to code a (semantic, well coded) layout in CSS, right?
> The bad part of this is the disappearance of WYSIWYG editors for HTML. You weren't supposed to write this stuff by hand.
It really doesn't matter what you were "supposed" to do with HTML. It's become something entirely different than what was originally intended.
When Tim Berners-Lee was at CERN he really just needed a way to link research papers to one another when, for instance, one cited another. His creation of the 'Web' referred to a web of mostly static documents. Nothing like the interactive applications we have today.
The fact that no WYSIWYG editor can keep up with the latest front-end application design trends is no surprise. (Would you expect a WYSIWYG editor for your iOS app?)
As a back-end dev who recently took on creating an SPA for work, I ended up learning and using React/Redux/Babel/Webpack.
I pretty much hated every min of it, and there's a fair chance things will break if I update any of the deps, but I can't imagine getting something as organized and functional as I did with just jQuery, or even Knockout.
I have code broken up into organized modules (was never a fan of AMD/require.js), and truly re-usable components. The hot reloader renders my changes more often than not without a refresh. Production code is combined and minified into a single .js (no more downloading 15 different .js files). The feedback I have received from the business consistently mentions how fast and responsive the UI is.
Yes, the front-end JS scene kinda sucks, but I don't think I could go back to what it was 10 years ago and accomplish what I was able to in the course of a few months.
You can even render React components as views on the server in Express, I was shocked how easy it was having used both React as a SPA and Jade views in Express.
That seems like hands-down the best way to mix server rendered HTML with SPAs, especially if you have to support fallback to pure server rendering.
I'm surprised this surfaced on HN, which is usually crazily in love with all the 'innovative' new web technologies that keep popping up. Some of my favorite quotes from the article:
"You see the Node.js philosophy is to take the worst fucking language ever designed and put it on the server."
"That’s right. All you guys using React like it’s the only way to solve every problem ever are using it because Facebook couldn’t build a fucking notification icon."
"PostCSS - People actually use this thing. Can a library actually do shit out of the box anymore? I just want to install something and use it, not decide all the little plugins I want to use."
I don't think that javascript can be seriously described as "the worst...language ever designed". I don't think that anyone who has ever written any non-trivial program in AppleScript could agree with that, and I am sure that there are other languages that are, in their own way, unquestionably worse. For me, it set the tone for the article and greatly diminished the value of his observations. After that patently hyperbolic statement, everything he said had to be taken as a possible exaggeration. This is fine if one has direct experience with everything he mentions and just want to read a colleague rant about a frustration one shares, but it means that this blog post is not a useful document to anyone else.
I stopped keeping up to date with the latest "trendy" JavaScript frameworks when I realized it was tanking my productivity.
New JS libraries are coming out several times per year, and employers and engineers expect you to be familiar with them in order to get hired (e.x., we need React, Angular, Ember, Node and Meteor skills).
But what really happens, is when you have 12 months of time, and you need to know a new library / framework every three months you are burning something like four months of time per year just getting used to the new tech.
With RoR & AngularJS 1.5 I get a full-stack web application loaded with best practices that I can keep chugging away at building without ever worrying about what I need to hop onto next month.
This is what makes people frustrated: They feel the need to change their stack. In reality, what matters is that you ship good software. If you are comfortable with Rails and Angular like you are, there's no need to change your stack to Node and React. Sure, it may be beneficial to take a look at them just out of curiosity, but no one's forcing you to use them if you don't like them!
That's an excellent nutshell description of one mode of a productivity / technology trap that I've noted for quite some time.
I've been in and about technology since the late 1970s. There've been periods where it seemed that there were a large number of new technologies being promoted -- OLE, SOAP, and XML were several of the big ones, with a burst seeming to emerge just as the first dot-com bubble shattered. I still recall walking into a (now closed, of course) technical bookstore in a tech hub, and finding an O'Reilly title I hadn't seen before, with the blurb "The only book on $TECHNOLOGY_X you'll ever need". I did my standard scan: title page, contents, introduction, index.
I never got the least idea of what $TECHNOLOGY_X was.
That said, the blurb was accurate -- it was the only book I'd ever need, it only neglected to consider that I never needed it.
For young techies who happened to cut their teeth on a skillset that is widely adopted by the industry, the world is your oyster. Eventually, that skillset erodes or is abandoned. I watched that happen to mainframe and VMS programmers, to Perl hackers, to various all-inclusive toolkits aimed at what were once called "Open Systems" (apparently nobody wanted to say "Unix"). And many Microsoft technologies (though some have been surprisingly robust).
I'm watching it now with the set of Web technologies that have emerged post-2005. For many HN readers, Rails, Ajax, Angular, etc., are all you've ever known. For others, they're one more set of word-and-TLA-salad tossed out in front of us.
When I cared to do so, I'd learn the technologies in front of me, well, and try to keep an eye on what's coming down the pipe. But with tech half-lives measured in single-digit years, if not months, that's increasingly difficult. And frankly, the results are also increasingly difficult to deal with.
I see a recaptitulation coming, almost certainly with a vast simplification. I strongly suspect that someone's going to look up from Node.js-SOAP-COBOL one day and realise that they're accomplishing nothing Codd, Englebert, or Ritchie didn't pressage decades ago.
We'll get a simple document format. Probably based on HTML or LaTeX. We'll get an applications platform. Commerce will be standardised to a small set of apps, almost certainly growing out of iTunes, Amazon, Google Play, eBay, or Craigslist, or someone taking on one of their positions. Media will get its own dedicated standalone player.
And the titles "Web Designer" and "Web Applications Engineer" will be consigned to the same Schumpeterian scrap-heap of history as "stable boy". Perhaps retained for sentimental value by a small group of eccentric (although, by definition, fanatical) hobbyists. But otherwise rightly forgotten.
Medium appears to generate and append a unique tracking code onto each page load, you'll notice only one of those submitters was aware of it and stripped it off.
I bet Medium has a nice social graph of blogger and social share influencers based on this tracking, leveraging this might be the biggest value of their platform.
They add a phony fragment identifier to evade dupe checks -- a pretty pathetic way to augment traffic, unless there's a legit purpose for doing this that I'm not seeing (in all cases, there is no genuine corresponding fragment ID anywhere in the page).
One of the tricky things (I presume) about detecting Medium links is that they append a custom hashtag to the URL with each individual share, so that they can track the "path" of the sharing. So everyone who copies the Medium link from their browser will be pasting a new unique URL into the HN system. Maybe there should be a new rule written for the medium.com domain that strips the hashtag when determining if it has already been submitted?
Sticking random fragments in place to avoid dupe detection is a very common tactic. Intelligent dupe detectors should ignore fragments. However, people can also throw in random query string variables and it's impossible to tell if those substantially modify the content without visiting the page itself and comparing.
It's not impossible. You can just text match the first X characters of that URL segment and consider it a dupe at that point. I can live with the occasional false positive.
I wonder whether they shouldn't be stripped by default for everything. It seems like they're hacking what's supposed to be an in-document anchor, so it should be something HN can safely ignore. But that might be too simplistic.
I think it'd be easier to do on a case-by-case basis. It'd be too much to predict the effects of stripping out anchors across all sites, because some single-page apps still use that as a way to mark actual endpoints.
There are a handful of domains that are repeatedly submitted and have very predictable behavior...nytimes.com and medium.com. Everytime you go to an article URL at nytimes.com, at the minimum, `?r=0` is appended. As far as I can tell, every NYT article has a permalink in which query parameters have no effect to the end user. So writing a rule to strip out query params when testing for uniqueness would probably be of minimal harm.
Obviously such a rule would be terrible to apply for all domains...for starters, it would penalize all sites that use the `q=x` type param to query for unique pages, such as PHP bulletin boards.
- There are loads of options for the back-end – Rails if you're building something CRUDdy, Java if you're building something enterprise-y, Go if you're building a simple API, Node if you like Javascript… They're all suited to particular niches, and it's great.
- The front-end is getting much better. For quite a while we had nothing except mad DOM-twiddling, then we had jQuery (which helped to some extent), now we have better frameworks that work more effectively with the way we want to develop apps. And there are options there too – React can help to control view complexity, for example, or you can go right ahead and build a full SPA using Angular or Ember or whatever.
Now I'm no fan of using Node for a server app. Personal opinion is that there's no requirements that aren't fulfilled better by another language. And indeed, I'm often frustrated by the extent to which people develop SPAs for things that should be static sites - Blogger, I'm looking at you.
But you know what? I'd take this in a second over the buggy soup of untested PHP, incompatible browsers, Prototype.js, IE6 and so on from only six or seven years ago. It's so incomparably better in every way.
I had to do a survey of the modern web world for a greenfield project my company is working on, and I ended up with AngularJS 1.x and Rails. Angular is by far the easiest to get in to, has the most stable libraries, and is relatively well known at this point. I know Angular 2 is coming and that everyone has moved on to React, but it's been more than successful at giving us a stable stack to work around while also producing something that works great for our customers. If React is still around in 3 years and has mature libraries for everybody to use, then sure, I'll take a look. But for now, I think my strategy of being a few laps behind is working, at least anecdotally.
Quite honestly, if someone asks me for a technology for their backend, I'll ask if they need performance or flexibility. The answers will be Java if they want to be fast, or Ruby if they want to be flexible.
Those are not shiny new kids on the block, but they are understood, proven technologies.
why Java instead of... well, i guess there isn't a language w/ GC and an ecosystem as "mature" as Java.
with clojure, which is indeed shiny and new, some people have cake and eat it too: speed of the jvm + flexibility of scripting. i guess a samish sort of thing could be accomplished w/ jython+Java if clj is too flashy.
anywho, i hear the "don't go for the glamor," thing and indeed try (i.e. make a conscious effort) to lag 'teh new hotness' by some interval. ES5 strict is usually good enough. indeed, tail calls are the one coolest feat.s ES6 to me, and they're pretty much everywhere unimplemented, including Babel, except maybe for some special cases.
w/ Java... it's a language i wish would move toward vanishing -- or at least go one layer deeper than everyday application development. when i first started writing applets, it was the coolest thing ever: Sun was awesome, the same program ran everywhere, there was automagic memory management, etc... now, Oracle's laying down all kinds of noise a/b owning the language, there are other runs-everywhere platforms/methods (ES, LLVM), and the Java language itself just looks incredibly noisy unless one uses some of the really excellent (but wo/man-hour costly) tooling expressly designed for handling it.
Partially, because I've been burned too much by pythons packaging madness. But beyond that, there is a bunch of strong, mature tooling done in ruby. Rake as a task runner, Thor as a simple library for more complex tools, guard as a general nice-ness, if you wanna go there, the entire chef-stack.
And if your main application is in ruby, there's very little overhead to use these strong tools to make your entire infrastructure better for little additional education, build chains or further investment.
I love Angular 1 because I can be quite productive in it, and expect to keep on keeping on with the Angular 1 branch for years. I will not be jumping to 2 nor will I jet off to learn React.
Good to see others who have decided to keep on with what works.
I agree with the overall sentiment of the article. I've felt many times helpless trying to keep up with the the latest js framework or workflow (webpack, Babel, grunt, brunch, Backbone, Angular, etc). By the time I've gotten comfortable with some new piece of js software, a new one, even cooler had appeared.
And on top of it, add the fact that I also enjoy learning new programming languages for the backend, and the mental overload is definitely ensured.
Title didn't make sense to me until I clicked through to the article. Of course Node.js web dev sucks. It's an immature stack. If you'd just learned Rails your sanity would be much improved. But no, the siren's song of using the same language on client / server lulled you in, and now your life is a mess.
Don't make the same mistake he did. Use the mature tech that is designed for small teams to be maximally productive. Use Rails.
Last I've done frontend dev was 2012, now I am doing frontend for a new project and while it's gotten much better, it's very overwhelming.
I had to familiarize myself with react, es6, babel + plugin, scss, redux & its concepts, react-router, npm and its packages, material-ui, browsersync, eslint and that's just to get started. Now that's a lot.
By the time I am comfortable in that arena something new would have replaced them.
Seriously. This is a vile article with poisonous language that's little more than "kids these days" hyperbole.
It has never been a better time to be an (insert your preferred coding environment) programmer: if you're unhappy with the code you're writing, I'm certain you can find a company that offers what you want in no time. Finding a job that suits your demands is a better use of your time than whining on Medium.
That's not an accurate representation of the article at all. I don't think the author is suggesting that web development was nice overall in the past, but that it was nice in the sense that you didn't have to download >100mb of tooling, learn each of those tools and their various plugins, configure said tooling because out of the box they are useless, and endure 10+ second initial compile times, learn dozen of different libraries and frameworks, just to get a simple webapp working, where, 90% of the time, static, or server generated content would have sufficed.
Does anyone else get a kick out of reading stuff like this, where people bitch about how much they hate JavaScript? I get a weird sense of enjoyment out of that, I love JS and so it feels like opportunity to me. I can certainly understand things that people don't like about Node, but if you think JS was the worst language ever designed then you're probably never going to like web development no matter what.
I don't understand disliking npm though, I think npm is pretty great. Every time I spend a bunch of time wresting with pip, coming back to npm is like taking a warm bath.
npm is quite possibly the worst package manager I've ever seen. It encourages unfathomably large dependency trees, using multiple versions of the same damn thing in the same software, duplicates things like crazy in the nasty tree structure that is the .node_modules directory, and cannot reasonably handle the full dependency tree of anything non-trivial that uses native extensions. I really don't understand what people find to like in npm. It's fundamentally broken.
You seem to be out of date. npm 3 uses a flat directory structure, only nesting dependencies when there are two different versions.
That misinformation aside, all package managers are agnostic about how large your dependency tree is; the large trees are purely a consequence (or choice, depending on your outlook) of the community. Could you imagine a package manager telling you you're using too many or too few dependencies? If you want fewer dependencies, use fewer dependencies. npm won't get in your way.
Speaking of the community, it is primarily what people like about node and npm. Sure, there are lots of bad packages. That's a side effect of javascript being the lingua franca of the web. Everyone and their grandmother is writing npm packages, so of course there are going to be a lot of bad ones. _But there are also a lot of good ones._ npm has driven web development forward at such a fast pace, I wonder how anyone can't appreciate what it's done.
Finally, some stats: ~230,000 packages, ~3,300,000,000 package downloads last month. That is a lot of users for something fundamentally broken. I can only wish to work on such "broken" software.
I agree npm criticisms are more about the way packages are bundled than the manager itself.
To your last point, the javascript ecosystem can have a lot of users and be "broken" at the same time. I think that is a large reason why people hop around to new libraries so much.
"Well what I have now sucks, maybe this new thing will work better. (2 days pass) Nope! What else do you have for me this week?"
Yeah, npm is fine. I understand the React vitriol to a point, but npm "just works" more than pretty much any other package manager I've used, and especially more than pip.
Front-End Development really does suck, and I think that can be backed up by productivity science. I think the problem is that the web was never intended to become what it is today. It was meant for making documents with hyperlinks — that's It.
It's unsurprising that using a technology for something it was never meant for is problematic.
Webdev has always been shit. Anybody remember xhtml? From the very beginning, everything the w3 standards body touches has been a design by committee nightmare. The latest generation is just more of the same.
That said, it's not going anywhere anytime soon. "Because it makes lives easier for developers" is not a valid reason for most end users to change their habits.
Personally, I'm banking on better tooling. Most single page webapps today are just more complicated versions of fancy UX on top of an excel spreadsheet. So why are there no graphical design tools that let you visually set up the application, visually see where the data comes from and where it goes and then spits out html, css and react code? The state of the art in code generation has come a long way since dreamweaver.
This is an extremely vitriolic piece that it seems should have been titled "The Sad State of Node and React. I have never used React, but got married to Angular a few years ago, which I'm guessing is basically the same? Either way, these are all choices that you have. I've never used node on the backend or the frontend. As is mentioned in the article, you can still fire up a text editor, write some html and CSS and have perfectly good website. Tools that are used beyond that are all developers' choice.
Its the eternal battle between leanness and bureaucracy, the later always stealthy infiltrating to unfold its corrupting influence. Then its up to the mature developer to pick the proper technologies for the job based not on fads but on real project needs and wise criteria.
Not everything coming from SPAs is bad; reactive programming is awesome when you implement it in your own lean way with small friendly libraries like ractive, blaze, etc.
> 2015 is when web development went to shit. Web development used to be nice. You could fire up a text editor and start creating JS and CSS files. You can absolutely still do this. That has not changed. So yes, everything I’m about to say can be invalidated by saying that.
Whether you find the recent frameworks to be blessings that bring sanity to web development, or a over-engineered pile of chaos seems to be a religious argument, mostly based on if you have already gotten used to not having frameworks for the last 20 years.
This pretty much sums the intellectual depth and research of this rant:
> From what I can tell the background of React is: Facebook couldn’t create a notification indicator on Facebook.com, so they create this over engineered dump pile to solve that problem...That’s right. All you guys using React like it’s the only way to solve every problem ever are using it because Facebook couldn’t build a fucking notification icon.
You can make very nice applications with the same LAMP stack that's worked since 2002 or so. All these modern frameworks are just a huge time-waste in my opinion. You don't need 20 libraries to make an XMLHttpRequest.
This works for small projects or sites (or if you want to ensure job security). But if you want to make something more complex, many of these JS frameworks can really increase productivity.
Ember.js, for example, has all kinds of nice buffering features, so you aren't making multiple un-needed ajax calls back to your server.
You will also end up needing to re-invent the wheel if you make anything complex.
https://news.ycombinator.com/item?id=10880604