>what makes js one of the most used languages is it's crazyness
No.. it's ubiquity in the browser alone made it one of the most used languages. Obviously, when there is only one game in town, that game is going to be popular.
People hate javascript and its "crazyness" so much that the entire universe of modern web development was designed around using other languages which "compile" to it so that developers could avoid direct contact with it as much as possible. What other language gets treated like a contagion by its own users?
You can learn React in a day. The API is composed of less than ten functions.
To answer part of your question, Promise.js has become formalized in the ECMAScript standard, so maybe not the best example.
These frameworks emerge to make it convenient to solve problems that JS does not offer an easy way to solve. I don’t see anything philosophically wrong with that; in fact, I would argue it’s a big driver of JS adoption. Prototypical inheritance makes it very easy to bend javascript to your will.
If you don’t like the frameworks you don’t need to use them, but it’s going to harm your career if you actively avoid learning how to use frameworks that are deployed with increasing frequency on new projects.
The other advantage of frameworks is that they provide common idioms and enforce procedural standards, both of which make working on a team more productive as everyone has the same base of understanding. They also make it easier to hire for that team.
Try implementing any sufficiently complex app in vanilla JS and you’ll likely end up recreating many of the aspects of popular frameworks, except your “internal framework” will be messy, undocumented, and unique to your project, severely reducing maintainability and increasing onboarding time of new developers.
Maybe React itself, but everything else that goes into doing react development; design patterns, gotchas, testing, webpack, native and so on? That takes far longer than a day, and is what most would expect when being able to really say they "know react".
Agreed, but as I mentioned in my edits of the comment, you’ll likely end up needing to solve all these problems in vanilla JS as well. So it’s really a question of picking your poison.
Also, many of the concepts you need to learn for proficient react development are auxiliary to react and could be applied to vanilla JS or really any UI framework. Any UI is fundamentally a state machine, and solutions to implementing it all require state management and clean separation of the presentation and data layers.
I don't want to turn this into another misguided "JS sucks" thread[0], but here's an example from create-react-app, the official point of entry for people learning React:
The README included on a project generated through CRA is 116KB. A screenshot of that page rendered in GitHub is 60054px tall.
Honestly, I don't know if this could be made simpler or easier. React and its ecosystem deal with complex problems that can't always be reduced to simple explanations. In the case of this README, of course a lot of it is about specific setups that most beginners don't need to care about, but that CRA, being the blessed point of entry, still should support, or it would lock everyone into a Facebook workflow.
I think many developers would be better served by entering frontend development not through React, but through the basics (HTML, CSS, JS) and other ecosystems.
[0]: Unrequested opinion: frontend developers reach for bigCo solutions — whatever Facebook/Google/some billion-dollar startup uses — when smaller, lesser known, "boring" or exploratory solutions could be better, trying to solve problems they don't have.
Good point. What I meant by "point of entry" wasn't the way to learn React as an absolute beginner, but the official tool to use after you've learned the basics of React itself. A beginner can (and should) go far without a build system.
How and where can you learn react in a day? Thats the problem in the real world, you can learn about react within a day, you need more and lots more time to master react and all that comes with it.
At my last company, we found the opposite to be true. Switching to React made hiring all but impossible. Our Ruby devs mostly refused to learn the new stack and left, and most of the people we did hire to replace them were Java developers. I only met one hire who was immediately productive on our stack and she said it's because she had spent the past few months learning programming for 70 hours a week (!). She left 3 weeks later for a better paying job. Front-end development is absolutely bonkers right now.
You can't build an application using React alone. You also need to learn ReactRouter and Redux, which add lots of complexity. Not to mention, if you spent only one day learning React you're probably going to do it wrong: you have to learn things like where to put state, when you have a hierarchy of components. Learning the "ten functions" of the API isn't enough!
Very silly. If you are keeping up with the latest and greatest in JS, you have the 20 minutes to sit down and learn the basics of a framework that will make your life a bit easier. This argument will never end, code hipsters need their voices heard.
I think its easier to say that because of the past history of moving targets with JS. The "aha" moment you get with React is it abstracts things in a very easy to understand way with JSX at its heart. You then find it quite easy to move from React Web to React Native to React VR or whatever other thing they cook up because its just simple to look at abstraction without the hairy object boilerplate that you are normally subjected to.
Maybe React itself is just another flavor but the JSX paradigm is really the goodness I think more frameworks could use which cough cough was done by Microsoft a long time ago.
Afaict vanilla js these days is much less relevant than any of the current frameworks. Is it really that big of a deal to learn a new framework/library every now and then? They're really not that hard to learn and the productivity boost is definitely worth the investment. Hype is not at all the reason they're popular.
The problem isn't learning the frameworks; the problem is creating code that relies on them and has to be supported for years, which may or may not be longer than the active lifespan of the framework.
Regardless of whether web components would actually be a stand-in for things like React: what makes you think that integrating something in the language results in it being there to stay? If Angular 1's two-way data binding had been added to HTML proper, I'd still have moved on to a virtual DOM-based approach.
Serious question: does anyone still care about Web Components? They still don't work cross platform, they have substantial limitations, and they lack many of the important features that React and others come with by default (event handling, anyone?).
For real, try to build a form with React, then try to build the same form with Web Components. It's a nightmare going from controlled inputs to manual DOM fiddling. Even just telling the parent component about the form submission means creating and dispatching your own event!
Is the point of Web Components to service frameworks? I really don't see who the intended audience is, because any half decent framework is infinitely simpler to work with.
People definitely still care about Web Components. They have evolved quite a lot over the last couple years, and there are some very nice helper libraries that have come out for them (skate.js, stencil.js)
I agree that state management/binding is hard, in general, but I'm sure that these Web Components helper libraries will be more and more sophisticated as time goes by. Also, isn't it pretty much standard to use redux/mobx for state management with React? Why not use these kinds of tools with Web Components? In the past I've used slots and symbols to communicate between parents and children without exposing all the guts of my components.
Aside from that, there's not really any good reason I can see that React itself couldn't/shouldn't support Web Components at some point soon.
The guy I replied to is saying that he needs to use third party libraries just for state management and data binding. Pretty much every non-trivial component is going to need these features, and if they're using a library to get them, we're back to the same situation we were in before Web Components.
The whole point of Web Components is that all of the innards of components are completely encapsulated in a component, the 'client' of a component only cares about setting its attributes and responding to the events that it emits. (And perhaps supplying external styles.)
I also think your claim of having to use 3rd party libraries for anything non-trivial is false, but let's ignore that for now.
Any framework that's integrated into browsers with no extra runtime to parse is worth caring about. Not disagreeing that the current state of Web Components is pretty bad, but the more recent versions of React are still a 100KB runtime - that's not great either!
That used to be the same argument for using jQuery instead of native JS and DOM, but now much of jQuery's goodness is native. I predict the same thing will happen with React. Like jQuery it will still be useful and will probably be somewhat cleaner, but most of its value will have gone native.
Most modern front end frameworks are younger than Web Components. They've rebooted the spec at least once. Even after half a decade, there's still no good way of even managing state with Web Components.
Really I'm not sure what we're waiting for at this point. The only thing Web Components have really solved is component isolation, but that's not something folks really struggle with these days.
Frankly, not that much. Most of the APIs are still the same imperative you-can-only-do-one-thing-at-a-time hell, often with very limited capabilities compared to jQuery.
And yes, whoever made the decision to return NodeLists instead of arrays everywhere should at least re-evaluate whether they should really be doing programming.
Yep. Fetch is very low level. Chaining is a godsend. Adding elements is way shorter with jquery. All the vanilla js project i've seen end up writting a poormy tested a'd documeted half backed jquery little brother. It's not a win.
In remembering this issue I had, I made a frankenstein promise return object mimicking fetch's interface called "retch" but didn't publish it. It allowed progress and cancelling. It made me think would be nice to have a promise interface standard class you could inherit from where you could add sugar to it so the chain would remain consistent with your additional functionality. Anyhoo.
I agree, and I prefer jQuery over native. It's still better, and does more. My point was that people say we don't need it anymore because the features it introduced are native now, and I think that's going to be said about React and Web Components too at some point. The same counter-argumemt will also be said: people will defend continued use of React because it will still be better, and will still do more. Just like jQuery.
Since I never really learned jQuery, I can't attest to how much of modern JavaScript is based off of it. But looking an a quick reference for jQuery, it's pretty obvious that a huge part of it did not become standard. So all of the time invested in learning those features is wasted. Any application using those features is permanently locked in to a nearly obsolete framework. And the owners of those applications is now forced to find developers who both know and admit to knowing jQuery knowing they'll be dooming themselves to supporting old legacy code.
The point of Web Components is namespacing (variable and styling scope), composability (one component inside the other) and cacheing (fewer network calls). Now, frameworks can work with the browser to provide those features instead of working against the browser to emulate them.
> Is the point of Web Components to service frameworks? I really don't see who the intended audience is, because any half decent framework is infinitely simpler to work with.
Originally Web Components were a response to web developers waiting for years to HTML elements like date pickers and such to be added to the standard. With web components, it will be possible to create such elements once and integrate them with every front-end project just like you'd use e.g. a <select>.
Using them as a framework for building web applications has mostly been propagated by e.g. Polymer, but as I and many others who have tried it can attest: that doesn't work too well.
Still, for components I think Web Components will be a great addition, and should combine nicely with React.
I don't think web components were intended to be used directly by average users; even a basic abstraction layer makes the tedious bits easier. Take this to its logical end and you have something like [skatejs](https://github.com/skatejs/skatejs), an abstraction layer over web components that you'd probably find very familiar and easy to use.
In that sense, web components aren't meant to compete with react and other frameworks, but to serve as an alternate, native foundational layer for frameworks.
This is OK. It compares some of the features of Web Components and React components as they stand today. Having recently used Web Components in a side project, I will say that I wish it touched more on how to give Web Components reactivity. The author touches on data binding, but doesn't really go too deeply into what will be one of the most customized (ergo hard to maintain) pieces of the VanillaJS code.
Polyfills also add an interesting twist. You can use them to enable Web Components in Firefox, but they mimic shadowdom behavior imperfectly. You need to be very careful of how you use CSS in that case.
Lastly, there seemed to be some gotchas in ES6 module loading a few months back. Perhaps those have been fixed. At the time, I found it hard to debug modules that failed to load.
In any case, I'm always happy to see Web Components and more powerful/useful features being added to JavaScript in the browser. Frameworks like React serve useful purposes, and it's great that we have a platform that allows us to move quickly and bring new patterns to life without waiting for browsers. In the long term, though, I will always be an advocate for standards and making vanilla implementations feasible.
Believe me, I want to touch more on Web Component reactivity, but I don't have the depth of knowledge yet to really expound on it in a blog post. Happy for others to fill the gap in the meantime though. :)
I definitely agree with pretty much all your points. I think it's a pretty exciting time for web dev right now.
Yeah, I wish I could call myself an expert there, too, but I've still some exploration to do before I'm really happy with how I have it set up, let alone recommending it to others.
Awesome that you're here responding, though. Great post, overall! (Sorry if my points were mostly critical...I glossed over the parts I liked.)
Haha, I always expect far worse when sending a blog post like this out there. It's the nature of the medium and I try to take it in stride. Your comment was good-natured, so no worries.
What I'm getting at is that the reason web standards are slow is because they go through a long vetting and trade-off discussion between various stakeholders to flush out flaws and make conscious compromises. React has not gone through this process, and was created for Facebook's needs. It would need to go through the same process before becoming a standard.
Web Components are an overly-verbose under and overspecified near-monstrosity that cannot even function on its own without throwing in Polymer/Skate/whatever.
"React-like" components in the article are to React what rocks are to a CNC machine. I also encourage you to count the number of problems the author mentions vs. the number of advantages.
If you want even more react-like web components, we built Stencil to use JSX and output plain web components as we move to WC's for Ionic Framework: http://stenciljs.com
60 comments
[ 2.8 ms ] story [ 146 ms ] threadThe pure Web stack skills stay, while framework specific skills are only good until the next JS Framework hype cycle.
Where are Dojo, MooTools, YUI, Promise.js now?
In a couple of years React, Angular, Vue, Polymer might join them, but VanilaJS, HTML, CSS skills will stay relevant.
No.. it's ubiquity in the browser alone made it one of the most used languages. Obviously, when there is only one game in town, that game is going to be popular.
People hate javascript and its "crazyness" so much that the entire universe of modern web development was designed around using other languages which "compile" to it so that developers could avoid direct contact with it as much as possible. What other language gets treated like a contagion by its own users?
To answer part of your question, Promise.js has become formalized in the ECMAScript standard, so maybe not the best example.
These frameworks emerge to make it convenient to solve problems that JS does not offer an easy way to solve. I don’t see anything philosophically wrong with that; in fact, I would argue it’s a big driver of JS adoption. Prototypical inheritance makes it very easy to bend javascript to your will.
If you don’t like the frameworks you don’t need to use them, but it’s going to harm your career if you actively avoid learning how to use frameworks that are deployed with increasing frequency on new projects.
The other advantage of frameworks is that they provide common idioms and enforce procedural standards, both of which make working on a team more productive as everyone has the same base of understanding. They also make it easier to hire for that team.
Try implementing any sufficiently complex app in vanilla JS and you’ll likely end up recreating many of the aspects of popular frameworks, except your “internal framework” will be messy, undocumented, and unique to your project, severely reducing maintainability and increasing onboarding time of new developers.
Maybe React itself, but everything else that goes into doing react development; design patterns, gotchas, testing, webpack, native and so on? That takes far longer than a day, and is what most would expect when being able to really say they "know react".
Also, many of the concepts you need to learn for proficient react development are auxiliary to react and could be applied to vanilla JS or really any UI framework. Any UI is fundamentally a state machine, and solutions to implementing it all require state management and clean separation of the presentation and data layers.
https://github.com/facebook/create-react-app/blob/master/pac...
The README included on a project generated through CRA is 116KB. A screenshot of that page rendered in GitHub is 60054px tall.
Honestly, I don't know if this could be made simpler or easier. React and its ecosystem deal with complex problems that can't always be reduced to simple explanations. In the case of this README, of course a lot of it is about specific setups that most beginners don't need to care about, but that CRA, being the blessed point of entry, still should support, or it would lock everyone into a Facebook workflow.
I think many developers would be better served by entering frontend development not through React, but through the basics (HTML, CSS, JS) and other ecosystems.
[0]: Unrequested opinion: frontend developers reach for bigCo solutions — whatever Facebook/Google/some billion-dollar startup uses — when smaller, lesser known, "boring" or exploratory solutions could be better, trying to solve problems they don't have.
At my last company, we found the opposite to be true. Switching to React made hiring all but impossible. Our Ruby devs mostly refused to learn the new stack and left, and most of the people we did hire to replace them were Java developers. I only met one hire who was immediately productive on our stack and she said it's because she had spent the past few months learning programming for 70 hours a week (!). She left 3 weeks later for a better paying job. Front-end development is absolutely bonkers right now.
For example, I am glad I did not spend more than a few minutes looking at Coffescript.
You can't build an application using React alone. You also need to learn ReactRouter and Redux, which add lots of complexity. Not to mention, if you spent only one day learning React you're probably going to do it wrong: you have to learn things like where to put state, when you have a hierarchy of components. Learning the "ten functions" of the API isn't enough!
And it's not like "Vanilla JS" isn't a moving target itself.
Maybe React itself is just another flavor but the JSX paradigm is really the goodness I think more frameworks could use which cough cough was done by Microsoft a long time ago.
Those who master the platform win, regardless of flavour of the month Framework that one puts on top of it.
For real, try to build a form with React, then try to build the same form with Web Components. It's a nightmare going from controlled inputs to manual DOM fiddling. Even just telling the parent component about the form submission means creating and dispatching your own event!
Is the point of Web Components to service frameworks? I really don't see who the intended audience is, because any half decent framework is infinitely simpler to work with.
I agree that state management/binding is hard, in general, but I'm sure that these Web Components helper libraries will be more and more sophisticated as time goes by. Also, isn't it pretty much standard to use redux/mobx for state management with React? Why not use these kinds of tools with Web Components? In the past I've used slots and symbols to communicate between parents and children without exposing all the guts of my components.
Aside from that, there's not really any good reason I can see that React itself couldn't/shouldn't support Web Components at some point soon.
The whole point of Web Components is that all of the innards of components are completely encapsulated in a component, the 'client' of a component only cares about setting its attributes and responding to the events that it emits. (And perhaps supplying external styles.)
I also think your claim of having to use 3rd party libraries for anything non-trivial is false, but let's ignore that for now.
Really I'm not sure what we're waiting for at this point. The only thing Web Components have really solved is component isolation, but that's not something folks really struggle with these days.
Frankly, not that much. Most of the APIs are still the same imperative you-can-only-do-one-thing-at-a-time hell, often with very limited capabilities compared to jQuery.
And yes, whoever made the decision to return NodeLists instead of arrays everywhere should at least re-evaluate whether they should really be doing programming.
The major thing still missing is upload/download progress.
Since I never really learned jQuery, I can't attest to how much of modern JavaScript is based off of it. But looking an a quick reference for jQuery, it's pretty obvious that a huge part of it did not become standard. So all of the time invested in learning those features is wasted. Any application using those features is permanently locked in to a nearly obsolete framework. And the owners of those applications is now forced to find developers who both know and admit to knowing jQuery knowing they'll be dooming themselves to supporting old legacy code.
Originally Web Components were a response to web developers waiting for years to HTML elements like date pickers and such to be added to the standard. With web components, it will be possible to create such elements once and integrate them with every front-end project just like you'd use e.g. a <select>.
Using them as a framework for building web applications has mostly been propagated by e.g. Polymer, but as I and many others who have tried it can attest: that doesn't work too well.
Still, for components I think Web Components will be a great addition, and should combine nicely with React.
In that sense, web components aren't meant to compete with react and other frameworks, but to serve as an alternate, native foundational layer for frameworks.
Polyfills also add an interesting twist. You can use them to enable Web Components in Firefox, but they mimic shadowdom behavior imperfectly. You need to be very careful of how you use CSS in that case.
Lastly, there seemed to be some gotchas in ES6 module loading a few months back. Perhaps those have been fixed. At the time, I found it hard to debug modules that failed to load.
In any case, I'm always happy to see Web Components and more powerful/useful features being added to JavaScript in the browser. Frameworks like React serve useful purposes, and it's great that we have a platform that allows us to move quickly and bring new patterns to life without waiting for browsers. In the long term, though, I will always be an advocate for standards and making vanilla implementations feasible.
I definitely agree with pretty much all your points. I think it's a pretty exciting time for web dev right now.
Awesome that you're here responding, though. Great post, overall! (Sorry if my points were mostly critical...I glossed over the parts I liked.)
Web Components are an overly-verbose under and overspecified near-monstrosity that cannot even function on its own without throwing in Polymer/Skate/whatever.
"React-like" components in the article are to React what rocks are to a CNC machine. I also encourage you to count the number of problems the author mentions vs. the number of advantages.
(The lib is 200 lines, so it is almost the same as VanillaJS)