You probably don't need a JavaScript framework
slack-files.com
slack-files.com
Then the web-boys came in to rewrite my... well, contraption. In came Grunt, NPM, Angular, some CSS framework, unit testing. Much more, but I forgot the names of all of it, you know the drill. I have to admit, looking at each of these components independently, one could hardly argue with their usefulness, but together they buried a relatively simple and elegant messaging system in tons and tons of incoherent, unmaintained, inextensible and incompatible (with websockets at the time) stuff.
The line-count went up, of course, easily to 15000 lines. I couldn't understand my own designs anymore, since they got spread out over dozens different files. Refactoring became almost impossible. The web-boys however, didn't understand asynchronous messaging, cryptography and eventual consistency very well and we lost each other, making a babylonian tower, far away from our original goals.
The quality of your solution is not in your libraries, or your frameworks, instead it's in being fluent bottom-up before grabbing a library or two. You'll see you often don't even need them.
(edit: small typos, edit2: please explain down-votes, I'd like to know and be happy to answer any questions)
As someone else pointed out in this thread, a great advantage of established frameworks is that they provide a coding standard for a team. People who do this stuff every day can easily follow the standard, understand the flow and be very productive. They did invest lots of time to learn about all those tools and libraries and probably had an overall productivity gain compared to writing native JS.
If you don't really enjoy front-end development, and your comment reads like you don't, get on your high horse and join me for a ride while the "web-boys" make our hacked UIs usable for end-users and maintainable for the next "web-boys" who have to hack on it. When we get back we'll probably be very grateful for a great UI(X). ;)
Unfortunately that claim doesn't hold up to what I suspect is happening most of the time. At least in my experience at work I've seen tech leads or someone similar introduce frameworks without so much as "apparently it's quite good, so let's use it".
One case in particular, Angular was chosen and turned out not to be suitable - it ran very slowly with the tasks it was chosen to do in the browser on a particularly busy web page. Learning the limitations of Angular would have gone a long way to avoiding the poor result. Not enough learning, too much embracing shiny new things.
And if they all want to use it - let them use it. The productivity gained by agreeing on a framework usually outweighs the performance loss over the "best" solution. Yes, my native JS implementation of a gallery app is much faster than the React version (reviewed by an experienced React-dev and judged "good") but if that project goes public and other people have to work on it I'll be damned if I make them learn my way of doing things. I'd expect these devs to implement a feature quickly and that means they use the framework they are most comfortable with. If it is good enough, it is good enough.
Aiming for perfection killed way too many projects, accepting that the productive path is not always the nicest or cleanest (according to some arbitrary metric) is what makes projects succeed. e.g.: Writing perl code is definitely not the best thing to do, performance wise (when counting clock cycles), but it does (did) allow some folks to be incredibly successful. See this awesome essay of this very site's founder: http://www.paulgraham.com/avg.html
Isn't that basic sin of software development - weighing speed of implementation (which is just a tiny part of the lifetime cost of software) over anything else.
I'm not arguing against 'good enough', I just don't think this is a particularly strong argument for that.
It's like surgeon not washing his hands and sterilizing his equipment because that way implementing the surgery takes less effort.
EDIT, to make my point clear: The surgeon comparison is not valid because a surgeon deals with a much longer lifetime than not only the average but most software projects.
This is a false dichotomy. This only applies once the developers have real experience with the framework. Throwing a brand new framework at the devs without at least a month to play with it - play, not work! - is doomed to failure. Expecting first-time use of a framework on an actual project to go well is a horrible mistake.
There is a lot to learn with any reasonably sized framework. Making devs use an unknown framework without time to learn it will result in a project that doesn't use that framework properly. Thousands of lines of code will be written... to duplicate functionality the framework already provides, but that the devs don't know exist. The rush of deadlines means that the devs skip reading documentation or researching the "right way" to do every task, and you wind up with a project that technically uses the framework... except that the entire project will be written in a way that someone with previous experience with that framework would never have allowed to happen.
Some frameworks have so much to learn that it's essentially equivalent to having to learn a new programming language. Would you ever expect someone to learn C in a week? Java? Python? No...? Then please don't expect devs to pick up a new framework on the spot with no time to self-train on it.
>> if they all want to use it - let them use it
>> they use the framework they are most comfortable with.
> Then please don't expect devs to pick up a new framework on the spot with no time to self-train on it.
I never said I did.
Amazon is an example, but there are many others.
I totally disagree, and not because of performance; choosing a framework based on its performance would be premature optimization. Your argument breaks down here:
> I'll be damned if I make them learn my way of doing things. I'd expect these devs to implement a feature quickly
But that's exactly what a lot of projects using a framework end up doing. Between Ember, Angular, React, Backbone, Dojo, Prototype, and GWT, there is a ton of competition in this space, and you would have a hard time finding a team of professionals who all know the same framework. So at least some of your team will be learning the framework, and that learning will not pay off compared to just using vanilla JS. You can't argue that familiarity outweighs the complication added by a framework because people aren't familiar with the same frameworks.
Vanilla JavaScript is the lowest common denominator: almost everyone is familiar with it.
Personally I consider everything and don't rule anything out. I wouldn't rule out be-spoke is my main argument.
It's just that, you know, life can be more rewarding if you not only aim for perfection or near-perfection, but achieve it. There's a philosophical angle here that may be more suited to the start-ups thinking and dreaming big and original, vs the company who just wants "something that works/MVP".
I do that with my own software in my spare time, but from an economic point of view I cannot justify to spend that time when working for someone else. And since projects are always evolving also in requirements "perfection" is a moving target.
I completely agree. Web people quite often commit to frameworks based on their marketing copy and maybe one guy they read on the internet saying "seems pretty AWESOME after I've played with it for two days!" and a testimonial or two.
Of course, I've seen development languages chosen that way, NoSQL databases chosen that way, "which Linux variant do we base our company on" chosen that way, bug trackers chosen that way, chat systems chosen that way, devops management chosen that way, VM and/or containerization chosen that way (or, indeed, people just declaring "we need containers" for what appears to be "because we aren't cool if we don't have them")... you know, this may not really be just a "web" thing....
It would be nice to exhaustively explore a tech before using it, but that's often simply not feasible due to lack of resources.
I suppose it depends on what you consider "significant" to mean. I have found close to 100% correlation between new technologies where I can understand the basic use cases and structure within a few hours and be moderately productive within at most a few days, and new technologies that have proven to be worth the effort in the long term when I've tried them. I can't immediately think of any exception to that rule within the field of front-end web tools I've tried so far.
I mean, that really ought to answer your question, but to be concrete: Never bet anything but maybe your startup on a tech that you can't find anybody else your size trying out. Try searching "$TECH sucks" and similar queries on the Internet. If you can't find anything, that's not a sign the tech is too awesome to have flaws... it's a sign nobody's using it! Of course, you need to learn how to balance the hype vs. the "sucks" options. The question is not whether somebody has something bad to say, the question is what bad things they say. Are they clearly using it wrong? Are they clearly using it in a use case the software doesn't even claim to support? Or... are they using it in exactly your use case in exactly the way you wanted to use it and encountered fundamental problems?
Even once you think you've settled on a choice, what other choices are there? The existence of a "good" choice does not preclude better choices.
If you do do a test deployment, don't fall into the trap of deploying at a radically smaller size than you need. If you're going to need the tech to work in clustered mode, for instance, don't deploy it to a single server and deploy three records to it. Deploy it in a cluster mode and load it up with 10-100x times the data you think it's going to have. You can't practically test the complexity of the app you wan to write without actually writing it, but you usually can test the size. Test your most complicated case; if you've got a web app and you want a framework to help you out, don't make the simple "user prefs" page, as soon as you can start working on the most complicated page in the site, which is probably the one that's the payload. Easy things being easy isn't an interesting test; check the hard things.
Find someone with a experience-hardened intuition to do this with you. Realize that any tiny issue you experience and can't get through now will become a large issue later. Realize that you generally always end up with some of those issues anyhow, so it's a question of picking which you go with. Don't underestimate the established choices. They're big for a reason, especially if they've been around for years. The new hotness will play up the old guard's flaws while minimizing their own. You can make anything look good by only considering the positives, you can make anything look bad by only considering the negatives. Always look at both for all options. Get that experienced person to help you through it.
For whatever task it is you are looking to do, figure out which problems you are most likely to have, and prioritize your analysis to focus on those. Do you know you need total CP consistency? Then you can quickly eliminate entire choices by whether they even claim it, and further eliminate more by checking whether they actually maintain it in the field on their user fora. Do you have price constraints? Bam, entire choices knocked out. I've never personally been in the situation where I got to the point where I needed to start kicking tires and I had a dozen equally-good choices; there was always a clear hierarchy.
And, in the end, do consider the joy-of-use of a tech... just don't make it your only consideration. An fun-to-use tech that completely fails to solve your problems rapidly becomes a nightmare-to-use tech anyhow. Ask around you about framework regret; anybody with a few years in should have at least one story of when they expected something to be awesome and it wasn't.
Even putting a week into something as important as "what database will we choose" can pay off huge, easily being the difference between project success or failure. You don't necessarily need to work everything out for months.
It isn't just a web thing, but it is way worse in the web world. How many of the cases you described were for web shops?
Where's Backbone gone? Or Knockout? Or Handlebars? Is it NPM, Bower or a mix of the two? Or etc. etc. Are you writing coffeescript still, why not typescript? Did you make an app in Durandal? Haha! Time for Aurelia!
Angular 1, one of the longer lived projects, is literally just being turned into a non-standard after a whole lifetime of about that of the family hamster.
So they're not standards, they're all today's hotness that won't be used on tomorrows projects.
It takes a couple of years for coding standards in new languages and libraries to even evolve, no-one knows how to use it properly to begin with and everyone makes a mess in a different way as they deal with the quirks and build non-trivial projects, but eventually a consensus is born.
In JS frameworks, just as that is happening, the whole thing is abandoned rapidly for the new hotness.
The JS community is massive and very good at publicising their tools, so there are lots of (very visible) options, and it can give the impression that everyone is constantly switching tools, but that doesn't mean you actually have to.
So it's useful for young, inexperienced developers. Do you kids really not have in-house coding standards anymore, or do you rely on your toolsets to provide that for you?
Odds are good that even if you are not a "young, inexperienced" developer, widely-adopted coding standards (that most frameworks probably use) have had more thought and reasoning put into them than you would ever be able to do on your own.
So I agree with your overall point of "don't just blindly adopt something", but the case can be also made for not naively doing everything your own personal way (including at the team/company level).
For example, "go fmt" exists for a reason.
If your own in-house developers, with full knowledge of the nature of their project and the kinds of requirements they're trying to meet, and with full control over their choice of tools and standards, really can't ever do better than some external organisation that is building a generic tool to cater to generic requirements and writing to general coding standards, then you should probably question the competence of your in-house developers.
This is not to say you shouldn't use existing material from outside your organisation if it's a good enough fit for what you're doing and saves time or otherwise has some tangible benefits, of course. However, your in-house team will normally have a huge advantage in terms of knowing specifics compared to almost any external equivalent. This is true whether we're talking about frameworks, coding standards, tools, or almost anything else used in programming.
The meme that anything written by a larger group of people outside your organisation is somehow inherently superior for your purposes to anything you could write in-house, and that any reluctance to use those external resources is inherently a case of NIH syndrome, just doesn't make any sense to me. There is no logical reason to believe it should be true since you're almost never comparing like with like, and I see very little empirical evidence that it is true in practice either, assuming reasonably competent and experienced in-house developers.
You, and my downvoters, all assume (naively) that any in-house standard must somehow be different than "widely-adopted coding standards (that most frameworks probably use)". Obviously, that need not be true, and in my limited 40 years of experience, it rarely is. Not sure how you even got there.
If you were implying that those two things might be identical then you did a bad job of conveying that (and then why even comment?)
This trend toward "frameworkfulness" probably started with OOP and Java in the mid 90s, and spread from there. Fortunately they seem to be realising the ridiculousness and gradually getting out of that mindset, but unfortunately other developer cultures like JS are now headed in that direction.
jQuery: library. (Others: D3, knockout). Salient feature: does not impose code structure or organization of code modules.
Angular and React: frameworks. Salient feature: expects adherence to module separation and code structure protocol. Like other MVC frameworks.
EJB: platform. Salient feature: provides entire terra firma and attendant oxygen for the entire solution. Frameworks and libraries are used on platforms.
It's true that the word framework is buzzwordy. If you look at the general interpretation or the most common usage of that term, you'll see that it does refer to some type of "boundary setting" type of thinking. To work within the confines of a frame.
So, IMO frameworks necessarily impose parameters within which to maneavure.
Edit:
I'd say the browser is the platform in the JS world. But analogies don't necessarily fold neatly.
No, it was already there with Smalltalk and C++, but millennials seem to have missed that part and everyone bashes Java.
This does not sound to me like they hopped on a bandwagon and wrecked working code, it sounds like they were trying to bring some fast and dirty code that they didn't like the structure of closer to a style that they were familiar with, which is reasonable.
Of course we don't know any real details, maybe the web boys really were a bunch of copypasta idiots that messed it all up - I've seen this scenario play out both ways, and the one thing that's for sure is that prototype engineers are always skeptical of work that other people do on their babies, whether they do it well or not.
If you haven't had the experience of maintaining multiple projects with some kind of consistency between them, then adding "complexity" (unit tests? really?) may seem unnecessary. I've had similar discussions/arguments with (junior) developers (or non-developers) and it's just a waste of time. If you don't have the long view, the whole discussion is moot.
Now, if those other developers created an unmaintainable monster, that's orthogonal; you can do that with any framework or no framework. You will always end up either A) creating a one-off framework anyway or B) creating a nightmare of inconsistency.
Edit: Also, I think it's somewhat amusing that you include jQuery right alongside vanilla JS without irony while denigrating more-modern frameworks.
I stopped reading after that, just sayin.
Inexperienced programmers can make bad decisions in any setting so I don't think this has anything to do with frameworks. I would be heavily against any decision that bloats a codebase 7 times its original size unless the pros heavily outweighed the cons.
People tend to associate poor coding mostly with spaghetti code and copy/paste everywhere, but poor coding also includes adding useless tests and abstracting too much.
I mean, your TCB already included the OS, the OS update manager and the browser, but still...
Frankly, build systems like grunt and gulp are not necessary for node or frontend development. You can write the same or much less code, with much less domain knowledge, and accomplish the same thing using npm scripts and plain JS files.
For example I wanted the ability to report content on a page. So I created report.tag, 40 lines of html, 30 lines of Javascript. Done. Then a button which mounts the component when needed. I like this way than using giant frameworks like react and angular.
If all it was was a chat app then angular was over kill.
Leveraging frameworks on projects for which they're unnecessary doesn't show that the frameworks are bad, just that the devs are bad.
The reality was probably that those "web-boys" have to maintain dozens of applications and so follow a certain workflow for all of those applications.
Many frameworks allow for easy and streamlined testing, are more reliable across browsers, allow for easy extensibility, and help you easily track data.
In the real world, people can't be expected to maintain dozens of custom tool chains and there aren't a ton of job postings for people who don't know ANY web frameworks/libraries.
By the way, as the nature of these messaging apps is mostly in async messaging, it proved quite hard to unit-test.
If your code had been as easy to understand as you say it is there would have been no need to re-write it.
Also, your acknowledgement that it was difficult to maintain makes my point for me.
> If your code had been as easy to understand as you say it
> is there would have been no need to re-write it.
I wouldn’t assume there’s any correlation whatsoever between the quality, readability, or maintainability of code and whether it gets rewritten when a new team arrives.
Sometimes, that’s just what happens, whether we think it’s justified or not.
And that's perfectly valid. In fact, it's one of the best reasons to use a framework.
If I hand-roll my application with a cobbled-together framework, I am the only one who understands how it works. Even if I'm a pretty great developer and write very clean code, there is an inherent complexity cost to any code—whoever comes on board will have to learn how I'm tracking state, managing the DOM, etc.
On the other hand, if I just wrote it in React I could be fairly confident that another web developer could pick up the project and easily understand how things are working with minimal effort. They've likely already paid the complexity cost of understanding React.
That's what the article and OP entirely miss. We don't use frameworks to improve the speed of the application. We don't even use frameworks to improve the speed of development. We use frameworks to improve the speed of understanding.
Every team has their own reasons. You have yours, I have mine, but they’re the team’s reasons.
By the way...
> If I hand-roll my application with a cobbled-together framework
But sometimes, people just write a single app that does just what it needs to do without a lot of abstraction and indirection. They are ruthless about YAGNI. And the result is very easy to understand, because the cognitive load of reasoning about an app that is just an app is no greater than the cognitive load of reasoning about an app sitting on top of a framework you have internalized.
The problem is when people build their own framework and then build an app on top of their own framework. Sadly, this is usually the case, as they fall in love with building infrastructure in the hopes that future features can be added with just one line of code or dropping one file in one place.
That kind of thing is quite properly the domain of a framework, and very, very few teams should be writing frameworks.
tl;dr Let’s not set imply a false dichotomy between writing your own framework and using an off-the-shelf framework.
I wanted it to be rewritten before I wrote the first line of code. My trust went to someone who does full-time web development (I'm alround, full-stack).
You wrote a POC of unmaintainable code, and then some junior web devs butchered your project because it was undocumented and "understandable" to you only.
Get off your high horse.
If I was your boss I would be asking why you didn't speak up earlier, and why you didn't document your work better.
The project wasn't a failure at all. Currently being used in a production setting for communication in and between hospitals and medical labs.
Going from "not written to be easily maintainable" to "unmaintainable" is exactly the problem you see very often. Instead of investing a bit of time to learn things and make them incrementally better people cry foul when it's not perfectly to their liking (i.e. if they haven't written it themself) and tell you later when you ask them if that monstrosity they've written was really necessary - which probably doesn't work and/or has bugs which had been already fixed in the original codebase - that it was "unmaintanable" and so they "had" to rewrite it.
If there's no guarantee, how do we ensure that we don't create an even bigger nightmare code structure when using frameworks? This risk has to be understood before framework choices are made.
I'm generalizing, but frameworks reduce program complexity when applied in a thoughtful way to a suitable problem space. If you adopt a framework that isn't suitable to your particular problem, or adopt one that is suitable but fail to learn to use it properly, you will probably increase complexity.
When I said that it was a failure on the part of the person, I meant that there is a possibility that the people responsible for rewriting probably did a bad job at choosing a framework for their problem (perhaps it was too big and complicated?), or maybe they chose a suitable framework but didn't do a good job of implementing it (perhaps they tried to code in their old style?).
> If there's no guarantee, how do we ensure that we don't create an even bigger nightmare code structure when using frameworks? This risk has to be understood before framework choices are made.
This is obvious and I don't believe I made any argument to the contrary. Just like choosing any tool, one must understand it first to make good use of it.
Would it be fair to say you didn't understand the web frameworks very well?
I'm not sure that lines of code is a great measure here. What about test coverage? Maintainability? NPM is a package manager - anyone would advocate using that over manual dependency management, no matter what environment you're programming in.
It sounds like you had an expansion of the web team. It only makes sense that you'd standardise things when that happens. It just happens they weren't standards you are familiar with.
There's a perception among "server boys" (or are you "server men" looking over the "web boys"?) that the web doesn't deserve 15,000 lines of code. It's a lot more complex than you give it credit for - or would you be happy to write all your backend code in C and C only?
This is precisely the kind of generalisation that many experienced developers will rightly object to.
There is absolutely nothing unreasonable about manually downloading a specific version of a small number of self-contained libraries, and just using them either directly or integrated into some sort of bundling process. This has significant advantages in terms of simplicity, reliability, and transparency compared to the who-knows-what that NPM and its ecosystem will generate only to achieve the same end result.
You only really need to use NPM if you're working with lots of small packages and/or packages that have many small dependencies of their own, but either way, now you have two problems.
I'll probably do that in my "utility" library to keep my actual application project as light as possible. But I'm not going to add a dependency for 4 lines of code, as much as I may appreciate the effort you took in providing them. See https://github.com/btomala/akka-http-twirl/blob/master/src/m... for a recent example.
?! What web frameworks kill accessibility, exactly?
Furthermore, using a virtual DOM is not the purpose of React. Virtual DOM is merely a part of how React works. People don't buy cars to get an engine. They buy cars to get around places. People don't use React to get a virtual DOM engine. People use React to make building and maintaining apps easier.
Let’s say you decide you’re smarter than everyone who worked on React or some other library, and you can build your app without them. Great, if you’re building a small app this is probably just fine. Scale your app up, however, and you’re going to end up with a framework anyway. The only difference is that it will be your own framework, and chances are it will be difficult to understand, hard to maintain, and full of bugs, and you may even be stuck with it because of how much it would cost to change.
Using libraries, or even frameworks, is how you leverage the collective intelligence of dozen, hundreds, or even thousands of very smart minds (a few of whom might even be smarter than you). Especially proven ones with many successful projects using them.
You’re welcome to give this up to be a cowboy, but me: I’ve been there, thought I was that smart, and realized how much better off I am by not trying to reinvent the wheel every time.
The rest of the article mentions other points which don’t seem particularly related to framework decisions to me at all, so I’ll let them be.
The way I look at it:
- If you use a library that augments your style of work but doesn't change it then it's a library. Maybe a tool.
- If you use a library that replaces or changes your style of work then it is a framework.
React is a framework in my opinion. It can be used as a library but it's almost never used that way; most people incorporate JSX and much of the virtual dom into their workflow.
But this is pedantic. I feel comfortable I could make an argument for almost any JavaScript library being a framework as well as not being a framework.
> Scale your app up, however, and you’re going to end up with a framework anyway. The only difference is that it will be your own framework, and chances are it will be difficult to understand, hard to maintain, and full of bugs, and you may even be stuck with it because of how much it would cost to change.
While correct I cannot disagree with you enough. If you write clean, as-simple-as-possible code with clear separations of concerns it's dead easy to maintain and not necessarily "full of bugs". It really just boils down to how well a developer can architect an application to determine if their own framework is going to be a huge bottle neck / issue or a breeze. I've been through both :)
> You’re welcome to give this up to be a cowboy, but me: I’ve been there, thought I was that smart, and realized how much better off I am by not trying to reinvent the wheel every time.
I'm not a fan of this sentiment. If it makes the most sense (and it doesn't always) I try to avoid using frameworks but I would hardly call myself a cowboy (though perhaps I will going forward, ha).
The DOM API, as this article shows, provides quite a bit of functionality that many popular frameworks / libraries provide and as long as you don't need to target old browsers you're fine here.
Yes, angular and react do a lot for you but you can still write effective web applications without them with minimal "reinventing of the wheel". Just because someone provides a way to do X in a framework doesn't mean it's not easy to still do X without a framework. Many times the bulk of the framework's capabilities are supporting its own, specialized workflow that isn't always necessary.
I was much more in the camp of 'use/learn frameworks as much as possible for productivity', started a new job and have really become much more moderate on the subject. There really is a balance and the type of application you're building matters. The best thing about writing your own framework is that you're able to structure to fit the exact needs of a business. The productivity gains can be extremely massive as well. If you can build a custom system that scales to your needs, it can certainly be worth doing. The flip side of course is that you may ( Probably? ) have a fairly simple/basic product. If you don't have heavy business logic to model, the heavy automation and tooling that is available can be a damn good way to go.
> If you use a library that replaces or changes your style of work then it is a framework.
I don't think that one's style of doing things have any merit in classifying what 200 people at Facebook had built. (Perhaps someone likes two-way binding. Backbone would be a library/tool and any Virtual DOM implementation would be a framework?)
Yes it’s pedantic and arguments could be made either way. However my experience is that people comparing frameworks are often looking for something comprehensive—that solves (or makes provision to solve) a majority of the challenges they will face with a particular stack, so they can focus their energy instead on the problem domain.
React is far from this. It’s an important but relatively incomplete piece of the puzzle. React apps use a lot of other libraries to provide the missing pieces. A framework, to me, would be a system that ties these pieces together to solve for a large class of apps.
> While correct I cannot disagree with you enough. If you write clean, as-simple-as-possible code with clear separations of concerns it's dead easy to maintain and not necessarily "full of bugs". It really just boils down to how well a developer can architect an application to determine if their own framework is going to be a huge bottle neck / issue or a breeze. I've been through both :)
In my experience the number of developers that can do this successfully is relatively small. It requires a lot of experience and skill. Even if there were a large number, why reinvent the wheel for each project?
> I'm not a fan of this sentiment. If it makes the most sense (and it doesn't always) I try to avoid using frameworks but I would hardly call myself a cowboy (though perhaps I will going forward, ha).
Yes—be skeptical but also practical. Not every problem needs a framework but would your problem benefit? If yes, why not? Especially if you’re adopting something proven.
This is especially true if you’re writing something new and therefore still learning about the domain. I've seen a number of cases where a team decides against a framework, ends up with a mess on their hands, and later switches to one of the frameworks they were originally considering (at great cost).
One case in which it may make sense to write your own framework for a large application is when the app is relatively stable (therefore you can leverage your experience building it) and existing frameworks don’t meet your needs.
> The DOM API, as this article shows, provides quite a bit of functionality that many popular frameworks / libraries provide and as long as you don't need to target old browsers you're fine here.
This is true, although sometimes impractical in enterprise software. When jQuery came out it was a godsend in it’s ability to erase cross browser compatibility concerns. As time went this became less of a problem and now I no longer use jQuery. You won’t find me arguing to stick with something that used to make you more productive where better alternatives are now available or ready.
> Yes, angular and react do a lot for you but you can still write effective web applications without them with minimal "reinventing of the wheel". Just because someone provides a way to do X in a framework doesn't mean it's not easy to still do X without a framework. Many times the bulk of the framework's capabilities are supporting its own, specialized workflow that isn't always necessary.
I can say to sum up that this totally depends on who is working and what they are building. There is a ton of complexity that React and other “frameworks” abstract away for me. The core concepts powering these tools may not be that hard and perhaps more of us could take on the task, but the devil is in the details. Usually these libraries start out simple, but in the end it’s the edge cases and quirks that make them internally complex.
> I understand that React is only the view-layer, but in reality many of you are using things like Redux with it - along with other plugins. The result of that is a pretty heavy application.
You can create this on your own of course (and I have), but the solution of "just use the DOM" ignores an enormous amount of progress that React made with component design, not performance.
Its like the people who rail against static typing and like the flexibility of dynamic languages. They just don't know what it is like.
Ember (for example), takes care of huge swathes of complexity for you. I can't imagine trying to build a:
* client side router * data transportation/cache layer * view layer * model layer * build pipeline
... and more, in less code that just
`npm install -g ember-cli` `ember new my-app`
And then having a common app structure with thousands of other people that can provide help and insight.
You people really are kidding yourselves. I feel bad for whoever is paying your salaries.
You list a lot of things that a framework gives you, but they vary between the small (routers are easy if you can ignore #) and the things which you probably don't need but have been convinced you want by your framework
You are the only person working on the project and you are patting yourself on the back for writing "maintainable" code.
Bring 50 more people into the project and then lets talk.
You don't think that there are thousands of people who can provide help and insight into the standard Web & DOM API's? I mean, do you in all seriousness think that there are more people that can help you with React than it is that can help you with the Web & DOM API? Not to mention the standard browser libraries have decades worth of documentation and information about them, freely available.
> * client side router * data transportation/cache layer * view layer * model layer * build pipeline
Let's narrow that down a bit:
client-side router - There's examples online of a router that's 20 lines[1]
data transportation/cache layer - Umm, what? The browser already takes care of data transportation (also known as the HTTP protocol, WebSocket protocol or WebRTC - whichever floats your boat). Surprisingly, it also takes care of caching as well.
view layer - if you absolutely need one, here[2] - 2KB and has everything you need.
model layer - `class Model { ... }` and `let model = new Model('path/to/component')`. Simple as that.
build pipeline - don't really need to "build" thanks to HTTP/2. Otherwise if you want to transpile anything you could always just setup a single-line `npm run build` script.
> You people really are kidding yourselves. I feel bad for whoever is paying your salaries.
Why can't you try to have a friendly discussion instead of attacking on a personal level as you've done countless times throughout the comments. Nobody's pointing a gun at you.
[1] - http://joakim.beng.se/blog/posts/a-javascript-router-in-20-l... [2] - https://github.com/pakastin/frzr
Yes, 20 lines which you have to be responsible for and maintain... and changes over time add up to make it 200.
>The browser already takes care of data transportation ... HTTP protocol, WebSocket protocol or WebRTC
Yep, with boilerplate code that you have to write and again, grows as your use cases grow.
>if you absolutely need one, here (frzr)
Oh, some view layer some guy came up with 22 days ago... or something that has been working for a decade for facebook. I wonder which one I want to go with.
Tell us, because - as I am not Facebook - I couldn't decide without checking both, maybe making a simplified prototype of what I'm trying to accomplish and see which one fits the use case better. You seem to have another process?
Why can't you? Routers are easy; you likely don't need more than a few lines of code to accomplish most of what you need. Caching and data transportation is also easy and simple (there are a million cache libraries if you don't want to write a small one). Views and models have been done since the 90s and are relatively easy as well (in fact I wrote one in just a few minutes the other day to drop some dependencies from a personal project). Though models are not always the best way but I'm digressing.
Build pipelines usually add more complexity than needed in my experience. I almost always, eventually, nix whatever complicated build pipeline I start out with and go with something dead simple.
Most of this stuff has been done for over 15 years on the web. It's at the point where it should be mostly boilerplate / routine if you're not using a framework.
Router as in delegating a URL to a handler for that URL? I wrote one once … and it is deceptive and not easy; most of the server side ones that I've encountered (e.g., Django, Flask, nginx) do a poor job.¹
The naive implementation of a mapping of regexes to handlers is dead simple to implement, but not very ergonomic to really use. Something that understands that paths are hierarchies works a lot better. Then it's also nice to have something that can stub out a component to a variable (and preferably type check that), e.g., "/customers/:customer_id", and pass you "customer_id" after validating it to be an integer, a UUID, or whatever. Then you need the capability to delegate an entire subtrees to a subrouter, and maybe if we could just get some handling of delegation based on the method in here, but HEAD needs to be automatic…, and canonicalization of URLs would be nice too.
¹I feel like this is one of those things that until you've seen something better, you're still wanting the faster horse.
Yes, that is EXACTLY what many of these frameworks are.
If you can't imagine trying to build these things, why on earth should you be trusted to use these things built by others?
All of your comments in this thread are so unnecessarily abrasive. And you just continue to give off an unfounded and indefensible air of smug superiority, when what you're really falling back on is ... the ability to run a command that puts you in a padded room so you don't hurt yourself?
Here's my attempt: React is about making composable UI easy using stateless components which can still update fast because of the virtual DOM optimization.
(OK looking again you did say "functional" which implies something similar)
It's a bit harder to understand than the simple API indicates, especially coming from other kinds of stateful architecture. What I like best about React is how yoy can optimize stateless components incrementally, all the way up to where you're doing everything with raw DOM manipulation in the lifecycle methods. And how it's fast enough that you usually don't have to optimize at all.
The type A ones just gave up to the complexity and bury it with foreign frameworks.
The latter ones invent their own ecosystem. And are very productive with it. It's fast and beautiful. And you know every screw and bolt. There is a feature request? No problem, you know immediately how to solve it. I know many of them. And nearly all of them are the best I have ever known.
But here is the big "but". Would programmer type B want to work with a 2 year old project from another type B programmer? And there you have your answer why there is such a hugh appretiation for frameworks. Its easier to throw 10 programmers of type A onto the same project.
You're forgetting type C that don't know anything about existing frameworks so decide to reinvent the wheel by writing an unmaintainable mess of spaghetti code... I'm guessing type Bs are very rare. Once you've seen enough untestable jQuery soup you'll learn to appreciate frameworks.
I'm a type B. I've written entire systems from scratch that fit me like a glove. I could fix any problem in no time flat, and it was very stable.
But when it came time to have other people work on it, it didn't fit them like a glove. It barely made any sense to them at all. They eventually got up to speed, but they were never as productive in it as they would have been in a decent framework-based system.
I was actually quite happy when they decided to rewrite the whole thing... And then it turned out I left about a year later, so it was a good thing they did.
Sure!
A homegrown javascript ecosystem doesn't grow up in a vacuum. It may include smaller libraries that aren't as opinionated as this year's popular framework. It may draw inspiration from Backbone or Flux without using either outright. And it should follow familiar design patterns.
In fact, some frameworks start out this way (https://ampersandjs.com/).
Now, the answer you probably expected was "I'd want to see it first." And that's true, but that's also true with a framework. The things that make a project pleasant to work on - good architecture, docs, clarity - aren't guaranteed with a framework.
Seems like it's mainly a matter of balance between collaborative work easiness and individual work flow quality.
There's also the work avoided by not having to test code on different environments but after reading this thread looks like it's a minor advantage of frameworks.
Other companies juggle their priorities differently, and would probably not want to focus their efforts on replacing React, which has a small API, constantly-updated documentation, a team that responds to issues, and widespread attention and thus lots of discourse. I also think the React layer abstracts away complexity, trading total lines of code for cognitive easiness. Some teams have the business justification for doing things their way -- but I think most don't.
(And I don't buy the large teams can't adopt a self-grown code in the first place. If they're any good, they can. If they're not, then even their React and Angular skills will be bad).
Besides you know all your business logic code? That will be custom too, anyway,and they'll have to adopt it...
Average size for the most popular sites has actually grown to ~ 2.5-3MB.
And since they're the most popular, it shows that people DO wait just fine for them to load.
wikipedia: " collection of instructions that performs a specific task when executed by a computer "
We can do better than describing a JS Framework/Library, than calling it a program I guess.
You might not need a framework, but you'll need a structured approach to avoid those problems, and frameworks can help a lot with security.
Also regardless of what framework you are using you still have access to location.href, e.innerHTML, etc. I'm not really sure what you're trying to convey here but it's lost on me because, framework or not, all of these things still exist. Hell angular simply wraps location as do some other frameworks.
e.innerHTML = "<td class=\"" + type + ">" + value + "</td>"
d3.select(e).append("td").attr("class", type).text(value)
$(e).append("<td></td>").addClass(type).text(value)> None of those are "pwned" if you know what you're doing.
... can be rephrased as "All of these are still 'pwned' on a daily basis."
Because everyone is perfect, right?
I don't know if this person has even really scaled and deployed a web application that must work across several browsers - especially older browser versions. I always wonder that whenever I see people bashing frameworks. Like the author said, start with asking why the framework was created. Just make sure you come up with the right answer to that question next time.
1) Where are all the people hiring web devs who don't know a single library or framework?
2) Why do huge tech companies like facebook and google develop web frameworks if they're unnecessary?
I don't think he's saying hire web developers who don't use a single library or framework; he's calling for some perspective by looking at the latest state of system. He answered #2 in the very beginning of the article:
"React was created to solve the issues Facebook were facing with their massive amount of data, activity and size."
"They then went ahead and open-sourced it and released it to the public, where many developers seem to have come to the conclusion that “Facebooks’ solution to their problem is the solution to my problem”. This - in the majority of cases - is not true."
I found the article refreshing in that aspect.
No, I'm saying people don't typically hire developers who don't know ANY libraries or frameworks.
That's reality.
For the same reason you should write your own "framework": An internal 'framework' is nothing more but a certain way of structuring your code, so that it works for you and your problems, which no one ever argued against. It gets far harder to make that case when you say "well, all my problems can be taken care of by popular framework of the day" - now you can only solve problems well which fit the frameworks model. And if your problem doesn't fit the model you start writing around the framework, so in the end you have written - again - a custom framework, which only in name resembles the one you started with.
Plenty more. You'll notice that a lot of what is written in Angular by Google tends to be their newer platforms/platforms being re-written while Angular was out/coming out. Older products like GMail are extremely complex and transitioning to a saner, more streamlined way to scale those applications usually stems from necessity, but rest assured they use their own framework (take a look at all the gnarly tags and events bound in GMail).
I don't personally use Angular.
Plus I like being employed so knowing frameworks and libraries is a must.
The article is full of sentences like: it's true React is fast, but basic Javascript is even faster. Duh? It's true React is quite small, but if you don't use it, your site will be even smaller. No sh*t Sherlock?
React was invented to simplify the program structure of medium-to-large applications by replicating the successful data flow of the Web itself: namely, the state of the application is in one place only (the URL in the Web, the state object in React); HTML is generated from that state using one set of reusable and composable templates; and crucially, user events only affect the state, not the HTML itself.
Personally, I'm going back to basic HTML + progressive enhancement, for a variety of reasons. But React is the sanest of all the client-side architectures I've seen so far, including bare-bones web api.
No framework -> Backbone -> Angular -> React -> No framework
We should be back towards using a simple MVC skeleton by the end of 2016.
(fan of modern frameworks btw, just saying vanilla MVC is kewl too)
Not in my experience. I've seen frameworks come and go like that over the span of 15 years and teams rewriting for the new "hotness".
So, one year they do Angular, then Angular 2 comes out, invalidating a lot of their code/experience, then they get to React, then they're told that they should structure it like Flux, then Redux comes along, and who knows what in 2 years.
Just imaging that merely 5 years ago Backbone was the preferred edge JS framework. In fact wasn't even that at that point -- it was only just released 5 years ago...
But eventually they'll bit rot, and all the new features, and community support will move to 2 -- and you're stuck with the worst of both worlds: a framework with stuff you don't need AND with few left to maintain it.
Please keep in mind that my intent is not to mock you or your framework of choice. My goal with this post is to try to inspire you to try building something with the native DOM and Web API and see for yourself. Some may enjoy it, others may not. And if you feel comfortable with your current way of building your web applications with a framework, that's completely fine.
Also, please keep in mind that I cannot address every use-case in a single post. As much as I'd like to, that's going to take way too much time.
However, in your update you are suggesting to use Object.observe as a simple alternative to React. I looked it up and https://developer.mozilla.org/en/docs/Web/JavaScript/Referen... says it is deprecated and even removed in some browsers.
Using API's that are not widely supported and then not relying on a well supported framework to abstract them, seems to me an even worse maintenance nightmare than sticking with a Framework.
- follows the widely accepted format of "rant about some popular framework/library/language by mimicking a tiny portion of it"
- uses shock factor to get the reader's attention
> React, Virtual DOM, Webpack, TypeScript, JSX… HOLD ON! Let’s pause for a second here and think.
YES, you don't always need a framework/library BUT if you want to build something maintainable & scalable, it's better to opt for battle tested approaches (which is especially true when it comes to the web, having browser quirks)
So, having started outside the web world, I really don't understand the hullabaloo. It reminds me of a certain point in Windows development, when shareware etc. was a thing, but download speeds, RAM and disk space were still low. Creating smaller programs was a thing for some developers, both for distribution and an alleged "bare metal" feel (whether they were that much better than e.g. a big package including all of Tcl/Tk is another matter). Programming Win32 with assembly. The ATL. Compressed executables. People recomming a new weird command-line oriented operating system made by some crazy Finn.
Both ATL and Win32ASM bring in yet another feature: Programming in my favorite, possibly new idiom. Another reason for creating these mini-frameworks in the JS world. All glued together by slapdash micro-libs and utilities, that might be there one day, might be gone tomorrow.
I might finally be getting old and cranky, but I actually feel that some bigger frameworks wouldn't hurt. Some kind of standard library included, given that this won't come out of standards or the global community. More opinions. A set of standard components/widgets, not just three score methods of displaying them and two score of connecting them to a score of different backends.
Go all in: If you really want to just use the web browser as a delivery system for all kinds of GUIs, give me a GUI framework. I think that strangely enough ExtJS used to have more competition there...
Either that, or make more use out of the old-fashioned tenets of HTML, do more with text and links and stick to progressive enhancement. The middle ground of shiny but tiny GUIs that seems to be the rule for modern "SPAs" is neither fish nor flesh. (And I don't think that "isomorphic apps" is the answer here, either.)
Flexbox is definitely a lot nicer than the Bootstrap column system though.
> HTTP/2 is widely supported by web browsers already. At the time of writing, 70.15% of visitors has support for the updated protocol.
Oh yay, so only another 5-10 years until I can use it.
As for the article itself I was a bit confused by it as from the clarifications at the bottom it makes the assumption that the reader is building a trivial application with minimal UI state. There are thousands of boring companies like mine not named Youtube or Facebook building complex web applications and it wasn't until I read the clarification at the bottom that I realized the whole article wasn't aimed at me.
Contenteditable is so annoying that the first thing most rich text editors seem to do is make their own selection state manager, because the native range implementation in the DOM is crap. Medium in particular pretty loudly got rid of it entirely, and that's the direction most modern web-based rich text editors are going.
So. The best thing to do here is find some kind of framework that helps you map from user intent into mutating a data model, and a separate way to translate that data model into the DOM. This sounds like a framework to me, and it especially sounds like one if you want it to work on lots of platforms.
Similarly, sure: I don't need a framework to do DOM manipulation. But I've been using angular (1.x) for a few years now, and I can say: it makes life a lot easier. If I don't have to debug lines of javascript looking for where different elements get injected into the DOM, I'm happy. I can just look at the template file for the html code I'm editing and see where classes get programatically changed based on state, not because I'm deep inside some MutationObserver, but because I can read an ng-class directive. Easy pie.
I sure don't need a framework. I could also program in ones and zeroes. Speaking as someone who's been doing web stuff since the 90s, where the first framework I ever wrote was a bunch of DIY C libraries to make writing cgi-scripts easier, I can say with all honesty: using a framework makes life easier.
Sure, it's annoying to learn, and sometimes the opinions of the framework are different from your opinions. That's why I use angular instead of ember (because I'm not a rails person, for the most part). Take your pick, learn it well, and it will make your life easier.
And if you're that worried about the weight of your library, stop loading so many hero images uncompressed.
(I will grant edge cases where library size is a big deal, but it's more of a premature optimization thing in most places, especially now that tree shaking is starting to make its way back into our build tooling).
I have a few small personal projects that I haven't started due to lack of desire in building the front end I want, after reading this I'm going to give them a shot and see how far I can go with out all the goodies!
If I can recommend a js framework so flexible it feels like a non-framework I'd say go and learn Backbone.js It's like a flat green Lego table, no assumptions, just structure.
Backbone allowed me to write cleaner code without forcing me to do anything. I still use backbone today. The code tends to be very verbose, but the trade-off is that it is not heavy handed. I never have to "hack" around backbone, it just gets out of my way when I want it to.
This fits my personal preferences, I prefer simple, verbose code. I also tend to prefer lower-level to high level. For example, I don't like ORMs. For me, it is easier to explicitly express how I want the data to be indexed and move in and out of a database as opposed to have an ORM manage it for me... because if it doesn't do it right, its very difficult for me to learn how to get the ORM to do what I want it to do. I also prefer more keystrokes and fewer "things to have to know about" to fewer keystrokes with many things going on behind the scenes that I cannot see. I think I may be in the minority in this respect?
I understand that there may be better frameworks now, but I feel I need to commit to something and stick with it, I think the cost of re-writing things all the time is too high. I think its faster in the long run to use an old framework that's 50% slower than switch to a better framework every two years.
For reference, this is the main project I use backbone on: https://demo.enterprisejazz.com/
Exactly. So, unless it stops running on modern browsers, the code should continue to execute and provide a complete solution. Although, I do try to keep Backbone versions up to date.
I also plan to continue using Backbone but I do want to learn a 'view' tool to improve performance of UI-rich apps. React seems too big and complicated, I am more inclined towards vue.js or mithril.js.
I checked your demo, in case you have not done so already here are 3 tweaks I've done to make Backbone run faster: - Select el already on DOM for a view's el instead of render/append. This is a huge performance improvement. - For big collections use plain JS array instead of Backbone native collection. You'll trade some methods for performance, but such methods can be re-implemented with Underscore. - Ditch the router if you need dynamic routes.
Here's an experiment of a classic listings app. After selecting a city, 5000 random listings are loaded at once into a JS array, after that I use Underscore for search/sort. Records in this example come from a static demo file. A red warning pops up with total download time and total processing time (lapse from download ready to array populated and ready for use). When I used Backbone collection processing time would be between 5-9 seconds (depends on processor speed).
When first learning backbone, I played around with the router, but I don't use it at all now. It was pretty hard for me to use and didn't seem to have much of a point. I suspect for many use cases, if you really need the url path to change, reloading the page from the server would be fine. But of course my perspective comes from only the use cases that I've worked with.
I actually mostly don't use backbone to organize the data, mostly only to display the data. The demo you looked at actually has little mini database implemented in the background using arrays and objects (used as maps). I mostly use collections for things that go right on the screen. I also (mostly) don't use backbone's ability to sync data with the server. I have a module that uses Jquery's Ajax for this instead. The reason I don't use backbone for this is that I found their way of doing it breaks down with more complex relationships within the data.
I mainly use backbone as a utility for message passing (update a model and one place, and messages are passed so everywhere else it is displayed updates also). And for organization: the views, pieces of the DOM within a view, and events.
Also, I use Marionette.js, not pure Backbone.js
...I'm not trying to say my way of doing things is the right way, just relating what I do and why for discussions sake.
Oh, and I looked at your demo. That is really cool. That's really fast for so many records.
Bonus: you get HATEOAS without knowing what HATEOAS means.
Seriously. The javascript world is INSANE. All these frameworks and few truly need them... node.js package management is a mess... yet how many of these coders will take the time to learn real ES5? It really isn't that hard of a language.
I feel like calling oneself a "javascript" expert practically requires knowledge of a framework or too. This is saddening, because Javascript itself is a rich language with a ridiculously fast runtime, yet everyone wants to work with a framework when a head full of sound theory and experience will do :/
And frankly, a significant portion of jquery usages are a very limited set of functionalities: selection, class manipulation, some visible on/off, AJAX and promises. A lot of those don't necessarily need jquery[2]. Some hard-core guys go so far as to separately download only modules[3] which works.
Honestly, I wouldn't mind calling a significant portion of jquery to be "pure javascript" as it lets me not worry about browser compatibilities and pleasant stuff that should have been part of standard library. ES6 is supposedly fix most of the complaints, but whether browsers will support them or not is a different question.
[1] https://mathiasbynens.be/demo/jquery-size has a nice tabular info on how large jquery file sizes were.
[2] http://youmightnotneedjquery.com/ is a widely cited source.
[3] https://github.com/jquery/jquery/tree/master/src, go nuts.
When jQuery launched, it appeared on Del.icio.us and Digg, for context of its era: https://jquery.org/history/
(I don't consider jquery a framework, though you can use it like one. Back when browser compatibility was a much larger headache it was a requirement for being productive, but nowadays most browsers implement ES5 reasonably uniformly. Particularly notable are its succinct shortcuts for CSS manipulations, AJAX, and running code on-page-load)
The only real gotcha is that jquery DOM manipulation is not really compatible with native DOM manipulation, but you can get to one from the other
Re: overhead criticisms: the base jquery "runtime" is a pretty reasonable size for the functionality it provides, and the accoutrements are completely optional.
MutationObserver for UI updates + Fetch API for networking + History API and a custom router for routing + CSS for animations + HTTP/2 instead of Webpack + npm for building + JSPM for package management + multiple polyfills for browser support for all this
Besides not having a name and a dedicated site, how is the above any different from using a framework? Once you've worked out how to get all these things to play nice together, are you really saving any time from just using an established framework that's done the work for you in the first place (i.e. they'll use some of this stuff under the hood already)?
Just because you're leaning on native features instead of library features doesn't make it any different from using a framework. At least with an existing framework you know it's battle tested, has good documentation, has an active community and is easier to maintain for new programmers on the team.
Abusing MutationObserver to get "easy" 2-way data binding is precisely the sort of antipattern that React & Friends would have discouraged.
You don't need Gulp/Grunt/etc for 90% of the stuff I've seen it used for. They could be replaced with a Makefile plus a bunch of standard unix utilities.
You shouldn't have to install 90 libraries in order to build/install/run your program.
If we're lucky, maybe we can come up with something lighter weight (conceptually, and in terms of build tools needed, as much as in byte size) that is closer to the built-in browser API. I definitely don't feel like I can do what I need in a sane way with nothing but the browser API though.
There's the whole side issue of progressive enhancement and/or making a non-JS version of a site, but I feel like those ideals are now dead- whether it's due to it being unfeasible, unaffordable, or something else.
On the flip side, government sites are (or at least should be) developed with a high degree of accessibility in mind due to laws that typically prevent anything less. Their reach is much higher and their audience is potentially every citizen in their jurisdiction.
I would still like all the core elements of a decent JS project such as package manager, bundler, templating BUT without the overkill of a new framework. A project template that allows you to simply write HTML, CSS and JS modules in an organised fashion.
A reference to a Github repo or online doc would be awesome. With so much JS news and information these days its really hard to find any info without the words react or angular or whatever. Appreciate any help from you knowledgable folks.
Enjoyed this article. I like JavaScript, I use it almost daily, I'd like to learn React or Angular but just haven't had the real need. For the amount of JavaScript in the apps I build there just doesn't seem to be the payoff. I did venture into npm. What a nightmare of goop and time wasting. Although there were some cool utilities the amount of time setting up and dealing with in most cases didn't really pay out.
Don't manipulate the DOM. Why not? Works fine for what I do. Maintainability. Maybe. But well organized code is well organized. If there were a lot more of it this probably becomes a valid point but JS doesn't do everything in my apps. It does the things JS was originally designed to do.
I figure when the dust settles I'll probably dive into a framework. But right now stored database procedures, database triggers, a light Flask/Bottle layer and judicious use of well organized jQuery/ native JS works really well and doesn't have a bunch of unneeded parts.
Then again I'm still using Slackware. I like things simple. The less abstraction and "helpfulness" between me and what I'm trying to get done the better. Simple, powerful, modifiable tools without a lot of glitz and overhead are my preference. I mistrust black boxes and complexity. Maybe React is the kind of tool that could be useful... don't know. Might look into at some point when I feel it's reached puberty.
Now let's add Javascript to the list.
There may still be things that can not be achieved JavaScript, but aside from those cases, I would even add "you (probably) don't need JavaScript".
As soon as I saw this, I knew there were limits to this author's knowledge on the subject. React was a requirement for the low-latency UI we built for a major commercial app and without it (or a similar library) the user experience we shot for would have been impossible.
React exists to make complex UIs easier to build and maintain.
Being able to just write the code once to render a UI from some state and then just reloading the entire UI when the state changes is an incredible simplification of your code.
That the author kind of misses this point makes me pay less attention to the rest of the post.
Don't get me wrong, I'm not a React die hard but I definitely do like that it exists, and I understand where it fits on the library/framework spectrum (somewhere inbetween knockoutjs and angular) -- and don't try and use it when I shouldn't be.
I really like the article, but I'm not sure how else you're really going to do it. You could have magic functions that get called like in Qt (draw(), mousePress())* or that clunky Microsoft C++ framework whose name is escaping me (OnPaint(), OnMouseDown()), but behind the scenes the windowing systems is going have to have a big case statement of: in case repaint call repaint(); in case mouse down call mousePress(); etc. Win32's WndProc just made you write the case statement yourself instead of looking up the documentation to see which magic function you need to override.
I'm a JS framework hater--I've never used any, but I figure if they have a new one every year, and all the frameworky-looking websites are slow, there's got to be a better way--but if React is basically WndProc then at least it's on a solid foundation.
I'm sure the names of these functions are wrong
* React is generally considered to be "just" the view layer. You feed data in, and based on that data, return what the current output of a given component should be. It does include a per-component state feature, which can easily be sufficient state management for a smaller app.
* Redux is just state management. Put all the write logic into a single "reducer" function structure, and the only way to run any of that reducer logic is to call Redux's "dispatch" function with an object describing the action that took place (such as `{type : "ADD_TODO", text : "Buy Milk"}`. That's where the switch aspect usually comes in, similar to WndProc.
* There's "official" bindings to hook together React and Redux, but also bindings for a bunch of other view libraries as well (Vue, Angular, Mithril, Deku, etc), and all they really do is subscribe to Redux's state change callback and pass the new state along.
For what it's worth, my last year of learning React and Redux has already drastically changed how I think about programming. It's a great first step into functional programming and thinking about things in terms of state and output.
And yes, an article can be both totally wrong at the beginning AND totally correct later on (or any combination of correct and wrong along its length).
Too bad. The author addressed everything you said. You just didn't read past the sentence you quoted.
Nowhere does the piece imply that you should render every state change server-side. In fact, it goes on to show, with specific examples, of how you can get data-binding and partial-update behavior with web-native APIs. The argument is that most people don't need React, not that they don't need AJAX or data binding.
The middle paragraph is helpful and fine, and the comment would have been much better with just that.
"That the author kind of misses this point makes me pay less attention to the rest of the post."
If they had read the rest of the post, they would have seen that their argument was addressed.
You're being unfair here. The top-rated comment is from someone mischaracterizing the piece, saying he didn't read it...and you're calling me out for pointing that out.
I admit that the last line is unnecessary. I'll remove it.
The argument that it'll take less time to develop, document, and test your own implementation than to take advantage of the React ecosystem is clearly untrue.
As the public demands higher quality images and video, code weight matters less and less. If you're not serving up 3mb+ of high-res images and/or video and making multiple AJAX calls, your site is highly specialized and outside of the mainstream. It's not an insult or a judgement, it's an easily verifiable fact by looking at Alexa ratings.
If you need to save 50-100kb that badly, use a slightly smaller image file or a slightly shorter video, don't add hundreds to thousands of hours of dev time. And if you're developing for mobile, do as much server-side rendering as you can and add a debounce for potentially costly operations, it's really not that hard.
I disagree that the author addressed everything I said. He mentioned two-way data binding using mutation observers. That's not the win you get with react. React isn't about 2-way data binding - its the opposite - unidirectional data flow - which massively simplifies the mental model of how your user interface works.
Horses for courses. The author is merely making the argument that you don't need react, and the GP comment didn't bother to read the argument before responding.
http://etg.dek.im for site
http://github.com/serprex/openEtG for source
It does a lot of dynamic content generation, which dom.js has proved sufficient for
The best thing is to try and use minimal frameworks and libraries and justify every single one - Which I'm sure most devs already do. jQuery is still rather justifiable. Yes, you can replace functions with JavaScript today but you'll end up with similar looking functions.
I recently added Transit to animate using CSS3, the alternative would be to write each animation effect I use in CSS3 down to the duration! If I need to change the ease I spend 5x the time doing so - From a devs perspective no, just no.
I don't really need a smartphone, but it is quite useful.
I'm sure your clients and your family will love that.
You don't NEED a framework, just like you could theoretically build a car from scratch.
If your app isn't complex enough to merit using a framework, then you aren't really building something worth talking about.
Frameworks do exactly what they say, provide a common framework for your team to work off of while they build a complex application.
I feel like most of the FUD around JS frameworks comes from simple people building simple apps and wondering why everything needs to be so complicated. Frameworks enforce structure, which becomes more and more important as your app grows in complexity.
Frankly it would be great for me if this train of though picked up steam, plenty of contract work from companies who can't maintain their "homegrown" frameworks anymore.
You're glad you don't work with people who weigh up the list of possible solutions based on the specific problem? You're glad you don't work with people who care about performance, size and redundant code? You want to work with people who don't think, who don't question implementation?
Thats pretty dumb isn't it. If someone has an alternative solution and a sound argument to back them up, your response would be 'I don't like the way you think'.
But I guess projects are only worth talking about when they are incredibly complex. A simple website taking 10,000+ hits a day isn't worth squat unless you have a big JS framework under the hood. Complexity = value, not users, not the UX, not the support, not performance, but COMPLEXITY.
Gjolund, states that he is glad he does not work with people who think like this. He goes onto mention that projects that have limited complexity are not worth talking about, thus the only factor in considering a projects worth is its complexity.
If layers upon layers of frameworks really were the best approach for complex applications then why can't people get behind one clear winner? Why does there seem to be a new framework popping up all that damn time? How much money has been lost simply keeping up with the artificially hastened pace of change?
Now, I personally have nothing against frameworks individually, but collectively people seem to pile them on top of each other. One is enough -- the beauty of web standards is that there is a common language that one simply needs to speak to access.
You are profiting from the community's collective lack of technical rigor.
People come to me because they acknowledge that they don't understand the problems they are faced with, and I provide maintainable solutions that work for years after the contract has been completed.
How?
I choose a widely adopted framework that is suited to the task and follow the best practices of the community that developed it.
That way when I leave people don't say my app is "A spaghetti be-spoke js app" but instead "Its an angular/ember/react-redux app." See the difference?
One is the opinions of a single developer (or small team), the other is the culmination of hundreds of open source developers working together to solve common problems in a maintainable and performant way.
How does a LAMP/RAILS app share server side rendering code with the client?
How does a LAMP/RAILS app share data models between the server and client?
How does a LAMP/RAILS app provide search engines with indexable dynamic pages?
How does a LAMP/RAILS app preserve client state between page reloads?
How does a LAMP/RAILS app synchronize client state between multiple connected clients?
Your lack of experience working in a professional front-end environment is telling, and is the source of your confusion.
I would think those who don't like frameworks end up building one for themselves and decide to share the correct way of doing things without all the clutter found in other contenders.
As opposed to the unemployed people?
"You people really are kidding yourselves. I feel bad for whoever is paying your salaries."
"Honestly, it just sounds like you are bad at managing your own software projects"
"I'm really glad I don't have to work with people who think like this."
"Both are signs of inexperience."
"I guess I won't be hiring you then."
------
If your coding skills are as big as your mouth you must be a kind of coding god.
I have had lots of these conversations with other people who think they are good at what they do.
This line of thinking kills companies, because the prototyper they hired for their "MVP" doesn't like frameworks. A year later he/she is gone and I'm rebuilding their app as an angular app.
You don't have to agree with me, but I am right. Millions of of dollars in contracts and a resume full of happy returning clients says so.
If people choose not to listen to what I have to say it has no impact on me at all. I will continue making a living off their mistakes.
They tell me that you can cover the tracks of your desasters long enough to move on, so that problems surfacing later are attributed to the maintenance programmers and not you, even if your "great" choice of frameworks were the real reason.
That's the very mentality that gave us J2EE crapfest and poisoned JS.
The idea that a complex app requires a kitchen sink approach and framework-itis...
Its not a "kitchen sink", its scaffolding. If you don't understand then you are either writing huge amounts of documentation and test code for your custom solution, or you are acknowledging that your app will be unmaintainable once you leave your position.
Both are signs of inexperience.
Structure is the job of the lead programmer(s), not some third party framework developer. And it should suit the specific job.
It's as if we forgotten that programs have to be designed with an overall architecture based on our business, and instead just download off the shelve scaffoldings and try to adapt our business logic around their design.
You know that Joe Armstrong quote about OOP?
"the problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle"
Well, it's the same with frameworks. You wanted a router, a template engine, and a few more pieces, but you go that, a banana, the entire jungle, and a mustachioed dictator telling you how to do things.
>If you don't understand then you are either writing huge amounts of documentation and test code for your custom solution, or you are acknowledging that your app will be unmaintainable once you leave your position.
It's as if we've forgotten the existence of libraries and APIs, of which there are like 200.000 in npm, and 50 of them are also really good.
>Both are signs of inexperience.
Some of the most experienced programmers, of 20+ years of career of successful projects, don't trust frameworks (and surely neither the "framework du jour" of JS, nor the "framework that ate Cincinnati" approach of J2EE of yore).
A competent lead programmer will choose a structure that adheres to common best practices and is maintained by a community. Also known as a framework.
>If you don't understand then you are either writing huge amounts of documentation and test code for your custom solution, or you are acknowledging that your app will be unmaintainable once you leave your position.
200,000 libraries, 50 of them good. My point exactly. A well written framework has already done the curation for you and has a community of people working to make those components even better for YOUR USE CASE.
>Both are signs of inexperience.
I guess I won't be hiring you then. If a candidate comes in and says "I don't trust frameworks because they are complex", I say "Thanks for your time."
How did the latter point derive from the former?
Frameworks come with prepackaged components and it's usually their way or the highway.
A framework might very well have a "community of people working to make those components even better" (period), but surely not "a community of people working to make those components even better for [MY] USE CASE".
If anything, a component's community try to make them as generic and all-encompassing as possible.
Contrast with libs, where I can cherry pick and use the one closest to my exact use cases.
>I guess I won't be hiring you then.
People use those kind of "arguments" a lot, as if they prove anything.
Depending on what those who say it are arguing against, it could both be a wise decision or the sign of an totally inept boss.
There are people who don't like frameworks that can code circles around people who do (and vice versa). If you don't want to hire the former, it's totally fine. Telling strangers who haven't applied to you, and have no intention to do so (and might be making hiring decisions themselves, elsewhere) that you won't hire them shows you in bad light -- trying to beat them into line not with arguments but with "boss" power.
Saying that please bare in mind that I love react it's a great tool but like everything it has its place.
Case of pot calling the kettle black methinks.
While most apps with any complexity will end up using some sort of framework, there is no rule which says it has to be an existing one. In my experience, a lot of the more involved projects I've worked on have used their own custom framework (as opposed to React, Angular, etc.) The upshot of this is that it is certainly possible to build something worth talking about without using one of the popular frameworks.
If they do they are very very misled.
People choose a framework because they want to benefit from the R&D done at said company, and avoid sinking similar R&D costs into their product.
I don't find happiness when my neighbors "cow dies" (I like that metaphor), but it does pay the bills, and that makes me happy. If people keep making the same mistakes, I will keep getting the same contracts in my inbox.
p.s. try breaking up your wall of text in future posts, it makes your response really difficult to read.
I normally do. See my other reply in this thread below.
I'll admit I was first set off by your seemingly condescending remark of 'simple people...'; I should know better. And not to get into too much of an OT style/usage thread, but the use of 'said' could be removed from your sentences as they are written. It is popular in legal writing as an abbreviation for 'aforesaid' or 'aforementioned', but also comes off as an affectation when used unnecessarily.
My point about some people bringing in, or championing a framework for a freelance gig, is that sometimes it is done to get some paid time learning that framework for future jobs. I think is it is disingenuous to dismiss that factor. As a senior manager and director, I have seen people let their personal goals bias their decision making in all types of business.
I still don't think the article was against using frameworks. I think it was about questioning or revisiting your reasons for choosing them.
Like HN, Craigslist, Reddit, DuckDuckGo, Wikipedia?
From what I understand, each of these sites was famously minimalist in terms of front end architecture as such, in their early stages at least. And still are, comparatively speaking.
You don't NEED a framework, just like you could theoretically build a car from scratch.
Very often you don't need a "car" to launch a business or start a community. Sometimes what you need is more akin to a bicycle. Or a walking stick.
I'm really glad I don't have to work with people who think like this.
I greatly prefer working with people who challenge conventional wisdom (and my own unthinking assumptions and tunnel vision about things), actually.
This isn't true. There is value in simplifying the problem at hand to the point where you don't need fancy tools to solve it. Not always possible, of course...
In fact, I'd say there is a pretty strong correlation between simplicity and usefulness (for some reason).
You don't necessarily need a heavy framework to make a useful app.
For simple apps, it's probably not needed. The issue also is that you app could be really simple now, but have features added to it regularly making it complex.
Back then everyone on StackOverflow was still completely bought into the JQuery mission. I often see it when people don't fully understand something, they choose a framework.