Original: No more JS frameworks Byjoe Gregorio
Stop writing JavaScript frames.
The JavaScript framework is like death and taxes: it inevitably exists. I'm sure if I was a fly on that wall, every time someone started a new Web project, the first question was definitely which JS frame we were using. This is today's industry-to-JS framework of the deep-rooted thinking mode. But in fact it does not need to be so, on the contrary, the need to stop using the JS framework.
Let's see what we have.
Angular, Backbone and Ember, oh, mom.
For a long time, the most concise description of the Web platform and technology stack for HTML+CSS+JS is disaster (a lack of a better explanation). Who can forget IE's box model or layer label? I believe I only use these words to let some of you get back to that horrible web development era.
For a long time there was a lot of inconsistency between browsers, and as insiders we had to write a framework to cover up these issues. The problem is that there are some fundamental issues that are inconsistent between browsers, such as how events are propagated or what tags are supported, so that each framework not only compensates for these vulnerabilities, but also designs their own browser-run models. In fact their models, many models, because you have to invent a model for event propagation, invent a model for DOM, and so on. The inventions of many models are continuing. So wrote a frame, each like a snowflake, thousands of flowers bloom, brought us jquery and Dojo and MochiKit and Ext JS and Angularjs and Backbone and Ember and react! Over the past 10 years, we have concocted a whole bunch of JS frames.
But a lot of other things have happened in the past ten years, and browsers are better than before. Browsers have greatly improved the standard support, and there are now some browsers that are constantly evolving: they can automatically update the browser, and each new version has better performance and better adaptation to the standard. The new standards are as follows:
- HTML Import
- Object.observe
- Promises
- HTML templates
I think it's time to rethink the JS framework model. Now it's no longer necessary to create another way, just use Html+css+js.
So why do we have to write the JS framework? I think the reason is probably inertia, which is a habit. But it does not, it is not like the framework is active harm, right? Well, let's take a look at the web framework to define what I'm talking about. This is actually a gradient code that starts with a small piece of code, like the main thrust of the code, followed by a large section of code summarization, then up to the library, and finally the framework.
Theme ---Library--framework
The framework is more than just a larger library, and the framework has models that interact with events and DOM. So why not frame it?
abstract , one of the problems with the framework is their selling point, the framework is abstracted from the platform, so you can focus on building your software. The problem is now you have two systems that need to learn, html+css+js and frameworks. If the frame is a perfect pull out of a Web page like a platform, you don't have to cross the frame, but guess what, the frame is not so perfect. So you have to know Html+css+js, because in some cases your program doesn't run as you think, then you need a layer of inspection framework to find out what went wrong. Until the HTML+CSS+JS is checked.
Drawing Icebergs
The frame is like an iceberg, 10% floats above the water, it is not dangerous to open, the hidden 90% will kill you. In fact there are more apt, learning a framework like drawing an iceberg, in order to use the framework you need to learn the whole iceberg, but the final running process is meaningless, because the iceberg will melt.
Widgets, the other selling point of the framework is that you can read access to the Widget's library. But you do not need a framework to access widgets, they should all be independent. A good example is Codemirror, a JavaScript-made syntax highlighting the code editor. You can use it anywhere, without a frame.
Using frames to make widgets will also lose the effort you've made before. Remember all the mochikit widgets that you wrote? Right, now transfer it to ember or angular, are those widgets okay to make?
Data Binding , honestly I never needed it, but if you need it, it should be the library, not the framework.
A longer-term problem with the framework is that the framework ends up as silos, and the landscape and widgets they split for frame a cannot run under frame B. Your efforts are in vain.
So what is the post-frame world like?
Html+css+js is my frame.
The basic idea is that the framework is not required to create your widgets with Html+css+js's internal functionality. The whole block of material is divided into orthogonal components and can be arbitrarily combined. The final fragment can be under the umbrella of the Web Component.
HTML import, HTML templates, custom elements, and shadow Dom are all techniques that allow us to cut off the core of the framework and create reusable elements and functions. For a more detailed and better introduction, refer to the following articles and libraries:
- HTML Import
- Polymer
- X-tag
- Bosonic
So, we create <X-FLIPBOX>, declare victory, and then go home?
No, the first thing you need to do with Web Components is putty paste for this function, such as X-tag and polymer. The demand for this part is reduced over time, as browsers materialize the implementation of these specifications.
Emphasize that these putty pastes are not frames, using their own models to develop Web pages, putty Paste can be used HTML5 model. But this is not the only need, in the same platform there are some small differences, because the current standard, the browser will be in some small areas of deviation, which requires putty paste. MDN seems to require a lot of code, because the files often contain short putty pastes for each function.
So a huge HTML 5 Putty Paste Library is good, but the better is what I call Html-5-polyfill-o-matic, a group that allows me to write Web Components through bog standard html+js through static analysis or runtime Object.observe After analyzing my code, it produces an exact subset of the full HTML 5 putty paste for my project.
When I started trying to mix and match Web components and libraries of multiple resources, such functionality would be more important, such as a x-tag <x-foo> and polymer <core-bar>, which meant I would include these two putty pastes? What am I supposed to do to get these custom elements? X-tag and brick have custom bundle generators:
- Brick Download
- X-tag Download
If I start creating custom elements, do I need to create my own custom bundle? I don't think that's an extensible idea, and I believe that we need idioms and tools to deal with them better. This may actually mean changing how we open resources, a "widget" is not a project, so the way we handle these things changes. Sure, put the code in git, but do you need to pay for a github project? It would be more appropriate to have something smaller and closer to gist than the current project. How do I minimize/harden all of these codes into the correct format for my project? Things like asset graph may be a good start.
So what do we need now?
1. Set up idioms and instructions for reusable components.
2, in these idioms compile, crash, run, and other tools, all HTML, CSS and JS.
3, an extensible HTML 5 putty Paste (Polyfill), based on the actual use of all or proportionally reduced.
This is the future of creating a new model that does not need to learn the latest frameworks we need, instead, we just work directly with the platform, pull in custom elements and libraries to meet specific needs, consume time to create applications, rather than mark icebergs.
FAQ
q : Why do you hate the authors of frames?
answer : I don't hate them. Some of my best friends are also framework authors. I admit that it's a bit of inspiration that you've already ruined JavaScript, joking, but again, without mocking the framework author's meaning.
q : In HTML 5 you can not do xxx, for this, you need a framework.
A: First, this is not a problem. Secondly, thank you for pointing out this matter. Now let's get this together, HTML 5 allows you to complete XXX without a frame.
q : But XXX is not a frame, it is a library!
A: Yes, as I said, it's a gradient code, from the gist to the frame, you might draw a slightly different line from mine. This is possible, it's not about a particular software category, it's about moving away from the frame.
Q : I have been using XXX and XXX for many years.
A: Again, this is not a problem, but it doesn't matter, this is good for you ah, you should be in a better state to help others.
Q : So everyone needs to rewrite the dropdown menus, tables, sliders, and triggers?
A: Absolutely not, the point is that there is a way to create these elements, a way of not buying a particular framework.
q : Dude, all those HTML imports will degrade the performance of my site.
A: Yes, if you're naïve about using these things, it will, that's why I mentioned the need for a compiler and crash tool for HTML, CSS and JS.
Q : So I don't recommend using any libraries?
A: No, this is not what I said, I have carefully depicted the boundaries between the library and the framework, and one library provides the orthogonality of functionality that can be used by other libraries. The library is available, but the framework is what I would like to see people no longer use.
Q : But I like data binding!
A: A lot of people like it, I just express my own personal preferences. I didn't say you shouldn't use data binding, but you don't need to use an entire framework to get data binding, there's a separate library to do this.
Don't use the JS frame anymore.
