Really? Dojo won? jQuery never accomplished anything? For 10 years, people have been going to web conferences talking about how Dojo already did all this?
Apparently, I've been living in a completely different corner of the web than this guy.
This guy is a WebComponents evangelist of some sort.
I don't understand why so many people sweat over libraries, frameworks, and which one is going to "win". Once you learn to program properly, choosing a framework becomes a non-issue.
The bigger problem right now is the tooling ecosystem (webpack, babel etc). It's too difficult to set up and customize, especially for beginners. The packages change too often and you run into bugs all the time. Sometimes I wish we had a dumb-ass GUI to set up all this stuff. Customizability comes with complexity I guess.
From an individual developer standpoint, you should be able to transition between frameworks, libraries, and so on. You don't have to pick a single "winning" tech stack, although there are obviously transactional costs to becoming productive in a new tech stack.
From the point of view of a product or business, it is very expensive to switch between tech stacks. Most businesses can't afford to re-implement their product because there is a new 'hot framework'. I think there was an article on HN just within the last week about why Fortran is still a thing in some development circles.
So while I don't think it is necessary for there to be a single "winner", discerning which tech stacks have some long term stability and when the benefits of a transition outweigh the transactional costs of switching can be important.
I can't agree more with you, I recently started a huge open source project and the choice of front-end framework was changed about halfway through. The issue was never learning and working with the front-end framework even with a change, it was always just getting webpack/gulp/vueify/sass/babel/whatever amalgamation of tools we were using to pre-compile and compress everything. Once that was all setup everything was smooth sailing even with no experience on the framework.
To this day we are still having some minor issues with our tooling/builds and some odd configuration that we don't know if it's our fault or just something everyone deals with. The framework itself works as intended and is a joy to work with.
Well that and don't get me started on Selenium testing...
"The Web didn’t win because it was the favorite among enterprises and “real developers.” It won because it scaled down better than it scaled up. It won because it amateurized software development and unlocked the creativity of an entire generation of programmers that couldn’t participate in software until The Web."
This is what worries me about WebAssembly. If most web code goes binary, then it is no longer possible for the next generation of developers to View Source to see how things are built. Over the decades of doing web development, I've learned so much from looking at the source of other people's web sites. Even now with minimization and obfuscation it is pretty easy to run the code through some tools to get it back to a readable state.
> This is what worries me about WebAssembly. If most web code goes binary, then it is no longer possible for the next generation of developers to View Source to see how things are built.
A beginner already can't "see how things are built" in an application compiled with closure or whatever unless the developer ships sourcemaps to production, and then… nothing precludes having sourcemaps for webassembly.
jQuery is still around and still useful for a certain class of applications. But to say that jQuery won for rich web apps is to ignore all the churn we went through in frameworks and tooling to finally end up with Webpack, NPM, Babel and React.
React's target is complex apps. It's designed to scale both with application complexity and team size. jQuery never was designed to scale. And anyone who started with jQuery and built a rich single page app will generally tell you of all the imperative pitfalls you'll find.
The thing is, the web has evolved. The simple tools that attracted us to the web when web was mostly a presentation layer just don't cut it.
The "old" web is still there for beginners. If you want to learn to build basic websites without having to learn package management, numerous libraries and frameworks... jQuery is still a great option.
I'm always skeptical of loose analogies. 2017 isn't 2010. React is not Dojo. I'm not even saying React is the end all be all...but it works really well and it will continue to hold its position unless something better comes along that enough people are excited about to beat React's ecosystem.
For beginners there are tools like Next.js and Gatsby which allow you to create server rendered React apps with minimal config, setup, etc.
React also has React Native going for it, which is still young and booming.
jQuery is a syntax-sugar library. It's not comparable to react/redux, dojo, angular, or any other "framework". You could compare it to lodash, moment.js or similar.
I think the article explains it well, jQuery scaled down in a way that Dojo couldn't. I don't think you can fairly say that either Angular or React scale down in a way to enable the sort of amateurism that jQuery provided.
People who can't or won't invest the time to learn a tool that will boost their productivity...these are the people who determine the leading tools/frameworks??
At some point there has to be a next generation of web tools/frameworks. It's not like React will be around forever. Eventually it will bloat up just like these things always do and people will start asking themselves, "Isn't there a better easier way to do this"? I hope the author is right and the next generation of tools does away with a lot of the current complexity (especially the build step! - please no more need for cli, node.js, a "toolchain", etc.)
>>I hope the author is right and the next generation of tools does away with a lot of the current complexity (especially the build step! - please no more need for cli, node.js, a "toolchain", etc.)
If that's what you want, then it's not a function of a new framework to enable the vision you articulated. I think evolutions in the HTTP protocol is needed to allow unbuilt/unbundled code to be effectively delivered over the wire.
There is a clear distinction between how developers need to abstract and organize code vs how code is more efficiently processed by programs. The framework that the developer uses will always be designed to cater to what the user needs. If there is the need for a build/bundling step, then so be it. Framework designer should never sacrifice the former for an easier build/bundling step
Have a look at Elm. The problem with building webapps is not Dojo/jQ/React... It's JS itself. Also React is not enough to build a large webapp, you need various other tools as React is just the "V".
> please no more need for cli, node.js, a "toolchain", etc.
I'm okay as long as it is wrapped, and I do not have to fiddle with it for 95% of the use cases. Tools will always be part of the job, but the current JS situation is way too messy.
The build step wouldn't be too bad if it was a single command that didn't require any configuration. We're almost there already. Waste a few hours coming up with a good webpack config for your use case, and then you can mostly forget about it. Until the next breaking change of any library inside your build toolchain, at least. Or until the next hot build tool comes out /s.
The Angular Cli does a wonderful job of abstracting all of the webpack config from the user. One simply need to understand the ng build command and the associated parameters to effectively build the Angular project for server deployment.
React, Redux, Apollo, GraphQL, Express, Sequalize, and Postgres ecosystem seems like it is the new Drupal while Medium, Wix, and Shopify are the new Wordpress.
the Dojo AMD pattern sucks when you have too large of a collection of dependencies.. With Dojo you need to have exact matching order between your require collection and the parameters for your callback.
[+] [-] codingdave|8 years ago|reply
Apparently, I've been living in a completely different corner of the web than this guy.
[+] [-] rublev|8 years ago|reply
[+] [-] oldboyFX|8 years ago|reply
I don't understand why so many people sweat over libraries, frameworks, and which one is going to "win". Once you learn to program properly, choosing a framework becomes a non-issue.
The bigger problem right now is the tooling ecosystem (webpack, babel etc). It's too difficult to set up and customize, especially for beginners. The packages change too often and you run into bugs all the time. Sometimes I wish we had a dumb-ass GUI to set up all this stuff. Customizability comes with complexity I guess.
[+] [-] gwright|8 years ago|reply
From an individual developer standpoint, you should be able to transition between frameworks, libraries, and so on. You don't have to pick a single "winning" tech stack, although there are obviously transactional costs to becoming productive in a new tech stack.
From the point of view of a product or business, it is very expensive to switch between tech stacks. Most businesses can't afford to re-implement their product because there is a new 'hot framework'. I think there was an article on HN just within the last week about why Fortran is still a thing in some development circles.
So while I don't think it is necessary for there to be a single "winner", discerning which tech stacks have some long term stability and when the benefits of a transition outweigh the transactional costs of switching can be important.
[+] [-] overshard|8 years ago|reply
To this day we are still having some minor issues with our tooling/builds and some odd configuration that we don't know if it's our fault or just something everyone deals with. The framework itself works as intended and is a joy to work with.
Well that and don't get me started on Selenium testing...
[+] [-] irrational|8 years ago|reply
This is what worries me about WebAssembly. If most web code goes binary, then it is no longer possible for the next generation of developers to View Source to see how things are built. Over the decades of doing web development, I've learned so much from looking at the source of other people's web sites. Even now with minimization and obfuscation it is pretty easy to run the code through some tools to get it back to a readable state.
[+] [-] masklinn|8 years ago|reply
A beginner already can't "see how things are built" in an application compiled with closure or whatever unless the developer ships sourcemaps to production, and then… nothing precludes having sourcemaps for webassembly.
[+] [-] jordache|8 years ago|reply
This will be even more true as browser JS performance increases
[+] [-] setr|8 years ago|reply
At the very least webassembly gets ypu drbug symbols, so maybe there's a chance you can go through it
[+] [-] chrisco255|8 years ago|reply
React's target is complex apps. It's designed to scale both with application complexity and team size. jQuery never was designed to scale. And anyone who started with jQuery and built a rich single page app will generally tell you of all the imperative pitfalls you'll find.
The thing is, the web has evolved. The simple tools that attracted us to the web when web was mostly a presentation layer just don't cut it.
The "old" web is still there for beginners. If you want to learn to build basic websites without having to learn package management, numerous libraries and frameworks... jQuery is still a great option.
I'm always skeptical of loose analogies. 2017 isn't 2010. React is not Dojo. I'm not even saying React is the end all be all...but it works really well and it will continue to hold its position unless something better comes along that enough people are excited about to beat React's ecosystem.
For beginners there are tools like Next.js and Gatsby which allow you to create server rendered React apps with minimal config, setup, etc.
React also has React Native going for it, which is still young and booming.
[+] [-] trumbitta2|8 years ago|reply
[+] [-] oldboyFX|8 years ago|reply
[+] [-] demonshalo|8 years ago|reply
[deleted]
[+] [-] jordache|8 years ago|reply
Uhhh... Obviously Facebook would be using it. That was useless filler insight. What other large implementations of React is out there?
[+] [-] chrisco255|8 years ago|reply
[+] [-] pdfernhout|8 years ago|reply
An example using that combination: https://github.com/pdfernhout/Twirlip7
[+] [-] mhd|8 years ago|reply
[+] [-] Touche|8 years ago|reply
[+] [-] water42|8 years ago|reply
Well, yeah, it's developed by and for Facebook...that was a weird line.
[+] [-] gwt4life|8 years ago|reply
[+] [-] irrational|8 years ago|reply
[+] [-] jordache|8 years ago|reply
If that's what you want, then it's not a function of a new framework to enable the vision you articulated. I think evolutions in the HTTP protocol is needed to allow unbuilt/unbundled code to be effectively delivered over the wire.
There is a clear distinction between how developers need to abstract and organize code vs how code is more efficiently processed by programs. The framework that the developer uses will always be designed to cater to what the user needs. If there is the need for a build/bundling step, then so be it. Framework designer should never sacrifice the former for an easier build/bundling step
[+] [-] cies|8 years ago|reply
> please no more need for cli, node.js, a "toolchain", etc.
I'm okay as long as it is wrapped, and I do not have to fiddle with it for 95% of the use cases. Tools will always be part of the job, but the current JS situation is way too messy.
[+] [-] stefano|8 years ago|reply
[+] [-] jordache|8 years ago|reply
[+] [-] d2kx|8 years ago|reply
I don't see React "winning" on a major scale at corporations here in Europe.
Tbh I am quite shocked whenever I read about advances in React that Angular has had for quite a while.
[+] [-] k__|8 years ago|reply
[+] [-] zappo2938|8 years ago|reply
[+] [-] zerr|8 years ago|reply
[+] [-] jordache|8 years ago|reply
[+] [-] dk28|8 years ago|reply
[deleted]