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
347 コメント
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.
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.
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.
You don't need one, but if you don't eventually adopt one, you'll end up writing one.
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.
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.
"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.
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.
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.
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.
- 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.
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.
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!
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.
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 :/
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.
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)