11 ms·

Do you really want a single-page application framework?

186 points by Immortalin 10y ago

DigitalSea 10y ago
I think many of the arguments in this article might have been applicable back in 2012 when single page application frameworks were the new and popular thing. We can all agree that Angular 1 served us well at the time, but introduced added complexity and issues of its own (digest cycle being the main one). Some of the frameworks/libraries out there right now are stellar. 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.
- gumoro 10y ago
  Did you mean "non-developer friendly" or "non developer-friendly"?
  - Noseshine 10y ago
    I think we can use context to easily infer what was meant: Looking at Angular, I don't see how a non-developer could even get started :-) 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 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.
    - gumoro 10y ago
      Thanks, I have no experience with it and could not tell (although yeah I was leaning for your interpretation)... Maybe I'll reconsider this ng2 training then :)
    - indolering 10y ago
      There are legitimate disagreements to be had here but insulting the OP isn't one of them. 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.
      - Noseshine 10y ago
        > insulting the OP What on earth are you talking about???
        indolering 10y ago
        I misspoke, I mean the "original author" not the OP.
        Noseshine 10y ago
        That doesn't make your reply to me > insulting the OP any more comprehensible!
        indolering 10y ago
        Oh Christ, I totally misread your post! I took "I don't see how a non-developer could even get started" as being in the first person. I'm sorry!
  - exodust 10y ago
    Angular 2, non-developer friendly? Not happening.
    - SFJulie 10y ago
      Angular2 is «some kind of developer» friendly. The kind that loves framework but hate the underlying problem. 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.
      - tps5 10y ago
        Oh, OK.
      - exodust 10y ago
        I don't even, dive with a birthday suit but I'll swim with the fishes as soon as a monkey shows me the way.
        SFJulie 10y ago
        ook Oook Oook .... ook?! -- The librarian
- ilostmykeys 10y ago
  No, we can't all agree that Angular 1 served us well. Terrible architecture IMO. Used it on one small project (just to be open minded) and never touched it again. React, on the other hand, is well founded, but has its own flaws, as does everything. Nothing is truly stellar.
dwightgunning 10y ago
Solid advice for anybody who is already an experienced developer and capable of authoring an SPA framework of their own. 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.
kevan 10y ago
The author has an entire section on long cycle times (time to make a change, compile/transpile it, and try it out) but it hasn't been nearly as bad for me. The worst case I've experienced was a large Grails app using Babel transpilation that could take a minute to compile all assets on first startup. But that worst case only happened after a full clean. Incremental builds took about 2 seconds. I've never experienced a 5 minute cycle time due to a transpiler. In our case the productivity gains from ES6 features easily outweighed the compilation time.
deleted 10y ago
[deleted]
firasd 10y ago
I was amused by this HN comment saying that React is a tax Facebook imposes on startups https://news.ycombinator.com/item?id=12217170 https://news.ycombinator.com/item?id=12217170 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.
- enraged_camel 10y ago
  It's not React itself that consumes time. On the contrary, React reduces the time it takes to develop UIs. Sometimes drastically. 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.
  - ehnto 10y ago
    Managing tooling and dependencies is the worst part of modern front end work. 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!
    - thewhitetulip 10y ago
      Yes, especially the notorious npm which is hell bent on installing the entire Internet when I do npm install. God knows what and why it installs the things it does
      - eatonphil 10y ago
royka118 10y ago
Just feels like a rant tbh. I've developed spa's as well as django and rails app. I've seen bad spa's been written as well as bad server side routing apps. Shit code is shit code wherever/whatever language it's written in. To say you don't need some sort of FE framework is prob a bit much. You get so much for free and websites are getting more and more dynamic not less. Sure don't use flavour of the month frameworks. But I'd argue ng1, ng2, react, Vue etc are not flavour of the months.
- rimantas 10y ago
  Shitty code is one thing. Shitty choice of the solution for the problem at hand is on another level.
cdmckay 10y ago
I find that when you start rolling your own framework, you just end up making crappier versions of what's in Angular, Ember, etc. 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?
- jasonkester 10y ago
  I find that when you start rolling your own framework, you just end up making crappier versions of what's in Angular, Ember, etc. 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.
  - Cthulhu_ 10y ago
    > but you're making a really good problem specific framework that exactly fits the thing you're building. 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.
lacampbell 10y ago
I am new to front end development - javascript and html. I am dismayed at how slow and unproductive I am trying to develop simple web apps. People advise me not to use jquery anymore because ES6 makes it redundant. But I am not sure. 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..
- pjmlp 10y ago
  Developing JS + HTML + CSS applications on a stack created for interactive documents, feels like stone age when compared to the RAD GUI tooling of the 90's. 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
  - rimantas 10y ago
    > whole generation was raised on the web without ever > trying out proper tooling for native development. What's worse they try to drag this into native too. I am tired of repeating: do try and find out what native offers before bringing your crap into it.
- boyter 10y ago
  Try mithriljs. It's the same idea as react for the view. 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.
- Noseshine 10y ago
  > I don't know how much static typing I need The advantage of a type system is that you can restrict what you can do - which is a good thing. If you had to paint something, it's much easier to add some shadow or improve or add a detail in an existing painting compared to getting the full freedom of a blank white sheet. Any design act, art or engineering, means to slowly restrict yourself more and more, until you came down from a universe with an infinity of options to having only one left. 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.
pjmlp 10y ago
"Well, actually, we do. If our overhead for producing working development code is greater than say, oh, 5 seconds, then somebody out there is definitely kicking our ass on cycle times. That developer can fail 300 times in an hour. If it takes 200 failures before success, it will take a miniumum of 40 minutes to resolve an issue with a 5s cycle time. If our cycle time is 5 minutes because of all the multi-compile overhead, our minimum time for success will be 72 times longer, or over two full work-day. So we can pick 40 minutes or 2.1 days to resolve an issue to the same level of completeness. You make the call." Interacting with other people is what takes my time, not trying to break the Guinness record of code changes per day.
drawkbox 10y ago
The answer is will a monolithic framework or a set of libraries help you build the best product with quality and quickly. Whichever one will help you build a better product is different depending on the context, project, scope, team and timeline. 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.
cm2187 10y ago
To me the question is more "do you really need a SPA" rather than "do you really need a framework for your SPA". 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.
- PaulRobinson 10y ago
  There are points in this article that go beyond SPA. In fact, I'd drop "for your SPA" from the title, and just use SPAs as an example. The author didn't, because, you know, he has a book to sell on SPAs, but let's let that slide. ;) 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.
SandB0x 10y ago
Since the article doesn't define the acronym and I had to look it up: SPA means Single Page Application. The term is written in the third paragraph, but not clearly connected to the acronym.
dwaltrip 10y ago
At this point, I can't really imagine writing a large web app without some sort of framework. 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.
- methyl 10y ago
  But the point is, neither React nor Mithril are frameworks, they are just unopinionated libraries where you write plain JavaScript code.
  - dwaltrip 10y ago
    It's much closer to a framework than jQuery. Mithril also provides a few core things beyond just views - basic routing, an ajax helper, and a few others. 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?
z3t4 10y ago
JQuery solved a real problem when it was created. But the problem no longer exist, the standards has settled. But at least you can just stop using it and use CSS and standard API's instead. But when it comes to a framework, especially if it has a compilation step, it's not easy to just stop using it.
ricardobeat 10y ago
I apologize in advance, but I, an ES5 / lean modules / no-build / vanilla javascript guy, find this article to be terrible advice. The arguments against frameworks are backed by generalizations like 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 Then goes on to say When we use a sound architecture and libraries instead - well, guess what? Frameworks are just architecture + libraries! In fact, your plan to release an "npm module" with architecture, diagrams and library dependencies is a framework, a mishmash of solutions of varying quality! 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.
- mattmanser 10y ago
  You're cherry picking. 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.
  - zdragnar 10y ago
    There are certainly JS MV* frameworks older than 5 years... Dojo and puremvc come to mind.
  - dismantlethesun 10y 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.
iamleppert 10y ago
You don’t need any of this stuff to build a great web app. You don’t need react, you don’t need fancy javascript syntax that requires you have a complicated build infrastructure. Babel has over 40,000 files. Think about that for a moment. 40k files for some shorthand syntax. Your "build" times may only be a few seconds now (anything that is over one second imo is too long), but just wait. They will get to 30+ seconds in no time and then you'll have to go dive into the belly of that 40k file beast to find out how to unfuck yourself. I've been there. 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?
pka 10y ago
This is insane. 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.
ioda 10y ago
At http://www.reportdash.com http://www.reportdash.com we use backbone with backbone layout manager and jade. We have been able to design a pretty robust report and dashboard builder with just a single front-end developer. 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.
- bikamonki 10y ago
  > 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.
- throwanem 10y ago
  I've never seen a clean, maintainable implementation based on Backbone. I would like to.
codedokode 10y ago
Answering the question in the title: no, probably you don't. 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/ https://whosfiring.com/ [2] https://guides.emberjs.com/v2.9.0/tutorial/ember-cli/ https://guides.emberjs.com/v2.9.0/tutorial/ember-cli/
stupidcar 10y ago
People keep up-voting rants like this about how terrible front-end frameworks are, but EVERY SINGLE TIME I see an ambitious, high-quality web app upvoted, I check the source, and it's using a front-end framework. 99% of the time it's React or Angular. 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?
- Can_Not 10y ago
  It sounds like you saw some great apps using the right tools to solve the problem space and then you saw some unhappy devs who didn't pick the right tool for the job.
vladimir-y 10y ago
A need to use frameworks is the unification matter. Unification is necessary for serious/big projects for obvious reasons. Ie you can find people on the market who are able to start working quickly due to the familiar tools/structure used, not dealing with some "homemade" frameworks.
shanwang 10y ago
I started web development by learning Angular 1, maybe I'm the minority, but I actually liked it in the beginning, and only grow to dislike after dived deep into it. 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?
snarfy 10y ago
I'd rather have a good, easy to use library than a framework.
eeZah7Ux 10y ago
No, not at all.
trey-jones 10y ago
I feel this way about backend frameworks, but to me if you take the time to learn something like Angular, it saves will reduce the bulk of the code substantially, compared to using jQuery for example. A listener for this, a listener for that? No, just data-bind and be done with it. There are challenges of course. Once you are in, you are all in, and you will be maintaining this application for its lifetime or rewriting it. Javascript frameworks these days move at the speed of sound, so if you start writing it today at while your framework is at v1.0, there is a good chance that your framework will be v1.5 by the time you release, with several breaking changes. This is probably the most aggravating part to me. I have thought that perhaps the diversity of opinions on these sorts of issues, and the speed at which these frameworks are written and rewritten are symptoms of a larger problem, namely the browser as a platform.
throwanem 10y ago
I've done exactly what this author advises - that is, build a complex, real-world single-page app using nothing but jQuery and some plugins. 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!
- deleted 10y ago
  [deleted]
- g00gler 10y ago
  I had the same experience building a SPA with jQuery. Updating the view and keeping it in sync was atrocious. 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.
- dismantlethesun 10y ago
  > If your app takes five seconds to rebuild after a single-line change, maybe there's a problem. 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.
aikah 10y ago
Developers want declarative widgets mainly. Obviously web components are supposed to solve all that but they are still not widely supported by browsers.
dalacv 10y ago
just use http://Bubble.is http://Bubble.is
agentultra 10y ago
Well, actually, we do. If our overhead for producing working development code is greater than say, oh, 5 seconds, then somebody out there is definitely kicking our ass on cycle times. That developer can fail 300 times in an hour. If it takes 200 failures before success, it will take a miniumum of 40 minutes to resolve an issue with a 5s cycle time. If our cycle time is 5 minutes because of all the multi-compile overhead, our minimum time for success will be 72 times longer, or over two full work-day. So we can pick 40 minutes or 2.1 days to resolve an issue to the same level of completeness. You make the call. 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.
kensign 10y ago
I suggest people check out http://aurelia.io http://aurelia.io 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.
meitham 10y ago
Yes
curried_haskell 10y ago
To answer the question, yes. Yes I do.

186 points by Immortalin 10y ago

I think many of the arguments in this article might have been applicable back in 2012 when single page application frameworks were the new and popular thing. We can all agree that Angular 1 served us well at the time, but introduced added complexity and issues of its own (digest cycle being the main one). Some of the frameworks/libraries out there right now are stellar. 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.

gumoro 10y ago
Did you mean "non-developer friendly" or "non developer-friendly"?
- Noseshine 10y ago
  I think we can use context to easily infer what was meant: Looking at Angular, I don't see how a non-developer could even get started :-) 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 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.
  - gumoro 10y ago
    Thanks, I have no experience with it and could not tell (although yeah I was leaning for your interpretation)... Maybe I'll reconsider this ng2 training then :)
  - indolering 10y ago
    There are legitimate disagreements to be had here but insulting the OP isn't one of them. 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.
    - Noseshine 10y ago
      > insulting the OP What on earth are you talking about???
      - indolering 10y ago
        I misspoke, I mean the "original author" not the OP.
        Noseshine 10y ago
        That doesn't make your reply to me > insulting the OP any more comprehensible!
        indolering 10y ago
        Oh Christ, I totally misread your post! I took "I don't see how a non-developer could even get started" as being in the first person. I'm sorry!
- exodust 10y ago
  Angular 2, non-developer friendly? Not happening.
  - SFJulie 10y ago
    Angular2 is «some kind of developer» friendly. The kind that loves framework but hate the underlying problem. 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.
    - tps5 10y ago
      Oh, OK.
    - exodust 10y ago
      I don't even, dive with a birthday suit but I'll swim with the fishes as soon as a monkey shows me the way.
      - SFJulie 10y ago
        ook Oook Oook .... ook?! -- The librarian
ilostmykeys 10y ago
No, we can't all agree that Angular 1 served us well. Terrible architecture IMO. Used it on one small project (just to be open minded) and never touched it again. React, on the other hand, is well founded, but has its own flaws, as does everything. Nothing is truly stellar.

dwightgunning 10y ago

Solid advice for anybody who is already an experienced developer and capable of authoring an SPA framework of their own. 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.

kevan 10y ago

The author has an entire section on long cycle times (time to make a change, compile/transpile it, and try it out) but it hasn't been nearly as bad for me. The worst case I've experienced was a large Grails app using Babel transpilation that could take a minute to compile all assets on first startup. But that worst case only happened after a full clean. Incremental builds took about 2 seconds. I've never experienced a 5 minute cycle time due to a transpiler. In our case the productivity gains from ES6 features easily outweighed the compilation time.

deleted 10y ago

[deleted]

firasd 10y ago

I was amused by this HN comment saying that React is a tax Facebook imposes on startups https://news.ycombinator.com/item?id=12217170 https://news.ycombinator.com/item?id=12217170 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.

enraged_camel 10y ago
It's not React itself that consumes time. On the contrary, React reduces the time it takes to develop UIs. Sometimes drastically. 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.
- ehnto 10y ago
  Managing tooling and dependencies is the worst part of modern front end work. 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!
  - thewhitetulip 10y ago
    Yes, especially the notorious npm which is hell bent on installing the entire Internet when I do npm install. God knows what and why it installs the things it does
    - eatonphil 10y ago

royka118 10y ago

Just feels like a rant tbh. I've developed spa's as well as django and rails app. I've seen bad spa's been written as well as bad server side routing apps. Shit code is shit code wherever/whatever language it's written in. To say you don't need some sort of FE framework is prob a bit much. You get so much for free and websites are getting more and more dynamic not less. Sure don't use flavour of the month frameworks. But I'd argue ng1, ng2, react, Vue etc are not flavour of the months.

rimantas 10y ago
Shitty code is one thing. Shitty choice of the solution for the problem at hand is on another level.

cdmckay 10y ago

I find that when you start rolling your own framework, you just end up making crappier versions of what's in Angular, Ember, etc. 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?

jasonkester 10y ago
I find that when you start rolling your own framework, you just end up making crappier versions of what's in Angular, Ember, etc. 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.
- Cthulhu_ 10y ago
  > but you're making a really good problem specific framework that exactly fits the thing you're building. 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.

lacampbell 10y ago

I am new to front end development - javascript and html. I am dismayed at how slow and unproductive I am trying to develop simple web apps. People advise me not to use jquery anymore because ES6 makes it redundant. But I am not sure. 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..

pjmlp 10y ago
Developing JS + HTML + CSS applications on a stack created for interactive documents, feels like stone age when compared to the RAD GUI tooling of the 90's. 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
- rimantas 10y ago
  > whole generation was raised on the web without ever > trying out proper tooling for native development. What's worse they try to drag this into native too. I am tired of repeating: do try and find out what native offers before bringing your crap into it.
boyter 10y ago
Try mithriljs. It's the same idea as react for the view. 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.
Noseshine 10y ago
> I don't know how much static typing I need The advantage of a type system is that you can restrict what you can do - which is a good thing. If you had to paint something, it's much easier to add some shadow or improve or add a detail in an existing painting compared to getting the full freedom of a blank white sheet. Any design act, art or engineering, means to slowly restrict yourself more and more, until you came down from a universe with an infinity of options to having only one left. 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.

pjmlp 10y ago

"Well, actually, we do. If our overhead for producing working development code is greater than say, oh, 5 seconds, then somebody out there is definitely kicking our ass on cycle times. That developer can fail 300 times in an hour. If it takes 200 failures before success, it will take a miniumum of 40 minutes to resolve an issue with a 5s cycle time. If our cycle time is 5 minutes because of all the multi-compile overhead, our minimum time for success will be 72 times longer, or over two full work-day. So we can pick 40 minutes or 2.1 days to resolve an issue to the same level of completeness. You make the call." Interacting with other people is what takes my time, not trying to break the Guinness record of code changes per day.

drawkbox 10y ago

The answer is will a monolithic framework or a set of libraries help you build the best product with quality and quickly. Whichever one will help you build a better product is different depending on the context, project, scope, team and timeline. 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.

cm2187 10y ago

To me the question is more "do you really need a SPA" rather than "do you really need a framework for your SPA". 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.

PaulRobinson 10y ago
There are points in this article that go beyond SPA. In fact, I'd drop "for your SPA" from the title, and just use SPAs as an example. The author didn't, because, you know, he has a book to sell on SPAs, but let's let that slide. ;) 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.

SandB0x 10y ago

Since the article doesn't define the acronym and I had to look it up: SPA means Single Page Application. The term is written in the third paragraph, but not clearly connected to the acronym.

dwaltrip 10y ago

At this point, I can't really imagine writing a large web app without some sort of framework. 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.

methyl 10y ago
But the point is, neither React nor Mithril are frameworks, they are just unopinionated libraries where you write plain JavaScript code.
- dwaltrip 10y ago
  It's much closer to a framework than jQuery. Mithril also provides a few core things beyond just views - basic routing, an ajax helper, and a few others. 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?

z3t4 10y ago

JQuery solved a real problem when it was created. But the problem no longer exist, the standards has settled. But at least you can just stop using it and use CSS and standard API's instead. But when it comes to a framework, especially if it has a compilation step, it's not easy to just stop using it.

ricardobeat 10y ago

I apologize in advance, but I, an ES5 / lean modules / no-build / vanilla javascript guy, find this article to be terrible advice. The arguments against frameworks are backed by generalizations like 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 Then goes on to say When we use a sound architecture and libraries instead - well, guess what? Frameworks are just architecture + libraries! In fact, your plan to release an "npm module" with architecture, diagrams and library dependencies is a framework, a mishmash of solutions of varying quality! 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.

mattmanser 10y ago
You're cherry picking. 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.
- zdragnar 10y ago
  There are certainly JS MV* frameworks older than 5 years... Dojo and puremvc come to mind.
- dismantlethesun 10y 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.

iamleppert 10y ago

You don’t need any of this stuff to build a great web app. You don’t need react, you don’t need fancy javascript syntax that requires you have a complicated build infrastructure. Babel has over 40,000 files. Think about that for a moment. 40k files for some shorthand syntax. Your "build" times may only be a few seconds now (anything that is over one second imo is too long), but just wait. They will get to 30+ seconds in no time and then you'll have to go dive into the belly of that 40k file beast to find out how to unfuck yourself. I've been there. 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?

pka 10y ago

This is insane. 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.

ioda 10y ago

At http://www.reportdash.com http://www.reportdash.com we use backbone with backbone layout manager and jade. We have been able to design a pretty robust report and dashboard builder with just a single front-end developer. 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.

bikamonki 10y ago
> 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.
throwanem 10y ago
I've never seen a clean, maintainable implementation based on Backbone. I would like to.

codedokode 10y ago

Answering the question in the title: no, probably you don't. 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/ https://whosfiring.com/ [2] https://guides.emberjs.com/v2.9.0/tutorial/ember-cli/ https://guides.emberjs.com/v2.9.0/tutorial/ember-cli/

stupidcar 10y ago

People keep up-voting rants like this about how terrible front-end frameworks are, but EVERY SINGLE TIME I see an ambitious, high-quality web app upvoted, I check the source, and it's using a front-end framework. 99% of the time it's React or Angular. 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?

Can_Not 10y ago
It sounds like you saw some great apps using the right tools to solve the problem space and then you saw some unhappy devs who didn't pick the right tool for the job.

vladimir-y 10y ago

A need to use frameworks is the unification matter. Unification is necessary for serious/big projects for obvious reasons. Ie you can find people on the market who are able to start working quickly due to the familiar tools/structure used, not dealing with some "homemade" frameworks.

shanwang 10y ago

I started web development by learning Angular 1, maybe I'm the minority, but I actually liked it in the beginning, and only grow to dislike after dived deep into it. 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?

snarfy 10y ago

I'd rather have a good, easy to use library than a framework.

eeZah7Ux 10y ago

No, not at all.

trey-jones 10y ago

I feel this way about backend frameworks, but to me if you take the time to learn something like Angular, it saves will reduce the bulk of the code substantially, compared to using jQuery for example. A listener for this, a listener for that? No, just data-bind and be done with it. There are challenges of course. Once you are in, you are all in, and you will be maintaining this application for its lifetime or rewriting it. Javascript frameworks these days move at the speed of sound, so if you start writing it today at while your framework is at v1.0, there is a good chance that your framework will be v1.5 by the time you release, with several breaking changes. This is probably the most aggravating part to me. I have thought that perhaps the diversity of opinions on these sorts of issues, and the speed at which these frameworks are written and rewritten are symptoms of a larger problem, namely the browser as a platform.

throwanem 10y ago

I've done exactly what this author advises - that is, build a complex, real-world single-page app using nothing but jQuery and some plugins. 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!

deleted 10y ago
[deleted]
g00gler 10y ago
I had the same experience building a SPA with jQuery. Updating the view and keeping it in sync was atrocious. 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.
dismantlethesun 10y ago
> If your app takes five seconds to rebuild after a single-line change, maybe there's a problem. 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.

aikah 10y ago

Developers want declarative widgets mainly. Obviously web components are supposed to solve all that but they are still not widely supported by browsers.

dalacv 10y ago

just use http://Bubble.is http://Bubble.is

agentultra 10y ago

Well, actually, we do. If our overhead for producing working development code is greater than say, oh, 5 seconds, then somebody out there is definitely kicking our ass on cycle times. That developer can fail 300 times in an hour. If it takes 200 failures before success, it will take a miniumum of 40 minutes to resolve an issue with a 5s cycle time. If our cycle time is 5 minutes because of all the multi-compile overhead, our minimum time for success will be 72 times longer, or over two full work-day. So we can pick 40 minutes or 2.1 days to resolve an issue to the same level of completeness. You make the call. 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.

kensign 10y ago

I suggest people check out http://aurelia.io http://aurelia.io 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.

meitham 10y ago

Yes

curried_haskell 10y ago

To answer the question, yes. Yes I do.