You probably don't need a JavaScript framework(slack-files.com)
slack-files.com
You probably don't need a JavaScript framework
https://slack-files.com/T03JT4FC2-F151AAF7A-13fe6f98da
355 comments
I can relate to your experience but you, just as me, seem not to be a typical front-end developer - the "web-boys" (a term which probably got you the down-votes) on the other hand are. If one asks them why they do things the way they do them, they usually have a coherent answer and are happy to explain it.
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). ;)
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). ;)
> "They did invest lots of time to learn about all those tools and libraries"
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.
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.
> introduce frameworks without so much as "apparently it's quite good, so let's use it"
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
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
" I'd expect these devs to implement a feature quickly "
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.
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.
"lifetime cost of software" means what? 99% of the software we write is obsolete within 2 years. We should not confuse big enterprise, long term support software with modern web development. IMHO, if you want to invest into software viable on the long term, rather spend your time writing functional tests and good documentation so the current implementation can easily be replaced with a new one that uses the then hip framework.
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.
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.
> "lifetime cost of software" means what? 99% of the software we write is obsolete within 2 years
More like, developers change jobs that often. So it's no longer your problem.
More like, developers change jobs that often. So it's no longer your problem.
Personally, I have terrible pangs of guilt if I know I leave a mess behind me. I've had to suffer fixing enough of someone elses messes to know what a timebomb of anger and frustration that is.
Sure, if the software gets totally junked in a couple years then lifetime costs of the implementation become less of an issue.
I work in an environment that's quite lean, but where deployment can take up to a year and lifetime is measured at the decade level so in my case the more traditional 'implementation is 10% of total costs' actually applies.
I work in an environment that's quite lean, but where deployment can take up to a year and lifetime is measured at the decade level so in my case the more traditional 'implementation is 10% of total costs' actually applies.
Given the cost of abandonment and lost sales due to slow page rendering (there's a lot that's been written about that), even a 3% loss of conversions due to slow frontend code over 2 years is a lot of money. For a million-dollars-a-year business, that's upwards 6 months worth of a developer's time.
[0] 3% based on how many people will abandon a page that takes more than 1 second to render: https://blog.kissmetrics.com/loading-time/?wide=1
[0] 3% based on how many people will abandon a page that takes more than 1 second to render: https://blog.kissmetrics.com/loading-time/?wide=1
>> The productivity gained by agreeing on a framework
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.
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.
You are quoting me but I am not sure you are responding to my comment.
>> 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.
>> 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.
Haha. I thought of that and posted a sub-reply, according to timestamps, just 5 mins before you posted this. I read your whole comment, and just intended to clarify that the very act of choosing a framework does not necessarily mean increased productivity, if the devs don't know the framework in question. A tangent based solely off the quoted part, for something I've seen time and time again over the years (new framework, no time to learn it, rushed deadlines).
(I should point out that this isn't a direct counter-argument to the parent I replied to. Just a clarification on that single point. It doesn't apply to most of their comment.)
> 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.
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.
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.
Good point. Team unity and shared understanding of the methods, I'm all for that.
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".
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".
> life can be more rewarding if you not only aim for perfection or near-perfection, but achieve it
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 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.
"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"."
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....
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....
Serious question: How else can you adopt a new technology, without investing significant amount of time?
It would be nice to exhaustively explore a tech before using it, but that's often simply not feasible due to lack of resources.
It would be nice to exhaustively explore a tech before using it, but that's often simply not feasible due to lack of resources.
How else can you adopt a new technology, without investing significant amount of time?
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 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.
There's a range of options between "I watched an hour video and saw a cool demo" and "I invested six months into prototyping and testing the tech before I chose it."
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.
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.
"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! "
That's great advice. It's what I do. Helps find the trouble spots before I run into them.
That's great advice. It's what I do. Helps find the trouble spots before I run into them.
it is not only nice, but also necessary. If you build a project with a technology you don't understand you are going to invest a significant amount of time anyway, but it might not give you what you want in the end.
>you know, this may not really be just a "web" thing....
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?
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?
Zero, since I was deliberately describing things that weren't web in my list?
NoSQL databases aren't used by web companies? Linux distros aren't used by web companies? Programming languages aren't used by web companies?
Pretty sure all those things are used by non-web people too.
If you're going to apply that standard, since to a first approximation everything is hooked up to the web, everything is web. In that case, it does no good to claim that "web people" are particularly prone to anything when "web people" are to a first approximation everybody.
If you're going to apply that standard, since to a first approximation everything is hooked up to the web, everything is web. In that case, it does no good to claim that "web people" are particularly prone to anything when "web people" are to a first approximation everybody.
I am aware they are used by non-web people. That is why I asked if these incidents were web companies or not. I am not applying any standard, I asked you a simple question and you responded with a bizarre claim that they were explicitly not web.
Oh, well, then I hate to disappoint you, but no, these were not primarily web apps.
Why would that disappoint me? I asked a simple question. Now you're still not giving me a straight answer, which makes me think you're being dishonest and trying to hide the fact that they were web shops. It doesn't matter if the choice was "primarily" for a web app or not if the choice is being made by web people. People who as a rule abhor learning and value fads.
Sounds like "Resume Driven Development" http://imgur.com/DQcks8ul
They're not a standard though. Everything's only a year old and gets replaced next year.
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.
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.
That doesn't invalidate the point, though. I'd rather maintain an old Backbone app, where I can read tutorials and search SO for answer, than some home-made framework.
Just want to be the counterpoint here. I've been building stuff at my last 2 jobs in Backbone (plus good OOP) for the last 5 years, and am only now considering a move to React or Vue, Vue being the conservative choice I may well go with. Not everyone jumps on the new frameworks just because.
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.
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.
> As someone else pointed out in this thread, a great advantage of established frameworks is that they provide a coding standard for a team.
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?
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?
A counter-point to your argument: In-house coding standards smells a little bit of NIH syndrome.
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.
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.
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.
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.
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.
> naively doing everything your own personal way (including at the team/company level).
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.
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.
I actually upvoted you, for the record. But you drew a distinction between "in-house standards" and "the framework's standards" (which are by definition probably taken from widely adopted standards).
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?)
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?)
> I actually upvoted you, for the record.
That's why I said "you and my downvoters", rather than "you and my other downvoters". I am apparently very bad at making simple points.
> But you drew a distinction between "in-house standards" and "the framework's standards"
One is used in-house for all things relevant, one applies to a framework. In that, they are distinct.
> (which are by definition probably taken from widely adopted standards).
Probably.
> If you were implying that those two things might be identical then you did a bad job of conveying that.
sigh. Two things can be true at the same time. I give up.
That's why I said "you and my downvoters", rather than "you and my other downvoters". I am apparently very bad at making simple points.
> But you drew a distinction between "in-house standards" and "the framework's standards"
One is used in-house for all things relevant, one applies to a framework. In that, they are distinct.
> (which are by definition probably taken from widely adopted standards).
Probably.
> If you were implying that those two things might be identical then you did a bad job of conveying that.
sigh. Two things can be true at the same time. I give up.
It's always possible to craft an anecdotal argument to disprove a generalized statement. We were obviously dealing in apples and oranges here..
I was making a generalized statement that likely applies to a large number of places (but indeed not all places), and you were providing a specific but not really comparable counter-point in return.
So yes, we were both right, but then again I ask "why reply?" if you're not replying in a similar context.
That's like me saying "the oceans are vast and dangerous" and you saying "but a pond is relatively safe"... You're technically correct, but what does it have to do with my initial statement?
I was making a generalized statement that likely applies to a large number of places (but indeed not all places), and you were providing a specific but not really comparable counter-point in return.
So yes, we were both right, but then again I ask "why reply?" if you're not replying in a similar context.
That's like me saying "the oceans are vast and dangerous" and you saying "but a pond is relatively safe"... You're technically correct, but what does it have to do with my initial statement?
There's a very suitable verb for describing this process: "enterprisify"
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.
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.
Using a JS framework like jQuery or Angular or React isn't even remotely similar to Enterprise Java Beans and all that nonsense. You must be joking.
Oh that's only because there's a new framework every 6 months.
What's the difference between platforms, frameworks and libraries? Here's my attempt ...
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.
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.
I boil it down to a terrible analogy of a framework being like a bad date: "Don't call me, I'll call you."
I find this answer helpful - http://stackoverflow.com/questions/148747/what-is-the-differ...
Thanks.
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.
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.
[deleted]
Useful comment. EJB=Enterprise Java Beans right? Assuming that is the case, your other two examples were Javascript - is there anything in js that looks like EJB?
Yip. EJB is Java's version of another total waste of developer time introduced by Microsoft (MTS/COM+). These are larger constructs than mere libraries or frameworks. I call them platforms. You have to obey their large gravitational force fields. Failure to do that will result in catastrophe.
Edit:
I'd say the browser is the platform in the JS world. But analogies don't necessarily fold neatly.
Edit:
I'd say the browser is the platform in the JS world. But analogies don't necessarily fold neatly.
> This trend toward "frameworkfulness" probably started with OOP and Java in the mid 90s, and spread from there.
No, it was already there with Smalltalk and C++, but millennials seem to have missed that part and everyone bashes Java.
No, it was already there with Smalltalk and C++, but millennials seem to have missed that part and everyone bashes Java.
I didn't downvote you (and I thought it was a thoughtful post), but I could totally see somebody interpreting "web-boy" as some sort of weird emasculating epithet a la "fanboi". On the Internet it's super easy to take offense at things that weren't intended to offend, in fact some people seem to thrive on it.
I think he's referring to all of hipsters who don't really understand what they're using but they're using it because it's hip. Might offend some, but people shouldn't be so quick to hop on a bandwagon and go wrecking working code.
It was prototype code, OP said that it was unmaintainable, and complained about, among other things, the "web-boys" adding unit tests - I'm not a 100% coverage zealot or anything, but adding some tests is not exactly hipster shit, it's a perfectly justifiable step when taking a prototype messaging app into production, especially if you have time in the schedule.
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.
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.
And then there are the "retro hipsters" who stick with "vanilla JS" and jQuery (not a framework?), smugly denigrating the new wave of modern "hipsters". Repeat ad nauseum.
Might they be denigrating the new wave hipsters on the basis that so many new wave websites are bloated whales on the inside, with pretentious 'mobile-first' machine-pressed skins on the outside? Or perhaps I've just helped you rest your case!
I can't think of anything that's particularly constructive to say, but I find your comment... irritating. It's likely that you are simply wrong. It sounds like you are personally upset that your creation was modified by other developers who may have more experience.
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.
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.
> Took around 2000 lines all in all....The line-count went up, of course, easily to 15000 lines.
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.
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 agree. We can make subjective arguments over this or that framework all day. But objectively speaking 15,000 lines is likely to be more difficult to maintain than 2,000.
Also, your TCB now includes Angular, a bunch of fairly unstable libraries and the servers that provide all the NPM package managing infrastructure.
I mean, your TCB already included the OS, the OS update manager and the browser, but still...
I mean, your TCB already included the OS, the OS update manager and the browser, but still...
Thanks a lot for your comment, after all I'm not crazy at all, I wish find more people like you
I've worked with node/npm/frontendy land for 5 years solid now. At first I used a lot of libraries. I guess with experience, it became clear that relying on as few as possible is much better.
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.
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.
Hmmm I still use a framework. Riot.js because it's all I need. No jQuery, no other frameworks. Just riot.js. I feel like all I write is small little web components. I could do it without riot but this just makes things more consistent for me.
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.
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.
I wouldn't exactly call React giant framework. It's API is pretty small actually.
That sounds very painful.
>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.
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.
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.
Your comments reflect my feelings at the time. Trying to push a round peg into a square hole. Angular had (and still has) some really useful features and so do many other frameworks/libraries. However, it's the combinatorial complexity of having a dozen of them at the same time, each with their own DSL, coding conventions, community (or lack of it), that makes it overkill.
By the way, as the nature of these messaging apps is mostly in async messaging, it proved quite hard to unit-test.
By the way, as the nature of these messaging apps is mostly in async messaging, it proved quite hard to unit-test.
I imagine designing thorough unit tests for 2000 lines of code could take a few weeks, and continue to have sparse edge cases crop up over the course of years. They're nice to have for mature software components. If you're prototyping, they're a waste of time.
Honestly, it just sounds like you are bad at managing your own software projects and trying to blame it on the web team.
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.
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.
> In practice, the definition for “difficult-to-understand” and “difficult-to-maintain” often boil down to whatever the team decides they are familiar with... Or want to be familiar with.
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.
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.
My point was solely that rewriting code--whether to a framework or for any other reason--is no reason to judge the original code as suspect.
Every team has their own reasons. You have yours, I have mine, but they’re the team’s reasons.
By the way...
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.
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.
This. I've seen thing rewritten for purely political purposes more often than technical reasons.
Same here. I've also seen the re-written code perform no better than the original but nevertheless celebrated as improved. I guess when billable hours are at the heart, nobody wants to say "and we rebuilt the homepage for what turned out to be no reason at all, but kept us busy for a few weeks".
[deleted]
It wasn't written to be easily maintainable, as it was a PoC. So no comments, relatively short naming. However, it had good SoC and simple logic to update views. Minimal, but understandable.
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).
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).
What is the argument here?
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.
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 (beta) protocol was pretty well documented at the time and it took relatively little time to implement the iOS client. 2000 lines of code is relatively easy to understand, even without someone explaining what's going on.
The project wasn't a failure at all. Currently being used in a production setting for communication in and between hospitals and medical labs.
The project wasn't a failure at all. Currently being used in a production setting for communication in and between hospitals and medical labs.
> You wrote a POC of unmaintainable code
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.
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.
Why was it rewritten, because it was difficult to maintain? It sounds like whomsoever rewrote it failed to make it more maintainable, then I would say that is a failure on the part of the person than on the concept of a framework.
Aren't frameworks supposed to prevent this type of thing exactly?
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.
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.
> Aren't frameworks supposed to prevent this type of thing exactly?
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.
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.
> The web-boys however, didn't understand asynchronous messaging, cryptography and eventual consistency very well
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?
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?
NPM is a package manager - anyone would advocate using that over manual dependency management, no matter what environment you're programming in.
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.
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.
To piggyback: If your library is a single source file and spec, I'm going to vendor it. Not add a dependency on it.
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.
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.
Lines of code can be a very good measure. You can have an app that is small and easy to fit into the mental model. Or you can wrap it up in huges framework and get lost between the abstractions. We have a saying to shoot sparrows from the cannon, and often using web frameworks looks like doing exactly this: you take trivial case and make it complex just because it is implied that frameworks are necessarey. Doing that you also kill accessibility (remember it? was a thing several years back), load times, etc.
> Doing that you also kill accessibility
?! What web frameworks kill accessibility, exactly?
?! What web frameworks kill accessibility, exactly?
To begin, React isn't a framework. It’s a tool. Would you compare a table saw to a workshop? That doesn’t make sense and neither does comparing React to a framework—especially if you’re saying you don’t need one.
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.
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.
> To begin, React isn't a framework.
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.
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.
Good post, very well said and says most of what I wanted to say on the subject.
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.
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 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.
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?)
> 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?)
> 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.
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.
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.
But the author has already tried to cover that aspect:
> 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.
> 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.
I don't think that counts as covering it. Redux is very simple. The entire API surface is like 6 methods and it's not difficult to understand everything that it's doing for you.
The point of React isn't its performance (though that is nice). The point of React is the simplicity and composability of functional components.
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.
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.
I feel like people who say "just use the dom" don't actually have enough experience to know why that is such a bad idea.
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.
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.
The main contention of the article is that this "simplicity" is illusory. You end up writing just as much code, but now you've added a complex dependency you don't really understand but have to make your customers download, and ultimately have to test against
That seems incredibly anecdotal. Perhaps if you don't understand the framework you are using.
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.
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.
I'm paying my salary. In my last performance review I rated myself outstanding and gave myself a substantial bonus. Frankly my employer is a little bit irritated by your arrogant comments about his hiring policies
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 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
Hilarious.
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 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.
why 50? make it 500! Better yet, make it 5,000 of skilled offshore developers 12 hours away, capable of cranking up few megabytes of code per week each, full test coverage, mocks and injections. Now we are talking! That is maintainable!
> And then having a common app structure with thousands of other people that can provide help and insight.
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
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
>There's examples online of a router that's 20 lines
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.
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.
> 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?
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?
> I can't imagine trying to build a:
* client side router * data transportation/cache layer * view layer * model layer * build pipeline
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.
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.
> Routers are easy; you likely don't need more than a few lines of code to accomplish most of what you need.
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.
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.
> It's at the point where it should be mostly boilerplate / routine
Yes, that is EXACTLY what many of these frameworks are.
Yes, that is EXACTLY what many of these frameworks are.
What? Seriously?
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?
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?
> I can't imagine trying to build a ... and more, in less code that just...
The other half of that "less code that[sic] just" is no code at all, and a reliance on a pkg manager command. It's a useless comparison, and wasn't at all lost on me.
Saying "React is all about composable components" is just as incomplete as saying "React is all about performance."
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.
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.
A) There are people that love frameworks.
B) There are the ones that don't.
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.
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.
> 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.
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.
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 would go so far as to say that to a new programmer on the team, Type B and Type C programmers' code looks much the same.
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.
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.
> Would programmer type B want to work with a 2 year old project from another type B programmer?
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.
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.
So frameworks matters because they define a set of development practices to get interoperability between project members, to allow different people (in terms of development practices) to do work together.
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.
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.
So people who don't use frameworks are better programmers than people who do... because... ?
You don't need one, but if you don't eventually adopt one, you'll end up writing one.
Sure, you may well end up writing one, but it's likely to be a fraction of the size. My current entire app is running at half the size of jquery, which is getting me awesomely quick page loads even on poor mobile connections. The dev time was longer, but not crazily longer, and the surface area for testing is somewhat smaller
There are cases where some companies have the business justification to work on writing their own frameworks, like with Facebook. They can use up human resources to really focus on latency at the cost of other metrics.
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.
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.
In reality JavaScript size means very little when a single image might be 500k.
Unfortunately I have to disagree. The JavaScript Engine still have to parse and interpret the code. This can take a bit of time, especially on mobile devices.
Parse time shouldn't be very long at all, especially compared to network latency. How long does it take for large (~100-150kb minified) to be parsed and interpreted? I'd be surprised if it's more than 100ms
100ms is noticeable. It's already slow if you reach that.
It's barely above the threshold for detectable live feedback latency, from a musical instrument or sight/sound correlation. As a user veiwing a page with plenty of other latency, it's inconsequential, particularly since you can execute your js while image assets are still incoming.
[deleted]
Maybe, but in terms of understanding the code and having total control over it, it means a lot.
(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...
(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...
Did you not see that headline about how the average page now is the size of a Doom install?
Mainly because an average page has much higher resolution graphics than Doom.
Six years ago I was regularly mining merchant pages containing 1mb+ of HTML. Nowadays that seems to be par for course.
You shouldn't be serving 500k images to mobile users.
It's not so much the time over the wire to download, but the time to parse and run all that JS. If you open up your web dev tools, I think you'll see the impact from a 50k gzipped JS file is probably greater than a 500k image, for one thing the site can probably function without the image loaded, but your page will not be user responsive until that JS has finished executing.
My total image payload is 30k. Obviously getting there is more challenging for other sites, but at the end of the day if your page is >1mb I'm probably not going to wait for it to load
>but at the end of the day if your page is >1mb I'm probably not going to wait for it to load
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.
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.
Switch "most popular" to "your site" and it will probably change user's desire to wait for it.
Yeah, that's true.
Also what I left out in my argument is that while popular already, they still might get increased in traffic if they were lighter.
Also what I left out in my argument is that while popular already, they still might get increased in traffic if they were lighter.
What's more relevant at Facebook's scale is dollars saved per kilobyte shrinked. Because majority of its users will tolerate almost anything at this point, including apps that crash randomly to measure loyalty.
Then you are doing images wrong.
Can you post a link to your app? Would love to see an example of a frameworkless web app.
I'm not sure how the size of your app can possibly say anything about applicability or quality of jQuery.
Yep. If you're getting paid to maintain even 10-20 UI's, frameworks help preserve your sanity. At least you'll know what to expect from the boilerplate and what are the general capabilities of dozens of apps, just by learning 1 framework. And the more popular the framework, the easier it is to hire new developers to work on your apps.
That's funny. But at least you might not need the whole framework, just a part of it. And that part you'll end up writing youself. Why not? You'll understand javascript better. Most developers aren't able to write a single line without a framework.
So people keep telling me, but I've been building this stuff for a couple of decades now, including maintaining certain projects for at least as long as most of the modern JS frameworks have existed, and I'm still waiting. The only way these generalisations about everything becoming a framework hold is if you conveniently define framework to mean something like "having any sort of systematic or uniform software architecture".
I guess that's why we have so many! bah dum bum chh
I don't use React for speed. I use it because manipulating the DOM to make it reflect the application state is hard. It's something a program should do for me. React is that program.
I don't get a lot of opportunities to play around with JS frameworks, which is odd because I hobby-code a lot in JS. I imagine the top reasons to use frameworks are cross-browser compatibility and support for scalability in the domain of your work. Unfortunately sometimes people use them because the only tool they have is a hammer, so everything is a nail. Vanilla DOM manipulation has become much easier in the past few years. I have played around with some new DOM features in my own time, but for anything public-facing I'm going to use a library that allows for cross-browser compatibility, and typically that's a combination of jQuery, polyfills, etc.
It's not that it is hard to `document.createElement` compared to `React.createElement`, it's just that React has a nice paradigm of syncing your app state to what's displayed to the user which many people like. Sure it might be better somewhere else, but React is what is popular and more easily accessible.
I don't think it's hard. If you really think it's hard, I think you can study React's architecture and discern that you can accomplish what you want with React--or with smaller, different libraries in accordance to your use case.
A program?
I, too, did a double-take at the use of the word, but I looked it up, and it seems to be a valid usage. Various dictionaries define program merely as a "set of instructions," so, yeah, a library or framework counts as a program just as much as a separate process.
I just felt a program is such a general and high-level way to describe software... basically anything that computes...
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.
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.
I used "program" because that's what we call things that automate things for us, and that's the appropriate frame for thinking about React: it automates things you could've done by hand, but why do that?
One thing many people underestimate is how easy it is to run into XSS, XSRF, XSSI when not using a framework, in particular XSS when using native DOM APIs ("location.href = ..." - pwned. "e.innerHTML = ..." - pwned. "a.href = ..." - pwned. "*.src = ..." - pwned.).
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.
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.
Unless your framework bridges the backend and frontend you're not going to just magically get rid of XSS vectors.
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.
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.
I thought his point was clear. A framework provides all those things, free of charge. Instead of using location.href or e.innerHTML you're invited to use framework.html(), etc. It's possible you would take care of escaping output on your own, but the point he was trying to convey is that you are likely to take shortcuts and not do all those things.
framework.html() would presumably have the same problems as e.innerHTML (as you're probably aware). The examples that come to mind are replacing something like...
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. Idiot proofing is a real feature I grant you but it's not something you can blame the native DOM APIs for.
Anyone who knows what they're doing is one dumb moment away from not knowing what they're doing. I suspect I know no programmers that don't average at least a dumb moment per day. Your code reviewer is one dumb moment away from not catching it in your code review - which may be as simple as skimming a little too fast because the diff was a little too big. tl;dr: This:
> 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."
> 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."
> if you know what you're doing
Because everyone is perfect, right?
Because everyone is perfect, right?
"Another example is the Fetch API"... That API has very limited cross-browser support. One of the largest reasons web frameworks exist is to bridge the gaps between browser incompatibilities/offering legacy support.
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.
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.
Also beware that the Fetch API doesn't have support for file upload progress tracking.
Yeah I find it hard to believe that the people who go on about how convoluted web development is actually get paid to do web development.
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?
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?
So your suggesting that if you question the system, you shouldn't get hired, or paid?
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.
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.
> So your suggesting that if you question the system, you shouldn't get hired, or paid?
No, I'm saying people don't typically hire developers who don't know ANY libraries or frameworks.
That's reality.
No, I'm saying people don't typically hire developers who don't know ANY libraries or frameworks.
That's reality.
> Why do huge tech companies like facebook and google develop web frameworks if they're unnecessary?
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.
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.
Do Google even really use angular? I know none of their core products use it. As to Facebook, their website is painfully slow, seems like it's not a model of the right way to do stuff
Google Developer Console,
Doubleclick Platform,
Parts of Chromecast including the Chrome Extension,
YouTube for PS3
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.
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.
Well fb is fast for me, so is cloudflare, airbnb, Codecademy, Coursera, Docker, Dropbox, IGN, IMDB, Imgur, Instagram, Khan Academy, Netflix, okcupid, and a whole bunch of other websites that use react.
Plus I like being employed so knowing frameworks and libraries is a must.
Plus I like being employed so knowing frameworks and libraries is a must.
I don't think their main website uses React fully yet. Instagram does and that's pretty fast—same as most other well-done React apps.
Facebook.com contains more than 20,000 react components. They use React at pretty much every dynamic aspect on their website. They also use React Native in a lot of aspects of their mobile apps, both for iOS and android.
The article's author does not seem to understand what React is for and why people use it.
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.
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.
"for a variety of reasons"---care to share in brief?
The cycle continues...
No framework -> Backbone -> Angular -> React -> No framework
We should be back towards using a simple MVC skeleton by the end of 2016.
No framework -> Backbone -> Angular -> React -> No framework
We should be back towards using a simple MVC skeleton by the end of 2016.
The main point of frameworks/libraries is to set coding guidelines for the team. It's fine to go off and invent your own framework but this causes maintenance issues for the people coming in next. Most likely, there are no docs or examples for the code you just wrote (especially the framework bits). When a framework which has a community is chosen, these boring things like docs/examples/references/blog posts get fixed over time. So it's best to pick one so that the code is easier to maintain in the long run. Besides, the focus should be on the app and not the framework/library and writing your own is just distraction.
>When a framework which has a community is chosen, these boring things like docs/examples/references/blog posts get fixed over time.
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...
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...
Release of a new framework doesn't render all existing code based on an older framework useless. Nobody mandates moving all existing Angular 1 codebases to Angular 2.
Mandate moving them, no.
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.
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.
I apologize for not adressing your concerns with the post earlier, I've just added an update to the bottom of the post with some replies to some comments I've read.
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.
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.
Although I agree with the idea that Frameworks can easily make your life worse instead of better. Especially at the time the Framework moves forward to a version that is not at all compatible with what you are doing.
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.
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.
- shows an example using mutation observer API and fails to mention it only works on IE 11+
- 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)
- 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)
It's interesting that by comparison, a lot of these modern JS frameworks are positively tiny. No comparison to e.g. Cocoa, QT, MFC, Rails, Spring and all the things usually called the f-word. React itself barely qualifies for "library", more like "helper functions".
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.)
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.)
This might be the post that convinces me to write a companion piece on why you probably don't need a CSS framework, either. Browser renderers have come so far since Bootstrap's peak: Flexbox has all but obviated its primary value proposition, and when CSS grids make it out of RFC, using Bootstrap for layout will be like using Backbone to do rollover styling.
Sorry, I have to disagree strongly. For starters, bootstrap provides consistent and attractive default styles. Additionally, if you implement your styles as a bootstrap theme, third party components that are written with bootstrap in mind will (usually) automatically have the correct look & feel.
Flexbox is definitely a lot nicer than the Bootstrap column system though.
Flexbox is definitely a lot nicer than the Bootstrap column system though.
Plus one for my interest. I became checked out of front-end framework developments when it started to become a big build process with a lot of dependencies, and if that can be reversed, I'd be happy to work with the DOM again.
I would read that article positively
I wrote dbmon at Instructure (first with jquery, then in ember, then in react, where it has been for a couple years) to give us a birds eye view of a bunch of databases. It's been kind of surreal to watch it blow up into what it has.
I'm getting so tired of this conversation. Use a framework. Don't use a framework. Just build something already. Who cares how you made it? I'm so sick of getting asked "what framework did you use?" I'm so sick of seeing people pitch their projects as "ProjectName: built with FrameworkX and LibraryY", with zero indication what the project does. If the most interesting part of the project to you is the tools with which it's built, you're not an entrepreneur, you're a fetishist.
You don't need a JavaScript framework. You just need a bunch of stuff that you can't use because it isn't supported in IE9.
> 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.
> 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.
I came across this thread late, but the comments here have been quite fascinating to read. I think as developers we're always seeing patterns in our code and trying to figure out the best way to solve them and that's how many frameworks emerge. Before React's emergence I would occasionally come across UIs which were incredibly complex due to events firing left and right (and events firing in response to those events, etc) and in an attempt to reduce cognitive load I would try and re-structure the code with a uni-directional flow that would re-render the entire UI when any state changes with varying degrees of success (since applying this pattern on top of another framework is pretty fragile). So React was immediately appealing to me. And Flux and later redux was the evolution of that idea taken to another level.
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.
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.
So, I've been working with rich text editors in particular recently, and I can tell you one thing: contenteditable is a gigantic pain in the rear. It's uneven across platforms what it transforms user intent into (control-B: do you get a <b> or a <strong>?), it handles paste events sloppily, and marking inner fragments as not contenteditable (say an image embed, atmention or some other block) is weird, especially if that item is the last thing in the list.
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).
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).
Are Slack Files an official blog from Slack? For a second, I thought looking at the URL that this was just a URL for a Slack snippet or something similar.
No, if you look in the footer you'll see it says "Public file shared from Slack", which I think just means someone posted this document using Slack
Weird, so Slack effectively has a stealth Medium competitor now?
Slack's blog is at slack.engineering. It's called Several People Are Coding. This is not from Slack, as noted by philfreo.
yes this what I was curious about as well. Interesting the simplicity of creating snippets with markdown makes it easy to use for posts as well sharing code snippets ala gists
I have been avoiding JS for years (not out of hate, just the job) and every time I dabble in the node/js framework ecosystem I end up turning away frustrated.
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!
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!
I was in the same boat, tried reading tutorials for Angluar/Ember/Backbone/etc and wanted to throw up because of all the complexity and prior web experience/knowledge that they expect you to know. But then tried Meteor and everything there made a lot of sense to me.
Meteor is a great stepping stone to the more complicated JavaScript ecosystem of node/react/angular/webpack etc. I was a huge fan of it when I first started web development, but all its limitations caused me to switch over to using the above mentioned technologies. I highly recommend it to any beginner to web dev!
This eternal argument of js framework/non-framework reminds me of them old days of static html when Dreamweaver will just munch a PSD file and spit out working HTML + Images + CSS. Some of us hated it b/c the output was bloated, super hard to read/maintain, etc. So, some of us just went ahead and coded from scratch. I guess the preference has to do with a need to 'understand' what's going on. Tools like React or frameworks like Angular are just the modern Dreamweavers: don't mind the inner-workings, just follow the rules and get the desired output.
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.
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.
I feel this way about backbone as well. Before using backbone, I wrote complex user interfaces in Javascript/JQuery. They were a mess.
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/
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/
>I think the cost of re-writing things all the time is too high.
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).
http://edwardspooner.com/items/index.html
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).
http://edwardspooner.com/items/index.html
I actually do use an el already in the DOM. To be honest, I do it that way because the code looks cleaner and is easier for me to understand that way, I didn't know it was faster. The only caveat I've found with that way is that if you remove a view and add an identical one, the events from the old view still get fired. For views where that happens, I actually use a custom extension of the original views that has a special destroy method that gets called which unbinds events and stuff.
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.
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.
Most people probably don't need to write much app-land javascript at all to have reasonable UX:
http://intercoolerjs.org
Bonus: you get HATEOAS without knowing what HATEOAS means.
http://intercoolerjs.org
Bonus: you get HATEOAS without knowing what HATEOAS means.
This! This times a million times!!~!
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 :/
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 :/
As a javascript-noob, not even jquery? I've heard jquery solved so many headaches.
The major criticism of jquery comes from its "overhead" which comes from wrapping a lot of functionalities onto relatively(at the time of its onset) large file[1]. While they were legitimate(internet was slow) at the time, at its cost jquery worked as a go-to-solution for browser incompatibility. This was a major issue which jquery solved magnificently.
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.
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.
It solved problems of cross-browser compatibility back when Netscape was still a thing, before Chrome existed, when major releases of browsers (IE) radically changed functionality between releases, and if I recall, we had Phoenix/Firefox as the most cutting-edge browser of the era. This is what browser market share looked like back then: http://arstechnica.com/uncategorized/2007/02/8908/
When jQuery launched, it appeared on Del.icio.us and Digg, for context of its era: https://jquery.org/history/
When jQuery launched, it appeared on Del.icio.us and Digg, for context of its era: https://jquery.org/history/
jquery is awesome, go for it!
(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.
(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.
it solved differences between older browsers. now, they tend to follow standards, and that melding is less needed
Where are all the job openings for people who don't know a single framework or library?
So instead of using an established framework the post is suggesting possibly using these things?
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.
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.
React is popular because it re-frames the meat and potatoes of frontend dev as a simple input -> output problem. VDOM merely helps make this approach performant at scale - it has little to do with why people actually use React.
Abusing MutationObserver to get "easy" 2-way data binding is precisely the sort of antipattern that React & Friends would have discouraged.
Abusing MutationObserver to get "easy" 2-way data binding is precisely the sort of antipattern that React & Friends would have discouraged.
[deleted]
Whilst predictably this HN thread has turned into a bit of a flame war I would like to point out the article certainly made one indisputable point. That HTTP/2 is going to change how modern web apps are written all over again. So then we'll all need another new framework.
One of the big ones is build tools.
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.
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.
For those who read the comment about Object.observe: Don't use that. It's being removed from everywhere it exists, and pulled from the standards recommendation. Just have a set(state) function that calls your callback instead, it's like three lines of code.
I really wish I didn't need a javascript framework, but I find this essay unpersuasive. He doens't seem to deal with the same kinds of problems I do. But I like that he's making the argument, and trying to pull out the parts where the web API has gotten a lot better. It's approaching maybe. I really do wish.
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.
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.
Back in the late 90s a bunch of us create an architecture we named AJAX. Now in 2016 a bunch of us are still using AJAX to build web apps that work just fine and are probably faster than these "frameworks".
I don't think frameworks and tools are the problem. I have dealt with the same frustrations about these huge tool-chains but I've always seen it all boil down to one key point: the problem is not the tools- it is not choosing the right tools for the project at hand. Then you get websites and apps that really bloat up because of the overkill or poor choices.
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.
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.
Its ROI. For any new company starting off, they will quickly realize that all non-js agents are either bots or very low-powered machines. With many new companies, who base their entire existence on the web and customers' ability to access it, these two groups are not their target audience so why bother making a JS free, static site when you don't need those customers' business?
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.
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.
Is it possible for someone to point me in the direction of a nice JS project template that does not use a framework?
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.
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.
I agree. I enjoy developing the quickest route from a-z. I can write javascript. I know the dom, that its quicker to update one large dom container than it is to update many smaller elements. I have worked with and understand ajax, that rewriting a dom node before unbinding any events creates browser memory leaks causing it to eventually crash. I would not know these things if i had coded with the prescribed framework. If the argument for using them is to have team coding standards then have team coding standards. The framework creates its own problems.
Ok, we don't need frameworks, however what should we use in order to build complex UI applications? Own solutions? And know imagine that in every project you build your own skeleton and architecture...
I think the point is for complex UI applications (or a team with interchangeable members) you would use a framework. But for less complex applications you might very well not.
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.
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.
Greenspun's tenth rule: Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.
Now let's add Javascript to the list.
Now let's add Javascript to the list.
The good news is that with V8 and ES2015, we now have a formalized, (fairly) fast, and tolerably buggy implementation of Half of Common Lisp. Oh yeah, and it runs natively on devices owned by literally billions of people.
I like this way to do, preventing complexity.
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".
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".
>Virtual DOM is efficient and has good performance, but native DOM interaction is insanely fast and your users will not notice any difference.
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.
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 Virtual DOM is faster than rebuilding the entire DOM from scratch, yes. But making edits to DOM manually will be faster with native browser functions and no VDOM diffing overhead.
I agree, but it also possible to use these frameworks without much understanding of the DOM and I think anyone serious about web development should have a good inside grasp on how the DOM works before using a library.
React doesn't exist to handle the massive amounts of data that facebook has.
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.
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.
Moreover, I don't even consider React a framework. I consider it a library for my creating my view layer. Frameworks, at least to me coming from back end, have all sorts of extra bells and whistles. Something like Angular I would consider a framework and it has its OWN view layer inside. But React feels much different, it feels like something your (non-view layer) framework should feed into, not replace entirely.
React calls itself "a JavaScript library for building user interfaces", which I think is accurate.
I remember seeing an article a while ago that suggested react was a bad paradigm because of a similar paradigm that failed... something about COM interfaces in windows programs? Does anyone remember such an article? That was one of the few truly interesting critiques of react that I have read.
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.
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 think you're referring to https://bitquabit.com/post/the-more-things-change/ , which compares React to a Win32 WndProc function.
Ah, those were the days! I think I still have that Petzold book somewhere. It had to come with examples, because Stack Overflow didn't exist yet, so that was the only way you could get stuff working in a reasonable amount of time. (Except for when it didn't work in your code for some reason.)
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
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
So to clarify:
* 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.
* 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.
It reminds me a lot of WPF development in that you designed components with state (data context) and the component knew how to render.
[deleted]
Rarely anything insightful about an article was contributed by someone saying how they skipped it past the first few paragraphs...
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).
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).
"That the author kind of misses this point makes me pay less attention to the rest of the post."
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.
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.
I think I agree with you, but your comment breaks the HN guidelines twice: the first paragraph is uncivil and the final one goes on about getting downvoted. It also pretty much breaks the injunction against "did you even read the article" comments, so that's three. Please don't do these things when commenting here, regardless of how irritatingly wrong someone else may be.
The middle paragraph is helpful and fine, and the comment would have been much better with just that.
https://news.ycombinator.com/newsguidelines.html
The middle paragraph is helpful and fine, and the comment would have been much better with just that.
https://news.ycombinator.com/newsguidelines.html
The first paragraph wasn't uncivil. He said that he didn't read past the first few sentences of the article:
"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.
"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 don't see that. Actually the only bit that seems uncivil to me is just "You just didn't read past the sentence you quoted." You can't know that, and such statements are the internet comment equivalent of elbowing.
I was responding to the last line of his comment, coupled with the fact that the comment completely mischaracterized the article based on a single line, early in the piece.
I admit that the last line is unnecessary. I'll remove it.
I admit that the last line is unnecessary. I'll remove it.
(I didn't downvote you, I really don't mind, but it did sound aggressive).
Here's what you wrote: >> 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.
Here's a political rewrite (Keep in mind I'm not a native english speaker):
It seems that the author addressed your points later in the article. For instance, rather than rendering every state change on the server-side, it explains how you can get data-binding and partial-update behavior with web-native APIS.
The main argument of the article is that most people don't need React, not necessarily that they don't need AJAX or data binding.
Here's what you wrote: >> 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.
Here's a political rewrite (Keep in mind I'm not a native english speaker):
It seems that the author addressed your points later in the article. For instance, rather than rendering every state change on the server-side, it explains how you can get data-binding and partial-update behavior with web-native APIS.
The main argument of the article is that most people don't need React, not necessarily that they don't need AJAX or data binding.
The argument that React will be heavier than your own implementation is clearly true.
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.
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 didn't downvote you. But I don't want data binding. I want to input parameters and get UI as output. I want to minimize state as much as possible. I want to write unit tests where I mock as minimally as possible. These are the reasons I use React.
So, I actually did read the rest of the post. I just didn't look at it deeply.
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.
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.
It's odd that nobody that's responded to you so far has pointed out that your comment is totally irrelevant to the comment you're responding to. Nowhere does GP imply that OP implies that you should render every state change server-side. The whole point of react is to render client-side.
That doesn't address the fact that, to some of us, React simplifies creating, testing, and maintaining complex UI due to its functional nature. React is simple to me, and that's why I like using it.
"React is simple to me, and that's why I like using it."
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.
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.
If you're going to tell me I don't need to use a library, it has to be way more convincing than, "Look how easy data binding it with native APIs! And it's not slow!" This is a weak argument in my opinion, and does nothing to address how removing abstractions will make my life easier.
That's a perfectly fair counterargument to the content of the piece, but the comment to which I replied had no such content.
The post didn't miss the point that "being able to just write the code once to render a UI from some state...is an incredible simplification of your code." It argued that you can do that without using React.
The post didn't miss the point that "being able to just write the code once to render a UI from some state...is an incredible simplification of your code." It argued that you can do that without using React.
It argued that you can do that without using React.
I actually didn't see that argument being made - two way data bindings are not the same thing.
To achieve React's simplicity you either need to
a) Simply tear down the entire DOM and rebuild it - works for small UIs and I've actually used this myself before react existed
b) Implement something similar to the Virtual DOM that react has for any non-trivial UI that is too slow to rebuild on every user interaction.
I actually didn't see that argument being made - two way data bindings are not the same thing.
To achieve React's simplicity you either need to
a) Simply tear down the entire DOM and rebuild it - works for small UIs and I've actually used this myself before react existed
b) Implement something similar to the Virtual DOM that react has for any non-trivial UI that is too slow to rebuild on every user interaction.
This looks like a great blueprint to spend way too much time writing an app that is un-maintainable and only works in a few browsers.
Brilliant. I get burned by cross browser issues when going without frameworks. Would love to work exclusively with Web API.
I don't agree with the sum of it's parts, but I like some of the... components... in this article.
contenteditable and MutationObserver? What about <input> and onchange?
Absolutely agree. Also wanna notice that is React is the only one V from the MVC. At least it's weight now more then Angular. Backbone can even do everything and twice time more then React can do.
In some special environment, such as Electron (Atom shell), that can ignore the cross-browser problem, writing application using native Web API and DOM API and ES6 is elegant and effective.
openEtG doesn't even use jQuery, it's been alright. Only library it uses is pixijs, & a slimmed down version at that. Originally everything went through canvas/pixijs but over time only a few views aren't DOM
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
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
You 'probably' don't need one but 'should' use one to save yourself countless hours re-inventing the wheel that frameworks solve.
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.
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.
If you're looking for work and the hiring manager fishes for names of JavaScript frameworks you've used, you need a JavaScript framework.
I might not need a framework but that does not mean that there is no value to it.
I don't really need a smartphone, but it is quite useful.
I don't really need a smartphone, but it is quite useful.
Yeah why not? Let's reinvent the wheel every fucking time.
I'm sure your clients and your family will love that.
I'm sure your clients and your family will love that.
[deleted]
If the author thinks TypeScript is a framework there is no need to waste time reading the article.
You probably don't need Redux* but React is awesome
npm install --save-dev vanilla-js-loader
I'm really glad I don't have to work with people who think like this.
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 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.
'I'm really glad I don't have to work with people who think like this.'
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.
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.
You are building a straw man and then arguing with it.
No, im not. Those are the exact points laid out in the article. The author mentions both the performance, size and redundancy related to frameworks.
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.
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.
How funny, then, that the framework people can't seem to standardize over anything more than jquery or react?
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.
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.
I profit from people's lack of technical expertise every day, and I'm proud of it.
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.
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.
I think you're touching on exactly the problem: a 'spaghetti be-spoke' js app. Can a JS app be anything but? Javascript is a language for the view layer. It's supposed to be the minimal shim on top of LAMP or Rails or whatever, to bridge the gap between static HTML and dynamic movement. It was never supposed to run the entire app!
You are ignoring huge problems.
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.
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.
How does a LAMP/RAILS app share server side rendering code with the client?
It doesn't, because I don't need/want it to. Any data that needs to be passed to the client is rendered as JSON. Client-side get committed to the database via AJAX (to my buzzword-o-rific REST api), or with good-ol' POST.
How does a LAMP/RAILS app share data models between the server and client?
Again, not needed.
How does a LAMP/RAILS app provide search engines with indexable dynamic pages?
Uh, through clever use of jquery AJAX and postgres indices?
How does a LAMP/RAILS app preserve client state between page reloads?
A serverside redis cache? In the database? In the cookie? LocalStorage? C'mon man.
How does a LAMP/RAILS app synchronize client state between multiple connected clients?
By pushing a hash with current state to all clients via polling? Websockets? Whatsitcalled where you don't close the original HTTP connection? Did you know postgres has some pretty awesome realtime pubsub tech? I suppose if I have some extra time I could send changesets and load them with $.merge()
...
I just want you to know that you are doing nothing to improve my image of the JS-scene-writ-large as immature, spoiled, and childish. There are isolated pockets of brilliance, for sure, but the everyday talk scares me.
It doesn't, because I don't need/want it to. Any data that needs to be passed to the client is rendered as JSON. Client-side get committed to the database via AJAX (to my buzzword-o-rific REST api), or with good-ol' POST.
How does a LAMP/RAILS app share data models between the server and client?
Again, not needed.
How does a LAMP/RAILS app provide search engines with indexable dynamic pages?
Uh, through clever use of jquery AJAX and postgres indices?
How does a LAMP/RAILS app preserve client state between page reloads?
A serverside redis cache? In the database? In the cookie? LocalStorage? C'mon man.
How does a LAMP/RAILS app synchronize client state between multiple connected clients?
By pushing a hash with current state to all clients via polling? Websockets? Whatsitcalled where you don't close the original HTTP connection? Did you know postgres has some pretty awesome realtime pubsub tech? I suppose if I have some extra time I could send changesets and load them with $.merge()
...
I just want you to know that you are doing nothing to improve my image of the JS-scene-writ-large as immature, spoiled, and childish. There are isolated pockets of brilliance, for sure, but the everyday talk scares me.
(gjolund: I can't reply to you directly, but consider this my reply)
Because they're simple? They're relatively standard? They're compact? Because I don't have to learn a new god-damned framework for every single new assignment? When did software development become a paint-by-numbers exercise? There is a difference between spaghetti-code and engineering.
Why do you want to write all that extra code instead of just picking the right tool for the job?
Because I can do it in less lines, in less time, with no new dependencies, and -- again! -- I don't need to learn another new framework!
PS- Please understand, I know the difference between good code and bad. That's why I've automated most of my job title and am able to spend 97% of my working day helping the rest of my team solve their problems! Oh and did I mention I handle the infrastructure, enterprise integration, telemetry, and sales reporting for my company?
Because they're simple? They're relatively standard? They're compact? Because I don't have to learn a new god-damned framework for every single new assignment? When did software development become a paint-by-numbers exercise? There is a difference between spaghetti-code and engineering.
Why do you want to write all that extra code instead of just picking the right tool for the job?
Because I can do it in less lines, in less time, with no new dependencies, and -- again! -- I don't need to learn another new framework!
PS- Please understand, I know the difference between good code and bad. That's why I've automated most of my job title and am able to spend 97% of my working day helping the rest of my team solve their problems! Oh and did I mention I handle the infrastructure, enterprise integration, telemetry, and sales reporting for my company?
It's a lot easier to learn React than what all of you think. It's especially easier to learn these frameworks when you tried to solve the problem without them and experienced the pain of not having them.
As a user of React, I disagree -- unless you are using React in a javascript runtime, in which case you're probably fine. But I resent react for all the extra cognitive load it forces me to worry about when all I really give a shit about is its shadow DOM implementation. And then, only when I've got page(s) full of data I need to update without lag.
I'd like to correct some misconceptions you seem to have regarding React.
> unless you are using React in a javascript runtime, in which case you're probably fine
React is written in JavaScript. It runs exclusively in JavaScript. If you've somehow managed to run it outside a JavaScript runtime then I'd actually be delighted to learn about how.
> all I really give a shit about is its shadow DOM implementation
React doesn't have a shadow DOM.
> unless you are using React in a javascript runtime, in which case you're probably fine
React is written in JavaScript. It runs exclusively in JavaScript. If you've somehow managed to run it outside a JavaScript runtime then I'd actually be delighted to learn about how.
> all I really give a shit about is its shadow DOM implementation
React doesn't have a shadow DOM.
Are you talking about ReactNative? I haven't played with that yet, but it's one reason I chose React in one of my projects (eventual plans to use our web browser components at least partially in Native).
No, more specifically, using React with Rails through the react-rails gem. I am considering ripping out all my JSX and replacing it with our React JS
We didn't collectively decide to move rendering to the client side for no reason. It is unquestionably more complex to build a SPA than to have a traditional web app.
We did it because users demand it. A SPA feels substantially faster and more reactive. Users notice.
If Gmail used your approach, it never would have succeeded.
> How does a LAMP/RAILS app provide search engines with indexable dynamic pages? Uh, through clever use of jquery AJAX and postgres indices?
I have to assume you're just throwing out terms you've heard of but never understood. Database indexes have literally nothing to do with making your site indexable for search engines.
We did it because users demand it. A SPA feels substantially faster and more reactive. Users notice.
If Gmail used your approach, it never would have succeeded.
> How does a LAMP/RAILS app provide search engines with indexable dynamic pages? Uh, through clever use of jquery AJAX and postgres indices?
I have to assume you're just throwing out terms you've heard of but never understood. Database indexes have literally nothing to do with making your site indexable for search engines.
Most SPAs feel substantially slower IME.
The users didn't demand this. They were perfectly happy when you delivered a website that performed a full-round trip in 50ms a decade ago containing more data than your average SPA can handle before choking on it.
The users want it to work. They want it to be fast. They want it to be pretty. That's about it.
I'm tired of hearing about why GMail succeeded. It's revisionist. GMail succeeded because they had the best spam filtering, in a simple design, and you were probably using Google search anyways. Plus Hotmail was always going down for hours (days?) at a time.
I've never experienced bugs in the web like I have with SPAs. I'm very thankful that even if my budgeting software is built in Ember, making it slow and buggy, my bank's site isn't. Making it predictable, and very fast to render. Time to Render is atrocious on many "modern" sites.
The users didn't demand this. They were perfectly happy when you delivered a website that performed a full-round trip in 50ms a decade ago containing more data than your average SPA can handle before choking on it.
The users want it to work. They want it to be fast. They want it to be pretty. That's about it.
I'm tired of hearing about why GMail succeeded. It's revisionist. GMail succeeded because they had the best spam filtering, in a simple design, and you were probably using Google search anyways. Plus Hotmail was always going down for hours (days?) at a time.
I've never experienced bugs in the web like I have with SPAs. I'm very thankful that even if my budgeting software is built in Ember, making it slow and buggy, my bank's site isn't. Making it predictable, and very fast to render. Time to Render is atrocious on many "modern" sites.
Gmail was also originally a traditional webapp - in the early versions Javascript added to the experience, but there were still page transitions when viewing emails and composing new emails.
Opinion time: I miss that version. There's so many bells and whistles on Gmail now that I prefer to use a local mail client to logging in and attempting to work through all the clutter to do basic things like viewing and replying to emails.
Opinion time: I miss that version. There's so many bells and whistles on Gmail now that I prefer to use a local mail client to logging in and attempting to work through all the clutter to do basic things like viewing and replying to emails.
That's the opposite of reality. Users hate it. Overwhelmingly. You did do it for a reason, but the reason was "look I think this is cool!". Users suffer for the fashion driven choices of the web development world.
> That's the opposite of reality. Users hate it. Overwhelmingly.
You have absolutely no evidence of that.
On the contrary, there is abundant evidence that SPAs increase engagement.
You're living in an echo chamber if you actually thing the average user would like to return to the web of the 90s. They love things like the infinite scroll on Facebook, Google instant search, Slack, Trello, etc.
If you think the huge companies implementing these things haven't done extensive user testing to show that people prefer these experiences, you're letting your political agenda cloud your judgement.
You have absolutely no evidence of that.
On the contrary, there is abundant evidence that SPAs increase engagement.
You're living in an echo chamber if you actually thing the average user would like to return to the web of the 90s. They love things like the infinite scroll on Facebook, Google instant search, Slack, Trello, etc.
If you think the huge companies implementing these things haven't done extensive user testing to show that people prefer these experiences, you're letting your political agenda cloud your judgement.
An echo chamber? Where? Show me this echo chamber. The echo chamber is the one repeating the same baseless nonsense you are. And where on earth do you get a "political agenda" from pointing out the fact that user testing shows javascript messes are bad?
I love infinite scroll. I don't count though, hm?
I love peach pie. What does this have to do with anything?
No, you can build your own full-text search engine with dynamic pages with postgres' fulltext index types. You can subscribe to changes through LISTEN/NOTIFY, or by outputting log entries in trigger functions, among other techniques. That fulfills the 'dynamic' part of the question.
I don't know how you read that question (well, ok, I do), but it's not how I read it. Whiff of an insult duly noted.
We did it because users demand it. A SPA feels substantially faster and more reactive. Users notice.
Dude! Whoever said we were railing on SPAs? But since you bring up Gmail I'd just like to note that gmail has been a slow, bloated mess for many years now. It takes a half a minute for the page to stop janking on my dev box with 50mbps internet, so I think Gmail in its current state is a poor choice of example. Gmail of old, back before they tried to cram 80 million things into it, was a pretty good example.
I don't know how you read that question (well, ok, I do), but it's not how I read it. Whiff of an insult duly noted.
We did it because users demand it. A SPA feels substantially faster and more reactive. Users notice.
Dude! Whoever said we were railing on SPAs? But since you bring up Gmail I'd just like to note that gmail has been a slow, bloated mess for many years now. It takes a half a minute for the page to stop janking on my dev box with 50mbps internet, so I think Gmail in its current state is a poor choice of example. Gmail of old, back before they tried to cram 80 million things into it, was a pretty good example.
> I don't know how you read that question (well, ok, I do), but it's not how I read it. Whiff of an insult duly noted.
I don't know how you read "provide search engines with indexable dynamic pages" as implementing your own search engine. It was pretty clearly referencing the well-known challenge of making your JavaScript-rendered pages indexable by Google/Bing/etc.
> Whoever said we were railing on SPAs?
You are. When you say we should just abandon all this JavaScript and instead render everything through Rails, you're arguing against building SPAs.
I don't know how you read "provide search engines with indexable dynamic pages" as implementing your own search engine. It was pretty clearly referencing the well-known challenge of making your JavaScript-rendered pages indexable by Google/Bing/etc.
> Whoever said we were railing on SPAs?
You are. When you say we should just abandon all this JavaScript and instead render everything through Rails, you're arguing against building SPAs.
Answer: a bunch of singular solutions that may or may not be tested/documented
Why do you want to write all that extra code instead of just picking the right tool for the job?
Why do you want to write all that extra code instead of just picking the right tool for the job?
This may surprise you, but we used to make web pages without JS. I know, it's a shocker!!! But guess what? 1 is irrelevant, 2 is irrelevant, 3 is there by default, 4 is easily solved, and so is 5. Turns out, logic on just the server side is simpler. It may not be as pretty, but please don't assume that your way is the only way.
When were you building web pages without JS? 1994?
Server side logic MAY be simpler in SOME cases. Overall applications have become a lot more complex over the last 20 years and your oddated methodologies have been replaced by tested thorough solutions built and used by some of the biggest companies in the world.
Server side logic MAY be simpler in SOME cases. Overall applications have become a lot more complex over the last 20 years and your oddated methodologies have been replaced by tested thorough solutions built and used by some of the biggest companies in the world.
Dude. This site has onlylike 6 lines of JavaScript, and that's just to make the arrows disappear after you click them.
Well, admittedly, I don't write webapps that often, as that's not actually my job. But last one I wrote without JS is also the last one I wrote period, about 2 months ago. Must be completely ramshackle and useless. Too bad it functions perfectly for me... Again, please don't assume that your way is the only way.
> Why does there seem to be a new framework popping up all that damn time?
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.
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.
>"the framework people"
As opposed to the unemployed people?
As opposed to the unemployed people?
"I feel like people who say "just use the dom" don't actually have enough experience to know why that is such a bad idea."
"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.
"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 am very good at what I do.
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.
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.
I'm not going to engage you on what you do, but you need to re-read some of the comments you've made. A lot of it is too hostile / oddly opinionated to be taken seriously, regardless of message. Whatever it is, it's not good communication.
I am not an evangelist, I'm not trying to win a popularity contest in this thread.
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.
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.
> a resume full of happy returning clients
You mean the people you refereed to as lacking technical expertise that you profit from? "Happy client" does not equal "superior code". Often clients will be happy just seeing the page load.
You implied earlier that a be-spoke js app by definition is spaghetti, poorly documented and generally inferior. I can't subscribe to that idea. I've seen the reverse as true also.
Risk of failure is what everyone wants to avoid. Another risk to avoid... Mediocrity. MVP is mediocre by definition, and the quickest way there is to slap a few frameworks on top of each other. Bells and whistles yet more.
I suppose striking the balance is what matters, and "right tool" and all that. But the right tool could indeed be a be-spoke app.
You mean the people you refereed to as lacking technical expertise that you profit from? "Happy client" does not equal "superior code". Often clients will be happy just seeing the page load.
You implied earlier that a be-spoke js app by definition is spaghetti, poorly documented and generally inferior. I can't subscribe to that idea. I've seen the reverse as true also.
Risk of failure is what everyone wants to avoid. Another risk to avoid... Mediocrity. MVP is mediocre by definition, and the quickest way there is to slap a few frameworks on top of each other. Bells and whistles yet more.
I suppose striking the balance is what matters, and "right tool" and all that. But the right tool could indeed be a be-spoke 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.
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.
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.
>If your app isn't complex enough to merit using a framework, then you aren't really building something worth talking about.
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...
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...
Complexity requires structure in order to be maintainable.
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.
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.
>Complexity requires structure in order to be maintainable.
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).
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).
>Complexity requires structure in order to be maintainable.
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."
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."
>and has a community of people working to make those components even better for YOUR USE CASE.
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.
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.
"I wouldn't hire you" is the quintessential Hacker News put down and I see it all the time. It's effectively saying "I disagree with you, and I want to make you feel bad by pretending I'm in a position of power over you."
Hilarious, and if a Hacker News bingo exists, it should be the free space.
Hilarious, and if a Hacker News bingo exists, it should be the free space.
I have to say I agree with a lot of your point but your tone comes off really agressive, I think frameworks are good particularly for inexperiences developets that will have a really hard time writing simple and maintainable code, but all people are saying is that in development you cannot just cross out bespoke development altogether there will always be a use case when you need to fine tune your software.
Saying that please bare in mind that I love react it's a great tool but like everything it has its place.
Saying that please bare in mind that I love react it's a great tool but like everything it has its place.
Frameworks add complexity not structure. The goal is to cover every relevant base which is complex. The imposed design rarely has any relationship to your problems at best they help manage the framework's needs.
"Both are signs of inexperience."
Case of pot calling the kettle black methinks.
Case of pot calling the kettle black methinks.
I like how you put "you could theoretically build a car from scratch". As someone who writes about and uses React daily, and have written things from scratch before, that strikes me as a really good way of explaining the utility of frameworks to newcomers.
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.
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.
'simple people' as opposed to?
I think people are coming down really hard on the article, and I found it to be light-hearted, and simply asking people to revisit where we're at. He doesn't call for anybody to stop using their frameworks. I am studying Erlang/LFE. I chose LFE over Elixir (I know it is not a framework), since I like Lisp rather than the Ruby-like syntax of Elixir, and because one of the creators of Erlang (Robert Virding) has his weight behind LFE; he created it. It is a subjective choice for me. Elixir is great, and a lot of Ruby hackers have picked it up. Do I need Erlang/BEAM/OTP ,right now? Certainly not, but I am studying it anyhow. If I get the chance to implement it for a job, would I do it just because I like it, and WhatsApp uses it effectively? No, unless a fit comes along for it.
I do think a lot of people aspire to work for FB and Co. and so they learn those their frameworks, and I would wager there is probably a lot of people trying to bring them into their smaller companies to get the chance to work with them.
I find the simile to building a car from scratch, stretching it if you are not FB, WhatsApp, or another biggie.
And you should be eager to be able to step into a smaller company who has outgrown its "homegrown" implementation and help them use a framework; you just shouldn't find your happiness only when your neighbor's cow dies ;)
But a smaller company shouldn't run with a framework with the vision they will be needing it in 3 years based upon no real analysis of their needs, but based just on wishful thinking. The money could be used to grow the company, and then adopt it at the appropriate time.
Nobody brings in a framework out of hope that it will lead to them getting a job at said sponsors company.
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.
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.
>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.
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.
If your app isn't complex enough to merit using a framework, then you aren't really building something worth talking about.
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.
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.
> If your app isn't complex enough to merit using a framework, then you aren't really building something worth talking about.
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...
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...
Some of the most useful things I've written have been the simplest.
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.
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.
[deleted]
I think the flame war that has erupted has a pretty simple explanation: some people forget the state of javascript just a few years ago. I am currently in the process of moving my team away from the monolithic dojo framework towards using more of the vanilla web standards, but I think dojo was a great choice at the time. The pains of cross-browser support, terrible vanilla APIs that were completely different in IE8 vs the rest of the web, etc. made frameworks "the way to go" in the past, and that's set us off in the direction we are going today of immediately reaching for one. Articles like this one are great in that they are helping to educate people on the power and ease of use that the modern web has to offer, but I can 100% see why people are going to skeptical for a while longer when it comes to using only vanilla javascript.
If you don't use one and have a complex app, it will eventually turn into a spaghetti mess of callbacks. You will end up writing your own framework that hasn't been battle tested on thousands of sites.
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.
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.
I wrote about that about 4 years ago, often called vanilla JS.
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.
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.
While we're at it, let's just write everything in spaghetti ASP because you don't need a [insert programming language here] framework.
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)