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.
> From the point of view of a product or business, it is very expensive to switch between tech stacks.
I totally agree with you. I was talking about the developers perspective.
When it comes to companies, not only is it difficult to transition from an unpopular tech stack, but it's also difficult to hire great developers because none of them want to work on such stack.
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.
This is not true at all. WebAssembly does not exist solely for performance. It exists because javascript is the sole ecosystem for web application development. By making WebAssembly a compile target we expand the universe of web development into something similar to Desktop development. Hopefully we can introduce the newer generation of developers into realizing how bad javascript really is as a programming language.
if you don't want to use JS to build CRUD apps, you can do that today.. just use .NET MVC and use C# and Razor. I happen to hate using the latter though
Sure, but using some other language than js could become attractive to people who avoid frontend because of it. Not that that makes it a good idea, per se.
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.
It's easier to ask what large company isn't using React. The PATENTS talk was odd because those same companies had and continue to use it with or without the new licensing.
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.
I'm not the biggest fan of react, but it's pretty easy to slap a single component into a project using the cdn, a single require and a single jsx file. I mean it isn't as easy as jquery, but it feels like it's in the some order of magnitude of difficulty.
You're too much in-the-know. You skipped the build chain required to make this work. And if you make one mistake or do something not by the book you could easily wind up shipping the development version of React to your users (which is slower).
I think the analogy is so apt because Dojo users made the same arguments back in the day; that it really was easy if you ignore all of the parts that were not easy. They weren't wrong! But that didn't make it ideal as a scaled down solution.
> You skipped the build chain required to make this work.
Same thing when you just include jQuery and plugins from a CDN.
> And if you make one mistake or do something not by the book you could easily wind up shipping the development version of React to your users (which is slower).
Same thing with using jQuery from a CDN.
React itself is also tiny compared to Dojo. And Dojo never did anything truly new. This is all old stuff re-packaged for the web. Web programming is still catching up with PC desktop programming from the 90's.
This is in response to how accessible React is to beginners (amateurism).
The original tutorial allowed beginners to get started quickly (via CDN), even allowing them to write JSX via script tags in their HTML.
They can take that HTML and host it anywhere.
The new tutorial requires the usage of create-react-app or running the code on CodePen.
A tweet by a React core developer with instructions on how to get CDN support working better reinforces the point about not being open to amateurism, by the way.
You can still get React from a CDN and don't need to use JSX, though if you really want JSX, as smarx demonstrates you can use standalone babel to compile JSX in the client: https://news.ycombinator.com/item?id=15522420
Yep, and it wasn't required of Dojo either. Optional complexity doesn't make something any easier to understand, especially when most documentation and community expects you to use the complex parts.
The whole point of JSX is to make working with React more like html, because it is easier and more readable.
> How's that an argument at all?
Huh? You mean, the argument that you shouldn't be sending un-compiled content to the client? I don't know why I'd have to argue for this, but render speed is one of the big reasons. Also download size. If you don't recompile, you have to include babel as well, on the client.
Are you saying you can do that with absolutely no build phase? For example, you can download vue.js and include it in your html page exactly like you could jquery.js back in the day and add a vue component to the page with no build step or toolchain or node.js or anything else involved at all. Is that what you are saying you can do with react?
Sure you can. (Same with Mithril.) You can use either library with just a <script> tag and no build process. The notion that you can’t and you have to use JSX + webpack is kind of absurd. It feels like that false notion has been perpetuated and got people thinking they need to use another library if they want to keep things simple.
Actually now that browsers have fetch, async and await, you can do a lot with just those and document.createElement. No need for frameworks.
You're missing the point, the same was true of Dojo.
The point is not that scaled down is possible, it's that it's the way. It's not for the sake of learning, like the React with script tags tutorial. It's how people actually build things with jQuery; they just start hacking.
I justified that with the word complex. In my mind, a complex app is one that is built and maintained by a team over a long period of time. I don't know what you're doing to maintain complex apps between a dozen (or couple dozen) developers on with <script> includes, ES5, and pure CSS & JQuery...but I'd really like to hear it in a blog post of some kind. I've worked on large code bases with those tools and it was a nightmarish experience just to upgrade to the latest version of JQuery. If you're fine churning your wheels doing all that stuff manually rather than depending on NPM...sure I suppose you can get by and waste a lot of precious time in the process. If you care about user experience and developer experience, however, build tools are absolutely essential.
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
If you already have html/css files, then "dropping them under /src/www" will already just work - that's how servers have worked since time immemorial, no "build step" required.
But compiling isn't what a web server does, and it seems like having the server automatically do what a developer is going to do anyway when they push to production, and likely not very often, isn't a significant gain in efficiency. The point of having a separate build chain for these types is that you're emitting what are meant to be static resources anyway.
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.
Apparently, I've been living in a completely different corner of the web than this guy.