frameworks tend to intermingle display and business logic
    testing is tedious and difficult
    cycle time bs
    I once used a framework... and had to wait months

Of course they have varying levels of coupling - it's probably hard to replace parts of Angular, but Mercury for example is just a bundle of easily swappable libraries, like many others. React itself is not a framework.

It also completely overlooks the architectural differences that have come to exist in modern SPAs. What he proposes in the linked slides is just MV*, which everyone already has done for a decade. Flux-style state management + reactive rendering is a huge improvement over that and you won't get that just by using jQuery.

The author actually maintains a virtual-css library (PowerCSS) which benefits from the same principles, yet fails to see the value of doing the same with the DOM. This library + jQuery is already as large as many frameworks.

One of his key points is that frameworks aren't "just architecture + libraries". Read his 2nd point, "Frameworks and the inversion of control".

Also, MV* hasn't been done in javascript for a decade. jQuery itself only came out a decade ago, MV* frameworks started appearing 5 or 6 years ago.

10 years ago most browsers in the wild were still IE6 which could barely handle 100 element for loops, let alone an mvc framework.

Heh, I should tell you a story about 'enterprise' level frameworks of the 2005 era, and the abomination of entangling them with ActiveX.

Somehow, no one cared how slow a page was running, so long as it did it's job.

I didn't do this because I wanted to make some kind of point about architecture or overengineering. I did it because, at that time, front-end frameworks weren't a thing, and the phrase "single-page application" hadn't yet been invented. I didn't even know that was what I was building, because it hadn't been formalized as a concept. I just knew I had a problem to solve, a deadline to meet, and a contract to save.

Which I did. And it was terrible.

There's a point to be made about overengineering. If your app takes five seconds to rebuild after a single-line change, maybe there's a problem. But treating that as cause to throw the baby out with the bathwater amazes me in its foolishness. It makes exactly as much sense as saying that, because airplanes very occasionally fall out of the sky, they're not worth having at all.

I've been seeing a lot of this weird nostalgia lately, this technological-romanticist attitude that there was a better time before web frameworks because everything was so much simpler then. Well, I was there, and it was not. The problems were just as complex; the only real difference was that the tooling sucked. Now it doesn't. We no longer have to build complex applications from jQuery and bearskins. Speaking as one who has done so, that is not something to regret, and neither is a situation in which the major complaint we now have about our tools is that they do too much. As far as problems go, that's a really nice one to have!

I don't see it as a problem with the app, I see it as a problem with the whole Babel -> Browser compile chain using lots of tiny files and imports.

My Python app which is 10x the size of the javascript one has a startup of 2 seconds. The JS app, is less than 5k lines and has a start up of 10 seconds to compile via Webpack serverside, or 18 seconds if we're doing it inline via JSPM, and compiling client-side.

I can't wait till browsers have native imports, and support all of ES2016. If even one does so, I'll switch to that for development and only compile for production.

That's crazy, you should check you're not running more stuff through babel than necessary. (Edit: also why are you compiling via Webpack serverside at all, that sounds like a bad idea)?

> I can't wait till browsers have native imports, and support all of ES2016 ...

Same except once we have native imports, I'd happily stop with what Chrome has now/then, give up the rest of ES2016 for not having to have a build step for local dev.

Because it turned out to be faster to handle the compile serverside, then use hot-reloading.

Why are we using Webpack? Well because we use ES2016 for everything. I tried cutting down on the # of Babel transforms used, but some Babel plugins rely on the transform output of others (e.g. decorators/static members relies on ES2015 class transform), and so I ended up having to use 80% of all the 'standard' plugins anyways, plus everything up to stage 0.

The alternative was to go down to 3-4 second compile times, by eschewing everything that isn't implemented natively in Chrome. I rejected it as workable because our codebase was already pretty heavily leveraging decorators, but it's something to think about for other projects.

If you only use Chrome implemented features of ES2015, then all you need to make a build is a linker like Webpack/JSPM.

> That's crazy, you should check you're not running more stuff through babel than necessary.

Ah, I think you're saying this because of my 5k line of code figure for the JS project. I'm not counting dependencies... and some of those dependencies are really heavy, made worse because they load incompatible versions of things (e.g. Fbjs 0.13 vs fbjs 0.15).

The same is true for the Python project though, but Python is simply faster at linking pre-compiled files than Babel is. JSPM-client side is worse because it has to load each file individually in the browser and then check to compile it. Loading Babel itself in the browser via JSPM takes like 2 seconds.

I think you misunderstood. You aren't supposed to run your dependencies through Babel.

I also made the mistake of making a non SPA recently, using jQuery on the front end. It's a nightmare. I did this so a friend could collaborate and learn, but I really dread writing code for the front end anymore.

Coming back to the old ways from Angular, Backbone, etc feels like a HUGE step backwards in terms of the amount of time. Like if for some reason I decided to ride a horse instead of drive a car.

JS dev is a shitshow because of npm, because of how fast things are moving, because of how many different frameworks and build tools exist. And most of all because of all the hipsterism, using new things because it's cool.

What's worse, a custom framework won't be known by any new developers, so you'll have to spend more resources onboarding them than, say, if you just had to show them how you're using Angular in your company (i.e. they'll already understand things like directives, components, etc.)

Finally, you lose the advantages of having an ecosystem of plugins, support, etc.

It just doesn't make any sense to me to roll your own. Any initial speed you gain you end up paying for later on. To me, using something like Angular means I can harness the experience and expertise of dozens of superstar coders at Google whose only job is to think about the best way to write SPA frameworks.

Why would I not take advantage of that?

And that's a good thing.

The distinction is that you're making a crappy general purpose framework, but you're making a really good problem specific framework that exactly fits the thing you're building.

The reason those frameworks you list are so "bloated" is that their developers have spent so much time polishing them up and general-purpose-izing them so that Everybody can use them for Everything.

Your thing is only for You to do Your Thing, so it can be much lighter and to the point.

Strongly disagree.

Your hand-rolled framework is undocumented besides whatever comments you've put in your code, full of bugs besides whatever you've personally stumbled into, and lacks anything except the features you've needed thus far. It's a means-to-an-end to get the actual features you need done done, instead of built for its own sake and tested and polished for its own sake.

The second your application grows in an unexpected way, you need to augment the entire framework to suit. If there's a bug, you can't search stackoverflow or the github page and just read the answer that 500 other people have found before you, and neither can anyone who has to take over the code after you and try to maintain it--you are the sole author, your internal comments and notes and email chains are all the documentation for the framework that exists in the entire world, there's no hope for the maintainers besides slogging through the source and discovering the solution from scratch. There is no cheerful dev community contributing PRs for the buggy edge cases that break your code on obscure browsers. There's no helpful blog posts out there on how to tweak it for performance optimization. It's all just you trying to maintain what really should be its own full time project while you're trying to build a real product on top of it at the same time.

IME, hand-rolling your own framework as you're building a product gets you the bare minimum (read: extremely poor) mess of code that could possibly address your core use case, not something good for your specific problem. Using multiple libraries instead of monolithic frameworks I think is generally a good idea, depending on context--but completely hand-rolling your own framework from scratch while you're actively developing a product, no, I've never once seen this work well.

The second you need to do something your framework doesn't, the same rule applies. Frameworks are really good for covering most things, but almost everyone runs into that last 5-10% or so that it doesn't do. That ends up being the most difficult, in my experience.

If you use a well-known fwk, you can tell junior devs and new devs to google stuff when in need (as a first line of help), otherwise, you need to write a ton of documentation and/or devote hours per week on support, at the times when you have the least will to do that.

There's no one-fits-all solution, depends on the project, team, constraints etc.

I am saying they are about the same. The last 10% is about as much work as bootstrapping a specific solution.

The new junior dev point is irrelevant if you stick to plain vanilla javascript, and hire junior devs that actually know javascript. Your devs should know how to read code and tests.

> otherwise, you need to write a ton of documentation and/or devote hours per week on support, at the times when you have the least will to do that.

No I don't.

Junior dev: "hey how does this work?" Me: "Did you run the tests?"

At worst, your site won't be cross-browser compatible, but it's not like it's serverside where the framework is legitimately doing heavy lifting in a high performance environment.

Except when you don't. A lot of people, when they realize they're building a framework, start over-engineering (YAGNI). Another issue is that they, for example, build a template renderer but miss a lot of edge cases, opening their application up for script injection and other such nasty things.

Ten or so years ago, PHP had the same disease - people thinking they're hot shit, building their own frameworks, writing wrong tutorials on how to e.g. connect to a database because they thought they knew how that worked. This resulted in a huge amount of SQL injection issues, millions if not billions of hacked accounts, and billions in damages.

TL;DR don't write your own framework, please.

Custom solution built on top of stable components > general purpose framework

Yes I left that a bit ambiguous, but it is harder to manage and work witha rails and ember app than a reg'lear ol rails app. Thats cool if are genuinely getting something out of it. "Ember experiece" on your resume doesnt count.

Except that it does, bummed, but i do understand.

Considering the manpower invested into today's frameworks and tooling, any single individual or small team doesn't stand a chance.

Though the learning curve is much too steep at the moment. It's improving, mostly because 10-level deep callbacks are being replaced with promises/await/async, but especially the tooling is still a daunting challenge for many.

There are now a few promising methods to get something running fast (create-react-app), but that seems to lead to opaque systems that usually work, but are prone to end up completely broken and incomprehensible when you're trying to customize them – because, for example, they do not validate their config files, use inconsistent naming, or deeply nested json where any deviation from the expected structure leads to silent failure.

You really aren't. Well -- I don't know you personally, but speaking statistically, your homegrown one-off framework only makes sense to you and will require a major rewrite to accommodate that feature you want to add next week. And you're going to spend all your time until then debugging a glitchy state transition.

But are you really? I'm not against rolling my own framework, but there needs to be very specifics reasons. The are so many reasons why using a popular framework is a good thing, that there have to be some very good reasons to roll my own.

> Your thing is only for You to do Your Thing, so it can be much lighter and to the point.

Unfortunately every time I have seen this reasoning used, it falls apart after starting. Rarely is software static, and instead it continues to grow. The custom framework may be lighter and to the point when you start and 6 months from now it is a bad copy of a common framework you could have just used off the shelf.

And also doesn't handle things that didn't occur to you, like accessibility. Some of that bloat is actually useful, even necessary, to someone.

You give them too much credit, and yourself not enough.

On the contrary, the framework developers at Google, Facebook, etc. spend time on things that most web application developers do not. For example, accessibility for people with disabilities. If more web application developers would use these frameworks and follow the associated best practices, rather than all wanting to do things their own way, then maybe someday web applications will be accessible by default.

I'm so glad someone wrote preact

By using tools that do one thing and one thing very well it's easy to couple them together in interesting ways.

Way to many websites are using unecessary SPA which create more oportunities for things breaking, being incompatible, or taking longer to load than plain old server side html (plus with a flicker effect).

If you are really running an html application like an online trading platform then yes. But if you are a banking website and just want to display an account balance or the last 30 transactions, I fail to see why using a SPA makes sense. And I am not even talking about podcast websites or blogs where using an SPA is just absurd.

But as I noticed where I work, developpers are too often choosing technologies not based on the problem they are trying to solve, but based on the sort of keyword they want to see on their CVs. So I end up having to use hadoop for accessing 10MB csv files and dealing with similar moronic design decisions.

SPA is what I like to call "non-existent technology," meaning a buzzword that is neither a real technology people can download and use, nor a specification people can refer to. Other examples: "Cloud computing," "NoSQL," "SOA." It only really exists on people's resumes and on blog posts. Non-technical people have no way of knowing that it is not real.

There are good reasons why web applications have backends. There are also good reasons why you would use that backend to serve pre-rendered HTML. There are also good reasons why you would use page transitions to take the user from one screen to another. These concepts are lost on many developers nowadays. I'm not saying you never want an SPA, but it's really freaking hard to do because you're going against the grain on a platform with 20 years of progress in another direction.

What happens when non-existent technology makes up the greater part of the beginner's stack? When instead of the LAMP stack or Ruby on Rails, people graduate coding bootcamps with a specialty in building functional SPAs using NoSQL and cloud-based BFFs?

"Cloud computing," "NoSQL," "SOA" are concepts/ideas. They aren't "technologies" per say. There are, however, technologies that implement these ideas (AWS, CouchDB, Ostrich).

If I have a resume full of concepts/ideas and no actual technologies, then the fact is that I can't be trusted to extend or repair any real system. The beauty of open source is that I do have skills I can take from company to company. I can use my Rails experience at one company to hit the ground running at another. If we start replacing actual technologies with mere concepts in our trade, then we still have a shared language but no shared skills. So the end result is eventually the same as if open source never happened and every programming environment was proprietary. End rant.

But calling SPA a "non-existent technology" is like calling SUV a "non-existent sandwich".

No one claims SPA is a "technology" any more than they claim REST is a technology. It's a paradigm.

All the arguments he makes can be made about any framework, including server-side. Every point of pain he cites I can relate to from use of frameworks like Rails, Symfony, hell the abuse of Wordpress might qualify here.

Rails in particular: I was coding in Rails pre-1.0. Every major version upgrade has been hellish at some level. Often developers don't quite know what's going on only to find that callbacks or validations aren't working as expected.

We can still write awesome Ruby applications using all the libraries that make up Rails, but would I start with Rails these days? I'm not sure I would unless I was going to be working with a team that was quite junior where the gains from conventional layouts and inner workings might give us some gains.

That said, I'd also be transparent with them and myself about the costs of choosing a framework, any framework, and Rails is cheap in the short-term but I've seen it get expensive in the long term. Not because it's Rails or Ruby, but because it's a framework.

I used to think the lack of a decent CQRS framework in most languages was a problem. I now think it might be an advantage. As that pattern becomes more popular for complex domains, it's forcing developers to write better software, and I think somehow most of them are realising this is the way to go. Perhaps that's just my bias.

And it's also why Go is refreshing to me, personally. Frameworks are resisted by the community, primarily for performance reasons, but I actually think the author's arguments apply there too: with good enough library support we can get reuse whilst also not suffering IoC issues.

I have been using Aurelia for 1.5 years now and honestly, I could never go back to jQuery and other libraries again. I've worked with React, Vue, Angular 2 and dipped my feet into Ember. Of all of those, I would say Angular 2 was by far the most non developer friendly framework of them all. Ember is the most opinionated and some developers like that, but for me, I have settled on Aurelia and I do not plan on switching anytime soon.

Having said all of that, sometimes you don't need a SPA framework, sometimes jQuery or even Lodash will serve your needs. When it comes to needing support for routing, data-binding between view and some kind of view-model, I'll pick a SPA over jQuery and having to hack together something that is far less efficient than existing SPA solutions any day of the week.

Assess your needs and choose whatever works for you.

I mean, what would a non-developer do when given this (and that's a very simple example)? https://github.com/AngularShowcase/angular2-sample-app

I'm not making a quality statement, it's just that it is a complex framework for complex programming projects.

When I switched from Polymer to Angular (1) I found a pile of incoherent design decisions which hobbled performance. It's better than writing everything from scratch, but that's not saying much. Maybe Angular 2 is much better, but I understand why it was a total rewrite.

  >  insulting the OP

  >  insulting the OP

It is like an heavy diving suits made for monkeys that loves to climb the height of frameworks complication.

But there are some other kind of developers that feel naturally at ease with swimming in the water of the problem at hand, without requiring the framework.

There is a class of expert coders that are in love with the tools, but really forgot that tools are a mean not an end. Imposing frameworks is for these monkey coders the way they can pay their enormous student debts. And they cannot live in a world where they have to adapt.

On the other hand, there are coders who can and prefer to swim and are infuriated at the absurdity of being a fish trapped in a heavy diving suit.

I do think there's a kernel of truth to it--issues raised in this article and framework choice aside, it's good to ask whether your site needs to be an SPA at all. Because if so you are committing to a lot of time and resources spent on the front end.

HTML rendering, form handling, etc take up a lot of time in the backend too. And with the interactivity that is expected now for many pages (forms just as an example), you end up having to duplicate a lot of things on backend end frontend. And you end up using a framework on the backend too, because you really don't want to hand roll all the routing, templating and form handling. You don't. Trust me.

As long as you are comfortable with a JS stack (or have specialized devs for that) and have a good way of server side rendering figured out, I don't think an SPA incurs a big overall tax.

As an additional plus, there can be a lot more decoupling between frontend and backend work. You can stub out the API and work on the frontend independently in a much cleaner fashion.

What sucks is everything that surrounds React, or all other SPA frameworks for that matter. For instance, every time I end up having to deal with Webpack et al, I want to put a gun in my mouth and pull the trigger.

I don't see why we have to weave such a complex dependency tree and asset pipeline. Every project does it differently too, so you end up relearning the same tool with a different name and in different configurations. Too bad if the previous developer didn't commit the dependency manager manifests or task runner file too, you can't reverse engineer an asset pipeline if all that's left is CSS and raw JS.

If anything goes wrong, you end up chasing issues through half a dozen abstractions you had never heard of. I can't keep all of this plus my actual project requirements in my head. Let me write some darn code already!

[0] https://github.com/yarnpkg/yarn

Pattern matching.

For every dependency listed in package.json, npm install downloads and tests every JSON payload publicly available on the Internet until it finds one that produces the desired npm package.

If frameworks are these terrible monoliths that stop you getting anything done, how come the teams who are actually getting stuff done, and getting attention for its scope and quality, are the ones using them?

I've been using mithril.js a lot this year, and have found it to be unopinionated, minimal, performant, and fairly powerful. You are definitely not locked into some singular way of building applications.

It's a vdom framework, and its views are fairly similar to React (from what I hear, I haven't played with React much). You create a hierarchy of components, which each have a render function written in javascript. I've found this incredibly liberating. I love not having an unnecessary context switch between a limited template system and the rest of my application. Also, you can apply any desired javascript refactoring approaches to your views, instead of relying on pre-ordained approaches like template partials.

The only potential downside to the unopinionated-ness is that you have to decide how to structure things and what higher order patterns you want to use. This has slowed me down a bit, but it has also helped level up my architecture skills, which has been quite rewarding.

I could have chosen React, and I would probably be similarly happy. My main reason for not doing so is that things seemed a bit chaotic in the React world during 2015, and there also seemed to be a lot of spilt milk about doing things the "perfect way". I imagine it the ecosystem has calmed down a bit this year.

I admit the boundaries do seem to get a bit fuzzy. Do you think the article author would consider React or Mithril as libraries he could use? Or as frameworks to be avoided?

In the end I am not a big fan of monolithic frameworks, I prefer libraries much like OP describes that can be swapped or changed for parts of the app (routing, data, templating, scripts, style, etc). But sometimes you are on teams and need a common baseline/plane to keep consistency so you go with frameworks sometimes rather than having to educate/train on custom.

In the end, what helps you ship faster and helps you focus on your product is always the best choice. If you are spending all day learning how to use the framework, going to conferences to learn it, building things in it and jimmying things so you can get it to do what you need by jumping through hoops, then it may be a drag on a good product.

Typically frameworks get you 90% of the way fast and the final 10% or customizing too much is painful, not to mention updates where APIs change wholesale. Custom gets you there slower but you can finish faster at the end as the control is immense. Custom usually allows more flexibility and changes that are on your schedule not the new versions of frameworks that might throw a wrench in timelines from time to time. Simplicity is the key to good custom apps to beat the maintenance time of monolithic frameworks.

A framework is an abstraction and you have to decide if that abstraction is worth it, the real platform is javascript, css, html in the end, how much stack do you want on top of that is a question that changes by project.

For regular devs with deadlines, the need to onboard new team mates, and produce a readable and maintainable codebase, a modern SPA framework will be of benefit.

Interacting with other people is what takes my time, not trying to break the Guinness record of code changes per day.

I don't know if I want a framework, but I do want a library that lets me write less code, rather than solving boring problems that I am sure have been solved a million times before. But I guess at the same time, I want a fast loading web app. Where's the balance?

Interesting bit about the javascript transpilers. Some of them look cool, but I don't know how much static typing I need in something I am constantly refreshing and prodding. And it's another layer of complexity..

It always feels like an whole generation was raised on the web without ever trying out proper tooling for native development.

For me it feels like a Roman taken from the apogee of the Imperium time traveling into the middle dark age.

EDIT: CS => CSS

  > whole generation was raised on the web without ever
  > trying out proper tooling for native development.

The balance, it depends. I think the main value in opinionated frameworks - and typed languages - is in large applications, multi-person and multi-team companies.

Re: the article, 'vanilla' JS / jQuery does not scale to more than 10K LOC - if you are at that level, you're already building your own framework basically (NIH). Angular and other SPA frameworks are intended to help you not do that. More importantly, they imply a certain way to structure your application which others - that are added to the project later - can get up to speed a lot quicker than when you've rolled your own framework.

No, it might not be for you if you're a 31337 rockstar programmer that only works on their own projects and has never worked in the same codebase with other people, but if you're working on serious applications with a serious team, consider using an opinionated framework and a more restricting language.

I was having the same experience as you setting up angular and react applications and wanted to go back to jQuery.

Having done some react I wanted something similar that I could use the chrome debugger in easily and didn't require any transpilers.

Very impressed with it so far. It only took a few hours for me to grok the documentation and start feeling productive.

  > I don't know how much static typing I need

A type system installs roads and rails, you still have the freedom to move but only on those roads. You have to install restrictions in any case: In your code, in your head. The type system makes them explicit, meaning they are easier to share in space and in time, with yourself (a week or a month later) and with other people.

Yes, it's one more tool to learn, but there is a reason it was invented instead of relying on "just code" and context. The good news: You can start simple and easy. No need to use complex type definitions right away. A lot of what the type system does is make restrictions explicit that exist anyway.

Many developers today do not understand what a SPA is and when one should choose this architecture. Writing a client side and a server side code is more complicated task that writing just a server side code so it should be justified.

Client side code is necessary when building interactive applications like spreadsheet or when an application has to work offline or store data locally. When a website feels more like a desktop application than a plain web page. There should be reasons to complicate architecture.

Most of a web sites are just a collection of pages, not applications. Using SPA there gives no advantages. For examples, developers of this website [1] used a megabyte of Javascript and API to display a list of 10 links. I do not see a single benefit from using SPA here over serving a 5Kb HTML file with those links. Everything just got worse.

And it looks like some JS frameworks authors do not understand it too. For example, I looked at Ember documentation and saw a tutorial [2] on building a rental site. Using Ember there gives no advantages over good old server-side generated pages (optionally using github-style AJAX page reloading). This over-engineered approach just makes a website load slower, comsume more CPU and memory resources, increases complexity, complicates deployment. If they are presenting Ember as a tool to build applications they should provide an example of application, not a plain old HTML 1.0 website.

[1] https://whosfiring.com/

[2] https://guides.emberjs.com/v2.9.0/tutorial/ember-cli/

Otherwise I have to say this is the worst advice for any engineer building a commercial website. Maybe if someone went back in time 10 years, this might look like a solution, but there is a reason all of this is left behind. I've been a web developer for 20 years now and browser development has finally graduated to real software engineering.

The author has a laundry list of grievances based on their own experiences. It's clear that these are merely opinions though, and they can be taken at face value.

"Frameworks and complexity === insanely long cycle times"

This is simply not true and it's purely subjective. Any developer using Continuous Development can roll out changes to production in a matter of hours, if not a few days. Sophisticated apps need to be modular and engineered for a simple workflow, automated testing and a clear separation of concerns. There is no point to setting yourself up for defeat, and if anyone followed this advice, that's exactly what would happen.

There's a clear distinction between the FUD of naysayers compared to people with more sophisticated levels of development experience. I am not sure someone with this mindset could even get past a phone screen. egad.

I was a web newbie but experienced developer in other field. The attraction of a framework like angular is it lets you write relatively large chunk of 'flat' code without having to worry about the structure of your code. So for a newbie it's easy to get started, of course you'll eventually face the dark side. But then you have to make a choice to either abandon angular and go for something else, or keep on going and make yourself good at angular.

Another thing is, there are plenty of good resources for learning frameworks like angular and react. Can anyone point to me some good up to date resources of building a functioning website from scratch by using purely jQuery?

I'm presently working my way through Programming in the 1990s. In it's controversial premise, it states:

Basically we are taught to guess our programs, and then to patch up our guesses. Our errors are given the cute name of "bugs". Fixing them becomes puzzle-solving, as does finding tricks that exploit or avoid poorly designed features of the programming language. The entire process is time-consuming and expensive.

And while I appreciate short cycle-times between code and result; I find "guessing my program into existence" is the most sure-fire way to shoot myself in the foot.

Now I don't write a specification for every program. However one doesn't have to these days to gain the benefits of fore-thought and reasoning. Functional programming has revealed many patterns and algebras for programs that work well in practice. If compiling a higher-level, soundly-typed language into Javascript takes an excruciating 5 seconds it'd still be worth it because I will have fewer bugs in my code, by design, over the developer that continually adds code in a hurried frenzy.

In spirit I agree that frameworks are restrictive but I don't see how Javascript is there to help prevent you from writing errors. A framework would at least give you the ground work to avoid egregious ones. Though better still, use functional programming patterns or languages if you can and compile down to Javascript if you must. Works well.

In our case the productivity gains from ES6 features easily outweighed the compilation time.

Never once did I regret the choice, nor has been limited by the choice. I pretty much could implement everything I thought with minimal effort.

I would say backbone with backbone layout manager has the bare minimal abstraction. It just boils down to picking the right pattern. I use a state variable to hold everything related to the dom, and re-render the dom whenever the dom needs to be updated. May not be as fast as 'react', but at least in my case, it is good enough. ( Since my 'views' are nicely factored, I often has to re-render only a small part of the dom)

Without the framework, I would have taken double the time for sure. And boy, the code is nicely organised as well.

I did have some experience in developing spa's using jquery alone. Well, that was in 2009. On any day, I would vouch for Backbone+ Backbone Layout Manger + Jade over simple jquery

I used to wonder why it hasn't been as popular as react or angular.

Mainly b/c it isn't a framework endorsed by Google/Facebook.

You don’t even need a framework most of the time. Most of the frameworks I’ve used are poorly designed (I'm looking at you Ember. If there are any Ember devs reading this, I'll meet you in the parking lot...) and represent the design choices of a someone working on some project probably a lot different than yours. It feels good to give up control and let someone else make some choices for you, until you realize you’ve built an application based upon their poor design, and then you’re stuck.

All you need is semantic HTML, the DOM, and some plain old javascript. Organize your code, write simply, don’t overcomplicate and try to make things too general because your problems probably are very likely concrete anyway. Don’t buy into the hype. Just because big company X uses something, doesn’t mean you need to use it on your projects too. Have you seen Facebook? Their product hasn’t changed or innovated appreciably in years so you shouldn’t be taking any lessons from them in how to build ‘scalable’ applications, whatever that means.

Don’t dump a 500 KB framework on the page to save a few milliseconds in incremental rendering. Or think you need to worry about performance or complexity before you even have an app.

Is it odd to anyone that the entire battle cry of React is rooted in pre-optimization? The myth that the DOM is somehow evil, or all pages will one day have millions of elements to manage? This is gladly spoonfed to people who don't understand how the browser works, and never learned the basics. Take away their framework and they don't know how to build apps!

It violates my sense of pragmatism to save a few ms in rendering when you delay the initial page load by 500 ms or more? I also personally find the mixing of declarative and imperative programming styles and JSX to be absolutely horrid and the debug experience of many of the immutable libraries to be terrible. And, if you actually performance test the stuff you'll see they are full of either outright lies or fabrications to make the authors look good. Hint: if every time you call a getter on an object it causes the framework to go 30 stacks deep you're not going to have good performance. Just try it in your framework of choice today. You're swear we're working in java these days with the stack traces so deep and abstracted they have lost all touch with reality.

My favorite recently is to find all kinds of bizarre wrappers for javascript libraries that could have been used well enough on their own. The wrappers don't really do anything other than hard-code the original author's API and basically act as a middle man. I guess everything needs to be wrapped in a react component to be useful these days huh?

SPA means Single Page Application.

The term is written in the third paragraph, but not clearly connected to the acronym.

Even keeping two different views in sync in different parts of an application without a framework is so much work it's not worth the effort, let alone building a whole SPA.

But to each their own.