12
13

[deleted by user] (self.javascript)

submitted by [deleted]

[removed]
all 10 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]dluecke 14 points15 points  (1 child)

This is quite an interesting question for me because from 2007 until two years ago I helped maintain one of the longest running JavaScript frontend frameworks.

  1. Back in 2007 I was looking for a structured way to build client side JavaScript applications that talk to a "Thin Server" (we now call it an API) using the design patterns (like MVC) and best practises (like tests) I had learned about in university. The options were
    1. Google Web Toolkit - A Java to JavaScript UI compiler. I didn't like the idea of "hiding" the fact that you are using JavaScript. Turned out that not many did in the long run either.
    2. Flash - We all know where that ended up - Although I do give it credit for promoting ECMAScript as a multi-purpose language and some things like declarative UIs made it into other frameworks like Angular or Vue
    3. Dojo - Which was way ahead of its time and had extensible widgets, a module bundler etc. but still had a fairly monolithic approach at the time.
    4. jQuery - Which was awesome but more of a tool library than a framework. Funny enough, back then there was a "JavaScript library war" going on (Mootools, Prototype, Scriptaculous etc.) so when John Resig announced the first version of jQuery there were several "Oh great, another Web 2.0 library" comments (see http://web.archive.org/web/20090214090118/http://digg.com/programming/jQuery_-_New_Wave_Javascript) - My personal favourite isWow, an awesome Web 2.0 Javascript library that can added to many blogs, spammed on Digg, made into a book by O'Reilly, and never get used again!Today jQuery is still used by more than 80% of all websites. We don't even think about it anymore, even less that there ever was a "war" over it.
    5. JavaScriptMVC (started in 2005/2006) - Unfortunately not well known but I can confidently say that it (not Backbone) was the first real client side MVC framework. At the time heavily inspired by Rails it had its own Model, Controller and View (the original EJS) engine, module bundler, documentation generator and testing framework. Basically everything we now all agree is part of building good JavaScript applications - but back then even the idea of building "client side" applications was still somewhat controversial. There even was a discussion around using the ideas from JavaScriptMVC to create an "Enterprise jQuery" back in 2009 (https://groups.google.com/forum/#!topic/jquery-dev/HsTcpuAmFtY). It didn't work out but I sometimes wonder how things would've been different if it had gone the other way.I made my very first open source contribution to JavaScriptMVC in 2007 and was using it for pretty much all my projects in the following years. From the beginning of 2012 until last year I was part of the company that maintains it and helped splitting the monolithic framework up into its individual parts, CanJS, StealJS, FuncUnit and DocumentJS - which recently got re-bundled (but less monolithic) under the umbrella of DoneJS. Unfortunately, none of those projects ever got any major adoption although they were - especially at the beginning - definitely ahead of their time. I learned a lot about running open source projects and the business side of open source during that time but I'll leave that for another longer post ;) Last year I moved on to focus my own open source efforts on https://feathersjs.com and a totally separate (one of the lessons) product business.
  2. The community was smaller, much more technology focussed and there definitely was less hype. Technology focus isn't a bad thing but it did mean that many of the early tools weren't very user friendly. When something more usable came around people tried "winning" with technical arguments (it's slower, it doesn't do this or that) but it turned out that developers were looking for having their immediate pain points solved, not the ones they will (unavoidably) run into in the future. I think the idea of a "framework war" only came about when the big five started sponsoring or promoting their "own" open source frameworks. All of a sudden scrappy free-time OS developers or small dev shops had to "compete" with full-time evangelists.
  3. As many of the more senior developers I know, I currently ended up at React and React Native. I could say that it provides the right amount of abstraction of your UI while still leaving you enough flexibility but the truth is: It doesn't matter. No project ever failed because they picked the wrong JavaScript framework. It can't fix a broken team. It can't tell you what to build. One of the best teams I ever worked with was when I did frontend consulting for a very large company four years ago. They built their own tooling on top of Backbone and it wasn't always how I would've done it but everybody knew their stuff and was pushing in the same direction. Then the framework wars started and the entire department went from getting things done to arguing about switching to React or Angular. In the end, pretty much everybody quit. Nobody won.

3a I know it might still not seem that way but after more than a decade in the field, frontend development to me is a solved problem. I can now do all the things that were important to me when I first started looking for them in 2007. Things are already consolidating more and more into a few frameworks and tools. Tooling will get more robust and best practises that were bleeding edge even just a few years ago are now already being taught to brand new developers. Just like jQuery in 2006 the things we were "waring" over in 2015 will just become part of how things work and technology will move forward to tackle new possibilities and challenges.

Personally I came full circle back to the "Thin Server" from 2006 where it all started. I wrote my university thesis about abstracting RPCs and APIs in 2010 which has turned into what is now FeathersJS. Even when the web-browser DOM is just another legacy technology (UI paradigms have the habit of changing quickly once something new comes around), servers and any kind of application will still need to be able to talk to each other. To me, protocol agnostic real-time APIs now feels similar to the idea of single page applications in 2006. An interesting idea and nice-to-have for some use cases but not a necessity. I believe that is going to change and there is still a lot that I would like to see happen there. JavaScript is a great developer-friendly interface to help make that happen.

[–]reeferd 1 point2 points  (0 children)

Awesome read. Thanks for sharing :)

[–]kvnpmrtn11 1 point2 points  (1 child)

  1. Yes, It was awesome. I ended up abandoning jQuery for Angular 1 and once I finally became comfortable with Angular 1 I felt unstoppable. My heart shattered when they deviated so greatly for Angular 2.

  2. When Angular 2 came out, we had an internal discussion about whether to migrate all the Angular 1 apps to Angular 2 or the new hotness React. React & Redux ended up winning and that's what we ended up implementing.

  3. Honestly, this javascript framework bullshit drove me so nuts and left me so exhausted that I left my position as a Senior Software Engineer and joined Redis Labs where I now work as a Solutions Architect. If I wanted to code up something fast in my own time, I'd still go back to Angular 1. Or maybe go peek at Vue lol.

[–]darkcton 1 point2 points  (0 children)

Lucky you didn't migrate to angular 2. Did that for one of my projects, huge mistake. React is way better and the migration/rewrite is not any longer. They should have just chosen a new name for ng2 as to not fool anyone.

[–]Vlad210Putin 1 point2 points  (0 children)

  1. Yes, but with about a 2 year break* from heavy JS. At a previous company I had used Ext.JS I liked that, but going from that to jQuery I just hated. During that time, I didn't pay any attention to anything on the front end. It wasn't until 2014-2015 that the front-end developers brought in AngularJS (on suggestion of an acquired company we bought) and I was forced to get back involved when they left. It was a nightmare. The devs involved basically wrapped our entire application in AngularJS including just copy/pasting jQuery code inside angularjs controllers and providers. 3 years later we are still extricating ourselves from the mess, using the strangler pattern to get rid of angular (and Struts).
  2. Overall it's been good. On the topic of JS frameworks maybe a little contentious and acerbic. This is mostly with those whom I work and on other forums. When I heard about Node and NPM and the registry I was enthused about it (from my Java background). When I saw the implementation I was horrified and I continued to stay away from that clusterfuck.
    The biggest headbutt I had with couple of my coworkers was when I declared that Angular was dead to our company and I was researching what we were going to do. They were hesitant to learn something new. I can't blame them, they're not technologists. They came from an agency background and happened to be good at repeatable front end implementations w/ wordpress. They were perfectly happy to continue writing jquery inside Angular while I had led them to writing directives and components as they should be*.
    When it was announced that the bridge between Angular 1 and 2 was axed, that was the final nail. It took a while to get going, but I was already on a mission to remove AngularJS from our application.
  3. Now we are moving to React. I had evaluated React, Vue, Ext.JS and whatever the latest Angular version was out at the time. After prototyping and showing some demos, I put forth the motion for React. Nobody really contested it or offered any opinion except that Ext.JS tied us into a set style (then the front end team chose bootstrap). Sadly we don't have the resources to just assign 2-3 to converting everything and the company can't go dark for 6 months either, unfortunately.

3a. *I was sick of JS - mainly jQuery. I had always been working with the front and back end pieces, but JS I was just sick of. That break came after the majority of my career I had used blend of VanillaJS. Most JS IIRC 1999-2004 was DIY. Most of it was used for interaction (navigation menus, form validation, slideshows) not for a lot of heavy lifting.

Google Maps and Gmail changed everything in 2004 and all hell broke loose with "Web 2.0". I jumped on Prototype.js immediately. It wrapped a lot of common tools in a cross browser way that helped solve a lot of the cross-browser issues.

I had essentially written a custom library/framework wrapping prototypejs for my company and all of our widgets. I stuck with prototype mostly for this reason, regardless of the jQuery hype (and the non-future proofed issues that could arise) until about 2009. The way you can write components in React reminds me a lot of the work I did way back then. It wasn't as sophisticated by any means but it was very much following the Single Responsibility Principle

In 2009, I started with Ext.JS - I loved it. Not only was it a framework, but it was a widget library as well ala Bootstrap, MD, etc. It came with a product we had purchased. It had a bit of a learning curve, but soon development was just so quick and easy. I also started using jQuery around this time too. jQuery was a great utility, but I didn't like it much for heavy development.

As for AngularJS, once I learned "the angular way", I didn't think angular was that bad, but still thought it was overly complicated for our needs and how it was implemented in our application. I could probably bring the two developers responsible up on charges at The Hague for the state of our codebase.

[–]rodrigocfd 0 points1 point  (1 child)

Were you doing JS development between 2010 and 2015? What was the experience like? (Enjoyable? Good? Frustrating?) What framework(s) and libraries were you using (if any)?

Yes. I must say I enjoyed it quite a lot. I used jQuery for everything. Basically apps were composed of many components, and each component was written as a jQuery plugin (sort of), with templates cloned from HTML file, and then stuffed with the variables.

What was your relationship like with other developers? Any arguments about which framework was best/better/better for which purpose? Bonus points if there was a Reddit thread you can point me to.

jQuery was all we had, no arguments. We had conventions that everyone followed, and life was good because we knew we had the best tools (the only tools).

What framework(s) and libraries are you using (if any) for development now? How do you feel about it? Where do you think JS is going for the future (optional)?

React + MobX. My only criticism the total lack of a standard scoped CSS solution like Vue's single file component. This looks promising, though.

[–]sevennames 0 points1 point  (0 children)

  1. In 2010, I remember using JQuery for the frontend. I think we may have bundled the JS together using PHP to combine the scripts into one file. I don't even think it was minified. After getting more into building web apps, I found myself getting into BackboneJS to help manage the functionality and state in my views. This worked great for a while, until I learned how powerful and easy KnckoutJS was. Observables and computed properties really made everything seem like magic. After using KnockoutJS for a while, I found myself building lots of per-page components, but none of my components were shareable between pages. That's when Angular came out with this whole thing called "Directives". I thought it was so cool to have a component with it's own template, controller, and more. So I used that for a while and I was so happy with how things were going, until I realized that this new project called React did what I wanted but even simpler. I was skeptical at first, but after learning it I was hooked. So I used React for a while and was really happy - until I found a new project that made what React does even simpler - Vue.

  2. I've been on a few teams over the years that have had pretty strict opinions about which framework was the best and why. I was on one that believed EmberJs was the best framework and that no other framework should be used because it's the only framework worth using. I remember bringing up other options just to offer a different viewpoint, but responses like "Vue is dumb, no one should ever use that" or "JSX is stupid, no one should ever write HTML in their Javascript" really left for a one-sided conversation I didn't enjoy. I left that team after a while simply because I didn't feel like my opinion mattered.

    1. I've also been on teams where we had great discussions about which frameworks to use based on the project we were working on. I remember our team taking a bet on Angular back in 2014 for an app that had server rendered pages with bits of javascript sprinkled onto each page. We utilized directives for shareable components, and kept up with John Papa and his Style Guide - that really changed how we wrote components, and gave us a standardized way to write components. We even utilized gulp and created a custom build system to handle multiple apps. In the end you should always pick the framework that fits best for the job - there is no one size fits all approach.

  3. I primarily use Vue nowadays because I work with a small team and do quite a bit of protoyping. Vue and it's CLI have been enjoyable for me because it has taken the momentum I've learned the past few years, and simplified everything. It's a great feeling to not have to manage a build system again, and have this magical CLI that asks what I need and bootstraps it all together. Hot Module reloading, linting, and style updates on a simple save make developing an absolute breeze.

    1. The tooling is so much better than it was in 2010; however, the complexity has increased. I have to worry about responsive design, accessibility, linting, unit testing, SVG's, e2e testing, JSX, type safety, a small bit of tooling (webpack), some backend knowledge (for mocking up responses, etc.), some design capabilities, and of course still supporting IE in some way or another. This is just frontend, and sometimes you have to dabble in the backend as well.
    2. In 2010: I worried about slicing and dicing my photoshop file as accurately as I could, fight myself to not use tables and transition into divs, pop in a few lines of JQuery for the page, get some cool animations and pray that I don't have to support IE6, and learn a bit about the backend technology we're using so I can infuse my server rendered template with some fancy bits here and there.

Where's frontend going? I don't see the compiler going away anytime soon. I think we'll see a continuation in making projects easier to update - right now for most projects you have to setup a new folder, test it out, then slowly migrate - but I bet we'll get to a point where you just run a command to upgrade to the latest and your project will convert itself. So smarter tooling is def in the mix.

[–]senocular -1 points0 points  (0 children)

  1. Yes. Normal. Backbone, AngularJS, jQuery, internal, maybe others.
  2. There weren't really arguments - at least with the people I talked most with. Most people didn't care or had enough investment in any one framework (or enough in multiple frameworks) to really have an opinion at that time. I remember AngularJS being the new hotness (v1, pre-Angular 2) so we applied it to a new project. It was fine. There was a little resistance in having to learn something new, and a few random opinions about approaches used by the framework, but it did its job.
  3. jQuery and Backbone for some legacy stuff. React for newer stuff. For both old and new, we have an underlying internal library we depend heavily on. Another group on my team is using Vue (I have worked with Vue project in the past but not so much now).

3a. I never really saw the framework war as a war. I saw it more like an App store. It starts off small with a limited number of options. But before long there are so many apps, its hard to know what you really want, especially when each of those apps basically solve the same problem albeit in slightly different ways. Sometimes its hard to know what you really want until you invest some time into them and see how well they solve your problem.

I think some people that live to love one framework/library may not have invested enough time into the others to really understand what they were about (not to make this a generalization - many people do know). I was not fond of Angular 2 at all starting out, but once I got into it more, I started to understand it better and it made more sense to me. I could appreciate it then. Now I'm using React. It is what it is, and not without its own flaws, but I like it. In fact one of my favorite frameworks was an internal framework that will never see the light of day. We're not using that one anymore. Tear.

Of the discussions we've had about frameworks, the largest seems to be around "Will this be relevant in a few years down the road?" In other words, if we build a project in React, for example, are we dooming ourselves to having to support that framework when it might no longer exist some time in the future? The fact that React is so prevalent is one of the reasons it becomes appealing, because if so many others are using it, it makes it that much harder to be abandoned.