The title party is over. Let's talk about the specific meaning. We can see that the WebCompoents specifications are progressing a lot. Google's Polymer, Mozilla's X-Tags, Facebook's React, and some MV * frameworks, such as Angular, ractive, all use the custom tag function to enhance abstraction. HTML was too difficult to abstract, and now it has finally improved .. I want to know how many years will it take for everyone to make it easy? The title is in the bid. Let's talk about the specific meaning. We can see that the Web Compoents specifications are progressing a lot,
Google's Polymer, Mozilla's X-Tags, Facebook's React,
And some MV * frameworks, such as Angular and Ractive, all use the custom tag function to enhance abstraction.
HTML was too difficult to abstract, and now it has finally improved ..
I want to know how many years will it take for everyone to make it easy? Reply: Let's analyze the factors that make front-end development so difficult.
Let's take a look at the interface.
#1. Whether it is imperative or declarative
Without a doubt, for the writing interface, declarative code writing is much more efficient than imperative:
Panel p = new Panel();p.title = "Test";Button b = new Button();b.label = "Click me";p.add(b);
This answer is only intended to oppose the brains of wheels and wheels. [Don't Go To The comments area of this answer to give me your own respect .]
Microsoft launched HTML Component more than a decade ago, but the W3C created by netscape's Yuyi tried its best to block it. Now, we are waiting for Web Component. If the small group of people had honestly accepted the failure, the front-end would have had a good time. The current front-end is just as eager to get sold and pay for it.
On the wheel, can you not talk to fields you don't know? W3c was created by TBL and has a gross relationship with netscape. In fact, the original web components proposal (Behavioral Extensions to CSS)
) Is proposed by MS and Netscape.
[Reply to the question (tu) (cao )]
This question (How many years can front-end development be as easy as client development ?) It is also a premise that client development is easier than front-end development. In fact, browser-side development has long been more convenient and elegant than client-side development.
Of course, I agree with most of the analyses in @ Xu Fei's answer. But the answer is the challenge of web development, which is not compared with client development. In fact, client development leaders, such as WPF--XAML is obviously a lot of reference to the web development method. I think the front-end can be developed as smoothly as the client. Direct comparison directly. This is our new engine tool http://fireball-x.com/
I want to say that if I use WPF, QT or something, this project will be difficult.
If you are a crazy pursuit of Operation details like me, you will certainly want more customization and modifications to the native control when writing the interface. at this time, you will find that HTML5 interface writing is your good partner. for example: If you are a crazy pursuit of Operation details like me, you will certainly want more customization and modifications to the native control when writing the interface. at this time, you will find that HTML5 interface writing is your good partner. for example:
Design this kind of intimate gizmos:
Precise tree view insertion prompt:
Focus visual effects customized for each control:
There is even the dock/popup between Windows:
Once Dev Tools is started, you can adjust the style and Debug, which is in line with the pursuit of 1px by Virgos:
Update ==================================
I just answered the question and showed some of our undisclosed projects. I didn't think you would be curious about this project. I will briefly introduce the technical structure and selection process:
The entire project is built on Atom-Shell. we first wrote the code on Node-Webkit, but the Node-Webkit had many bugs, and the updates and feedback were not very timely, So we switched to Atom-Shell. the Atom-Shell project is highly active, and Report Issue basically replies on the same day. I found that Zhao Cheng, one of the authors of Atom-Shell, is amazing, and is also a green programmer on Github.
This is my combat power:
This is Zhao Cheng's:
So I am a brain program fan, and I like the programmers and their projects of fo's explosive combat capability. So we changed it to Atom-Shell.
The underlying UI is built on the basis of Polymer, So we play fashion very high! Shadow DOM, Custom Element, Object Observe, css flex, Web Animation, SVG, and any cool new technologies you can think of are all used in our editor development. at the beginning, I used Angular and React for the first version. Angular is not suitable for IDE-type programs because of its music structure. Don't spray me for specific music fans, I am a programmer who is not very familiar with frameworks and architectures. from small to large, I love to use the C language. Now I only write function + structure programming methods, what kind of object-oriented skills can't be used at all (I only know how to add the parent class's struct head in struct and only write func ptr ). the programming tool I used is also very rare. I wrote a Vim version called exVim: Home.
. Therefore, my programming philosophy is so old that I cannot accept Angular's height, while Polymer only adds a thin layer to some native things, in line with our original intention. react is mainly caused by two-way binding, which does not meet our project requirements. Otherwise, React is a good thing. it is estimated that my website and other things will depend on him in the future.
In the compilation layer, we use Gulp. In the above view, tupiao prefers simple things. grunt is a programmer like me who writes code using Vim. the main problem with Gulp is that its plug-in programming threshold is relatively high. After all, everything needs streaming, so the plug-in quality is generally inferior to Grunt. fortunately, our programmers are naturally fond of DIY and cannot write on their own.
After the selection of these main underlying technologies is completed, the rest is that the Code is not written every day (9) or night (6.
Our team is short of people. Although my programming is odd and my mind is old, my team members are free to choose and play.
If you are a front-end, back-end, full-stack, or excellent game engine engineer, or you just like to play with cool technology,
Or you can see the icon in the upper-right corner of the tool to understand what we will do in the future.
I happen to like the lifestyle in Xiamen and without logging in. I also happen to want to use Html5 and Nodejs to write cool things. Please contact us.
Send resume to: team@firebox.imThere should be no final answer to this question. What is "it's as easy as the backend", and the backend stuff is also the same, or so many people will do it.
It is true that you want to make it easier for yourself or your team. No matter whether the front end or backend end, you can find a way to improve R & D efficiency.
How to Improve R & D efficiency is a big topic, but the core is to adapt to your own team. It is not feasible to copy enterprise-level solutions from several teams.
1. Embrace the open-source community and reduce development costs. But you have to plan well, preferably a system (You Don't Need Yui if jquery is used ).
2. Use local debugging tools to reduce development dependencies between the front and back ends.
3. Automated construction and deployment, greatly saving time. You can check grunt.
4. modularization makes the code clearer and easier to maintain. Component, browserify, and seajs are all good choices.
5. Provides unit tests to ensure module quality.
The above work is to make developers focus more on code. As a programmer, you can only write code without worrying about the trivial things.
A lot of people have mentioned the issues at the code level. (Mobile phone code is so tired) I'm a little bit short. When is client development easier than front-end development? The key to my traversal is compatibility. So. A few years later. The backend is a unified environment. Historical pitfalls of various front-end vendors. Incomparable. In other words, even if everyone uses a browser. I think back-end development is much more complicated than front-end development ...... The knowledge index is not the foundation of an order of magnitude. I recently read some WebComponent stuff, including Google Polymer, and also tried to write some code for toys. Let's talk about your feelings.
Preface: the relationship between WebComponent and MV * is not that big, and the relationship with Angular and React is not so opposite. Angular and React are concerned with many problems than WebComponent, but in my eyes, they are not at one level and do not conflict with each other.
WebComponent helps us solve the problem of how to perform UI componentization development, while the MV * framework is at the upper layer, focusing on how to build applications.
Conclusion: I think Web Component is the closest to my ideal WebUI development.
HTML ImportTo help us import and manage a group of files. tell us that a group of files is equivalent to 1.css and 1. js.
Custom ElementIs an ideal component development method. It is not just as simple as encapsulating components in a custom tag, the user-defined elements are also provided with the same complete DOM system as the native HTML elements, such as DOM Events, such as document. createElement, such as lifecycle-related callback. You can expose your attributes through Attribute, and bind the interface like input to the value Attribute (more elegant !). You can also expose custom methods, such as. enable (),. disable (),. slideUp (),. expand (),. collapse () (more elegant !). Although there are still some unsatisfactory results, such as the strange feeling of using content and select, attribute and model bindings are not included (Polymer provides ).
Shadow DOMThe internal and external isolation of components is the ultimate. From then on, we can say goodbye to the lengthy CSS classname prefix and the structured naming method, and use a shorter, more semantic, and more functional classname, let each piece of CSS have its scope and change our views on CSS organization. Not only that, but the Shadow DOM can also isolate the internal and external DOM Events. This is really good. The Events in the Shadow DOM will only bubble to the Shadow Root and will not go up again, clean, no side effects, right?
The combination of the three gives me a great sense of foresight. I believe that one day in the future, for Web development, we can return to the nature of HTML, CSS, and JS-do you need a modal box? Okay, give you modal.html. You can import it. Your Content One, or document. createElement ('ui-modal'), and then hold its DOM node. show (),. hide.
Starting from a tag, it is like a black box. It gives you unlimited possibilities. In combination with two-way data binding, it can finally make WEB development more OO and declarative, one word: elegant!
All of this uses the technology we are familiar with: the DOM we are familiar with, the friendly event bubbling, simple tag nesting and combination, and the sophisticated CSS. You can even perform componentized development without learning any additional frameworks!
This is what I call returning to the essence of native GUI program development on major platforms over the years, and it is no easier than Web Front-end development. The complexity of computer-to-human interface problems limits its ability to create a framework like Ruby on Rails to simplify development. You can see that there is a total of logic between backend and front-end interfaces: routing, verification, CRUD, etc. If you limit the logic of the front-end interface to several types, or your interface will be very boring (for example, iOS applications made using official controls according to Apple's human-computer interaction Guide ), either this abstraction level is too high and you need to make too much concrete work. In fact, they are not easy, because they all have their own requirements.
However, as front-end development involves more "people" and the biggest uncertainties, the uncertainty of itself is also greater, closer to the category of "art"-When can I see that "art" has a definite paradigm? The backend processes logic, and the logic is more specific. But the industry is thinking about writing all the front-ends with js. The question subject has different perspectives.
