React is the new Dojo(medium.com)
medium.com
React is the new Dojo
https://medium.com/@mikeal/react-is-the-new-dojo-18bd9059378f
68 comments
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.
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.
I agree and I disagree.
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 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 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...
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. 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.
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.
For all apps, other than graphic intensive 3D, there is no need to implement something using WebAssembly. The performance gain is simply not worth it.
This will be even more true as browser JS performance increases
This will be even more true as browser JS performance increases
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
Minification has already fucked it over for the most part
At the very least webassembly gets ypu drbug symbols, so maybe there's a chance you can go through it
At the very least webassembly gets ypu drbug symbols, so maybe there's a chance you can go through it
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.
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.
The one "designed to scale both with application complexity and team size" is actually Angular.
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 used not only by hipster San Francisco startups but gigantic companies like Facebook"
Uhhh... Obviously Facebook would be using it. That was useless filler insight. What other large implementations of React is out there?
Uhhh... Obviously Facebook would be using it. That was useless filler insight. What other large implementations of React is out there?
AirBNB, Twitter mobile, Walmart app, Spotify, Atlassian, Skype, Discord mobile, many more...
Microsoft, Amazon, Apple, Netflix.
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.
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.
Dropbox, Instagram, Yahoo, Uber, Lyft, Twitch.tv, Automattic(Wordpress), Imgur, Vimeo, Asana...
And Mithril.js for rendering with Tachyons for CSS is the new jQuery? :-)
https://mithril.js.org/
http://tachyons.io/
An example using that combination: https://github.com/pdfernhout/Twirlip7
An example using that combination: https://github.com/pdfernhout/Twirlip7
If we're following that analogy, why isn't React the new JQuery, with Angular taking the Dojo role?
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.
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.
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.
React used to work this way[1]. They removed support for the JSX parsing without a build step[2].
The new tutorial explicitly requires a build phase -- no more CDN and ad-hoc running.
1 - https://web.archive.org/web/20150202210539/http://facebook.g...
2 - https://reactjs.org/tutorial/tutorial.html
The new tutorial explicitly requires a build phase -- no more CDN and ad-hoc running.
1 - https://web.archive.org/web/20150202210539/http://facebook.g...
2 - https://reactjs.org/tutorial/tutorial.html
Actually, in fact, you can still use React 16 from a CDN. [1], [2]
1 - https://cdnjs.com/libraries/react 2 - https://twitter.com/dan_abramov/status/893099358484353024?la...
1 - https://cdnjs.com/libraries/react 2 - https://twitter.com/dan_abramov/status/893099358484353024?la...
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.
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
No pre-deploy build chain is required.
Even jsx can be compiled on the browser, seamlessly.
Even jsx can be compiled on the browser, seamlessly.
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.
You are right, I see why OP's initial statement was wrong about React being "simple" because you could make it simple.
Did Dojo expect the community to use the "optional complexity"?
Did Dojo expect the community to use the "optional complexity"?
No build chain is required, you don't even need JSX.
Correct, but it is more verbose and ugly to not use JSX. I guess the argument is you shouldn't be compiling things on the clients browser.
> Correct, but it is more verbose and ugly to not use JSX
I don't agree with that. I tend to prefer hyperscript to JSX (for personal projects) and I think it looks perfectly fine.
> I guess the argument is you shouldn't be compiling things on the clients browser.
How's that an argument at all?
I don't agree with that. I tend to prefer hyperscript to JSX (for personal projects) and I think it looks perfectly fine.
> I guess the argument is you shouldn't be compiling things on the clients browser.
How's that an argument at all?
You are saying this...
> 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.
var rootElement =
React.createElement('div', {},
React.createElement('h1', {}, "Contacts"),
React.createElement('ul', {},
React.createElement('li', {},
React.createElement('h2', {}, "James Nelson"),
React.createElement('a', {href: 'mailto:[email protected]'}, '[email protected]')
),
React.createElement('li', {},
React.createElement('h2', {}, "Joe Citizen"),
React.createElement('a', {href: 'mailto:[email protected]'}, '[email protected]')
)
)
)
var rootElement =
<Div>
<H2>Contacts</H2>
<Ul>
<Li>
<H2>James Nelson</H2>
<A href="mailto:[email protected]">
[email protected]
</A>
</Li>
</Ul>
</Di>
> 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?
I think this is what you're asking for:
<div id="root"></div>
<script src="https://unpkg.com/react@16/umd/react.development.js"></script>
<script src="https://unpkg.com/react-dom@16/umd/react-dom.development.js"></script>
<script src="https://unpkg.com/[email protected]/babel.min.js"></script>
<script type="text/babel">
ReactDOM.render(
<h1>Hello, world!</h1>,
document.getElementById('root')
);
</script>This is essentially what I meant. I think it's a great way to approach hacking on and learning React, Vue, or similar.
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.
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.
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.
That being said...build toolchains are essential for complex apps.
They may be useful and/or convenient but no, they are by no means essential.
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.
That sounds like work. With Angular, it's literally only
ng generate component my-component
ng generate component my-component
> used by hipster startups to Facebook
Well, yeah, it's developed by and for Facebook...that was a weird line.
Well, yeah, it's developed by and for Facebook...that was a weird line.
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 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
What about a web server that does the build step automatically, with no configuration required?
Something like webpack-dev-server, but usable both in production and development.
To deploy, drop your typescript/html/css files under /srv/www/ and your web server will take care of everything.
Something like webpack-dev-server, but usable both in production and development.
To deploy, drop your typescript/html/css files under /srv/www/ and your web server will take care of everything.
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.
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.
> 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.
Create-react-app is enough for most of the scenarios, and it requires precisely 0 configuration.
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.
Maybe if you live in a bay area startup filter bubble?
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.
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.
Like a small API surface or a tiny set of concepts to learn? Oh wait...
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.
Apparently, I've been living in a completely different corner of the web than this guy.