preface
The year 2016 is fast approaching, and like each of the past six years, the Web front end is once again in a state of “unrecognizable” and “refreshing” change, with the old constantly being weeded out and the new at risk. The open source community is constantly churning out new concepts, new frameworks, and new tools. Some of the most popular technologies of last year have been further evolved and upgraded this year, but there is still no guarantee that the future of the front end belongs to them. In the context of the cooling of the overall capital market this year, the start-up company of TO B shows strong vitality. This type of business also brings obvious differences to the work of the Web front end, and the overall skill direction of engineers also shows a slightly different branch.
1. Updated network and software environment
1.1 The continued popularity of HTTP/2
In the middle of this year, almost all modern desktop browsers have HTTP/2 support, and mobile can still cover almost all platforms by downscaling to SPDY, making it possible to optimize page performance from the protocol.
At the same time, the necessity of front-end static resource packaging has become the focus of debate to some extent. As a traditional front-end performance optimization scheme, packaging and merger has a great impact on front-end engineering, and the superiority of Facebook’s famous static resource dynamic packaging scheme will be weakened. There have been several articles in the community about performance experiments with HTTP/2, but they are not the same.
In 2017, I believe that all large sites will switch to HTTP/2, but still remain dependent on static resource packaging and consolidation. Also, there won’t be much use for advanced features like Server Push.
1.2 Internet Explorer 8
The front-end technology community, which only three years ago was considering compatibility with IE6, has been stirred up by the recent announcement that Tmall will no longer support IE8. Internet Explorer 8 is the highest version of Internet Explorer supported by the Windows XP operating system, and abandoning IT means abandoning all XP users using Internet Explorer.
Angular abandoned IE8 in version 1.3 and React abandoned IT in v15 earlier this year. In the PC world, you can still support IE with other frameworks like backbone. js, but it’s better to abandon it for both development efficiency and runtime efficiency.
Due to poor HTML5 compatibility, IE9 will also be gradually abandoned by the community in 2017 for better performance and less code size.
How to write (Java)Script
2.1 ES2016? ES2017? Babel!
ES2015 (also known as ES6), finalized last year, brought a number of exciting new language features that were quickly implemented by V8 and SpiderMonkey. However, due to fragmentation of browser versions, ES5 is still the main source of production code. The mid-year release of ES2017 brought a pitifully small number of new features, but it gave browser vendors time to digest the year and take a breather before IT arrives — and yes, next year’s RELEASE is bound to bring a whole new wave of features.
JS explains that the engine’s ability to support new features does not deter avid developers from using them, and that the industry’s reliance on Babel is bound to grow in the long run. The Babel ecosystem will have a greater impact on the next generation of ECMAScript, with people adding new Babel-plugins and then submitting proposals to ECMA becoming the norm of ECMAScript evolution. Developers will write less and less code that runs directly in the browser.
However, the increased volume of compiled code resulting from using Babel has not been a particular concern, as polyfill can be introduced repeatedly, resulting in a significant amount of redundancy in code deployed to production.
2.2 TypeScript
As a superset of ECMAScript languages, TypeScript has had great success this year, with Angular 2 becoming TypeScript’s biggest customer by abandoning the fabled AtScript. People can write JavaScript just like Java, effectively improving the expressiveness and type safety of the code.
But as TypeScript features continue to evolve, in a production environment you may need a set of specifications to discipline developers and prevent incompatibilities caused by abuse, which increases learning costs, application complexity, and upgrade security. Among the advantages and disadvantages, still need a lot of engineering practice to accumulate experience.
In addition, TypeScript can also be thought of as a translator, with new feature support similar to Babel. In 2017, we can look forward to seeing how TypeScript and Babel will evolve into a delicate relationship.
2.3 Promise, Generator and async/await
On the callback hell issue, we’ve been bombarded with new solutions for the last two years. In the past async was used to simplify the design of asynchronous flows, until the “primary” Promise arrived. But they are just syntactic sugar for the callback pattern and do not eliminate the use of callback entirely.
The introduction of Generator/Yield in ES2015 seems to be a magic weapon for asynchronous programming, even though it was not designed for asynchronous programming. However, Generaor is tedious to run, so another tool, CO, becomes a must for using generator. The Node.js community’s Koa framework was originally designed to write onion-skin control flows using generators.
But in a flash, the async/await syntax, and the way to write asynchronous code with Promise, immediately swept the whole front-end community. Although async/await is still in ES2017 draft, today, not writing async/await immediately looks like your design is far behind the average of the community.
On Node.js, V7 already supports direct interpretation of async/await in Harmony arguments, and will be officially supported in V8 next April, when Koa 2 will be released, almost entirely without generators.
2.4 the fetch
Due to callback problems, traditional XMLHttpRequest is likely to be replaced by the FETCH API. Nowadays, mature polyfills such as WHATWG-Fetch, Node-fetch and Isomorphic-fetch have a large number of daily downloads on NPM. Even for mobile devices with poor compatibility, developers are reluctant to use complicated AJAX. With the async/await syntax, using the FETCH API makes code much cleaner.
Node.js services and tools
Koa 2
Koa and the popular Express are in a “homogeneous” relationship, built by the same team. The new Koa framework is lighter and more flexible than Express. However, Koa’s design has undergone major changes in a short period of time due to the influence of async/await syntax on asynchronous programming. In version V2, Koa’s Middleware abandoned generator in favor of Async, and all third party middleware implementations either upgraded themselves or wrapped transformations using KOA-convert.
Koa is currently getting a lot of attention in the Node.js community’s HTTP server framework, but its latest release on NPM is currently in phase 1.x and is expected to be upgraded to 2.x after the release of Node.js V8 in April 2017.
Koa’s lightweight design means that you need a lot of third-party middleware to implement a full Web application, and there are few large-scale heavy uses of Koa that can be evaluated. Over the next year, more and more products should try to deploy Koa 2. By then, the conflict of dependence on third party resources will be sharp. It will take a while for the Koa ecosystem to complete. We expect to have a robust enough Koa stack in 2018. This will allow Node.js to expand on the server side, and lightweight Web services will gradually become mainstream in the market.
Framework disputes
4.1 Is jQuery Dead?
JQuery 3.0 was released in June, more than three years after the 2.0 release, but there have been few major updates. As older browsers are abandoned and upgraded, jQuery has to deal with fewer browser compatibility issues and more focus on API ease of use and efficiency.
With the proliferation of frameworks such as Angular, React, Ember, and Vue. Js that can bind view data in either direction, there are fewer and fewer people using jQuery to write directive code to manipulate the DOM. Back in 2015, some people claimed that jQuery was dead, and there was a lot of similar discussion in the community. Today, we see that jQuery is not as important as it used to be. The famous Sizzle selector is now fully replaced by the querySelector native method. Manipulating the DOM can also be done automatically by the framework based on changes in the data.
JQuery’s reliance on building large front-end products will continue to diminish over the next year, but its understanding and accumulation of browser features will continue to be useful for existing and future Angular like MVVM frameworks.
4.2 presents 2
Later this year, the official Angular 2 release was released. Compared to 1.x, the new version is almost a complete redesign of the framework. A steep learning curve follows. NPM, ES2015 Modules, Decorator, TypeScript, Zone.js, RxJS, JIT/AOT, and E2E Test are all the latest concepts in the industry in the last two years, which can be quite difficult for beginners.
Angular 2 is also more geared toward developing single-page apps (SPAs) as a natural consequence of bundling Modules described by ES2015 Modules syntax, so Angular 2 relies more on “Bundler” tools like Webpack.
Angular claims support for TypeScript, ECMAScript, and Dart, but Dart is clearly not much of an industry interest, whereas ECMAScript and TypeScript, Angular 2 in both language modes has implicit (poorly documented) differences in apis and build processes that are bound to confuse developers. With limited support for third-party tools and components in the industry, TypeScript is pretty much the only option for developers right now.
In addition, the Angular team has stated that it hasn’t completely dropped support for 1.x components. With a proprietary compatibility API, you can use components developed for 1.x in 2.x. Few teams are willing to do this, given the unclear risks.
Using Angular 2 in production now, architecturally you need to consider two completely different build modes in production and development, namely JIT and AOT, which require two different compilation processes and configuration files. Automated testing can be done using E2E, SPEC, etc., to see if modules meet expectations in different environments. Well, Angular 2’s testing API can be a technical barrier, which can be even more complex than Angular itself. You can be sure that business pressures will force most teams to give up writing tests.
All in all, Angular 2 is a very competitive framework with a very forward-looking design, but it is so complex that many features are ignored by developers. Due to the React/Vue. Js competition, Angular 2 will certainly have less impact on the community than its predecessor 1.x, and more advanced features such as Server Render have not been engineered yet, so the industry will probably have to wait until the next 4.x release.
4.3 the Vue. Js 2.0
Vue. Js is definitely a dark horse in the MVVM framework, created by the author alone, what is more valuable is that the author is Chinese. The influence of Vue.js in the community has been enormous, especially since the release of 2.0, and the community has rapidly produced numerous solutions based on vue.js, mainly due to its simple API interface and friendly documentation. It can be seen that as a provider, the simplicity of the product is particularly important. In terms of performance, Vue. Js, based on ES5 setters, offers a performance improvement of multiple times over Angular 1.x dirty checking. And 2.0 is a step further in modularity, easier to develop and better to maintain. Vue.js hits a sore spot with the average Web developer. Domestically, Vue.js has teamed up with Weex to see what it can bring to the community.
4.4 the React
React still seems to be the most popular data view layer solution of the year, and has become a standard skill for almost every front-end engineer. React didn’t explode much this year, except for the jump from 0.14 to 15 and the abandonment of IE8. People are used to writing Web applications using JSX syntax, just as they have been writing jQuery for the past decade.
React code on the maintenance performance is obvious, if the JSX write properly, also has the advantage on heavy rendering performance, but if only deployment in the browser environment, so the first screen will adversely affect performance, after all, at present, pure front rendering but still quick back-end rendering, and back-end natural chunked segmented output advantage. We can see some negative cases in the industry. For example, a news application used React to rewrite all cases, which was a misuse of React, regardless of its scenario disadvantages.
Alternatives and companion tools built around React are still alive and well, with Preact touting its fully compatible API and compact size, Inferno touting faster speeds, and so on. Each framework wants to innovate on the Virtual DOM, but their improvements are not revolutionary. Developers are reluctant to take the risk of third-party plugin incompatibility. I think their greatest significance is to provide alternative ideas for the internal implementation of React. Just as in nature, where biodiversity is essential, hybridization offers valuable evolutionary advantages.
4.5 the React – Native
This year is the first year that React-Native (RN for short) supports dual-end development. A number of teams have shared their practical achievements on RN, and it seems that the future is promising. RN has effectively solved the problems of traditional client limited by release cycle and H5 limited by performance, and achieved the ideal goal of having both the best and the best.
But we still need to question:
First, RN currently releases new versions on a fortnightly basis, with no LTS, and each version is not compatible forward. That is, if you’re writing bundle code in 0.39.0 and want to run on 0.35.0 Runtime, it’s almost 100% wrong. In this case, how to set an upgrade policy for RN on the client? If upgraded, how does the business code for more than one Runtime version? If not, then that means you need to maintain an LTS yourself. Every current RN release has a bug fix for the previous release. I believe no team has the energy to synchronize these on an old release. If not, the business side will be faced with a buggy runtime, and its development psychological pressure can be expected.
Second, while RN claims to support both Android and iOS, there are a lot of system differences in practice. Some are in RN documents, some are in issues, including other issues, and the nearly 700 issues on RN on GitHub are daunting enough. If you don’t efficiently deal with all the crazy things that come up during development, your schedule is at serious risk. RN also performs differently on Android and iOS, and worse on Android, where you have to work on performance optimizations even after you’ve done the whole business. And no matter how optimized, the single-threaded model requires both smooth transitions and a set of data manipulations that require a high degree of skill to ensure decent performance. In practice, for H5, due to time constraints, a decent version of the business will be introduced first, and performance optimization will be initiated later. For RN, however, achieving the “passable” criteria is likely to require considerable refactoring.
Thirdly, Although RN uses Native rendering elements, it still runs on JavaScript Core kernel and is still single-threaded. Compared with H5, this does not have a revolutionary improvement in performance. Animated animations and large ListView scrolling are all familiar performance bottlenecks. To address performance and compatibility issues with complex components, teams are taking the initiative to build their own Native high-performance components. Because it relies heavily on a particular client environment, and because it still relies on client release and development, it defeats RN’s most important purpose. It can be imagined that RN degenerates into H5+Hybrid mode after a large number of Native components are frequently referenced, and the high-performance advantages of ITS UI will be weakened with the continuous upgrading of device performance. Meanwhile, its non-stable version will bring more unpredictable risk variables to development.
Finally, RN remains difficult to debug and test. Especially if you rely on a particular component on the end, native automated testing becomes almost impossible, and most clients do not support automated testing at all. However, debugging can only use the limited capabilities of remote Debugger, which is very inconvenient in performance analysis.
It can be said that the emergence of RN has brought a unique new perspective to mobile development, making it possible to use JavaScript to develop Native, and similar solutions such as NativeScript and Weex have also been developed. Obviously, the biggest problem of RN is still immature and stable. There are still many risks in using RN to replace Native, which may not be particularly suitable for heavyweight and long-term maintenance client products, such as Facebook itself. The advantages of RN are obvious, but its problems are also serious. Decision makers need to understand the pros and cons of each aspect. After all, the cost of such trial and error is not small.
Due to time constraints, no product on the market has long enough practical experience in the application of RN, and most of them still belong to the stage of “we have deployed RN to the client”. We cannot predict the long-term performance of this technology, and it is still too early to evaluate the final value of RN. In 2017, WE expect RN team to make greater progress, but do not be too optimistic. In view of the current situation, it is still quite difficult to achieve stable state.
4.6 with Mobx Redux
Redux has successfully become one of the most important members of the React technology stack. Like Vue.js, Redux stands out by having an API that is easier to understand than other Flux frameworks. However, some people soon began to get tired of the tedious process of defining actions, reducer, store, and a bunch of functional calls every time they wrote an application.
Mobx is also based on ES5 setters, which allow developers to trigger view refreshes without actively calling action functions, requiring only a store object and several decorators to complete the configuration, which is much simpler than Redux.
No matter what framework is used for data to view synchronization, one of the most important issues for developers to worry about is how to ensure that views are refreshed at a minimum but at a reasonable rate to save extremely sensitive performance costs in the face of numerous data changes. This can happen with Redux or Mobx, but Mobx in particular. In order to improve the performance of the view, you still need to introduce advanced concepts such as Action and Transaction. In an architecture where control flow and view are separated, this is an inevitable concern for developers, whereas with Angular, vue.js, frameworks do a lot of things for you, and developers have less to worry about.
4.7 the Bootstrap
Bootstrap 4 has been in alpha for a long time, and even now that 3.x has stopped maintenance, it seems to have been affected by the sluggish business of Twitter, and there are still a lot of issues on GitHub. Bootstrap is the best CSS framework for building internal platforms, especially for backend engineers who don’t know much about the front end. It’s not clear how much longer Bootstrap will last, and if Twitter has to abandon it, its best bet may be to hand it over to the third-party open source community to maintain
5. Engineering and architecture
5.1 Rollup with Webpack 2
Rollup is another packaging tool that has been around for the last year. Its biggest selling points are the ability to package Modules directly for ES2015 Modules and the introduction of tree-shaking algorithms. With the introduction of Babel-Loader, Webpack can also package ES2015 Modules, so Rollup is only really tree-shaking, a technique that removes redundancy and reduces code size. By analyzing the AST (abstract syntax tree), Rollup can find code that will not be used and remove it.
Tree-shaking is not just for Rollup anymore, Webpack 2 will support it, and ES6 Modules will be supported natively-too. This is a typical case of left-leaning contributions to the mainstream.
Webpack was the hot packaging tool of last year and seems to be the latest build tool to replace Grunt /gulp, but obviously not. I’ve always felt that Webpack, as a Module Bundler, does too many things that aren’t relevant to it to make it look like an engineering build tool on the surface. Classic builds require the concept of tasks and then control the order in which they are executed, which is exactly what Ant, Grunt, and Gulp do. Not so with Webpack, the most important concept is entry, one or more, which must be a disk file written in a javascript-like language, and all other things like CSS and HTML are handled around entry. It’s hard to see how Webpack has “built” the current project at a glance from the configuration file, but no one in the community seems to have raised any objections and everything is working fine.
Off-topic: How do you build a project without any JavaScript code using Webpack?
The new Angular 2 builds much better with Webpack 2. However, Webpack 2 has been in beta for a year and is now rc and will be released soon.
5.2 NPM, JSPM, Bower, and Yarn
NPM is still king among module managers, but to be clear, NPM stands for Node Package Mamager. NPM is used to manage modules running on Node, but now hosts a large number of modules that only run in the browser. There are several reasons for this phenomenon:
-
The heavy use of Webpack makes the front end usable and accustomed to commonJS-type modules;
-
Bower has never been, and never will be, a more suitable alternative.
The modular specification of the front end has always been in the warring states era. CommonJS is fine on Node. On browsers, while there are ES2015 Modules, there is a lack of module loaders, possibly SystemJS in the future, but it is still in draft form. Either way, it’s still at the JavaScript level, and the full front end modularity includes CSS and HTML, as well as some binary resources. At present, the closest solution is JSX+CSS in JS mode, which is popular in Webpack environment. This phenomenon has even influenced the design of frameworks such as Angular 2 and Ember 2. From this point of view, the JSPM is just a shell with no advantages at all.
NPM has its own problems, which in practice always affect efficiency, security, and consistency. Facebook has made a bold move to release Yarn, an alternative upgrade to NPM, which supports offline mode, strict dependency version management, and other features that are very useful in engineering.
As far as front-end modularity is concerned, JavaScript has CommonJS and ES2015 Modules, but components in engineering, which may need to be developed repeatedly in different framework environments, are still incompatible. In the future, WebComponents may be a better solution.
5.3 isomorphism
Isomorphism has been around for a long time in the software industry, but it wasn’t until the advent of Node.js and React in particular that it became possible on the Web front, because the React kernel didn’t rely on the browser DOM environment to run.
React isomorphism is a low-cost solution. As long as you pay attention to the execution environment of the code, the front and back ends can indeed share a large part of the code, which effectively overcomes the bottleneck in first-screen performance of front-end rendered pages like SPA. This is a common problem with all view-capable frameworks like Angular, Vue. Js, React, etc., and now they all support Server Render to some extent.
We can think of several problems facing the isomorphism of the front and back ends:
-
How to import static resources, CSS in JS mode needs to consider the compatibility of Node.js;
-
How the data interface fetch, AJAX on the browser, what it is on Node.js;
-
How to implement route isomorphism, the browser does not refresh the switching page, and the new route is available on the server;
-
How to avoid blocking node.js execution with a large DOM rendering.
At present, star has many homogeneous frameworks on GitHub, including Nuxt of vue. js and next. Js of React, as well as METEOR with all-package data storage. To be sure, whether or not they can be deployed in a production environment, they will not meet all your needs, a proper re-architecture is necessary, and there is not much to learn from this new area.
Sixth, future technology and vocational training
6.1 Big data Direction
More and more companies in the toB business are looking to the front end for data visualization or, more generally, reporting. This is an area that front-end engineers used to look down their noses at as boring and untechnical. But in the age of mobile, and especially big data, the demand for such skills is increasing and the value of technology continues to rise. With the principle of “salary-oriented programming,” a lot of engineers are bound to jump in.
The technical skills required for this direction are Canvas and WebGL, but most of the requirements don’t require you to deal directly with the underlying API. There are plenty of third-party tools that can do this for you, and some of them are excellent frameworks. Such as Baidu’s ECharts, foreign chart.js, Highcharts, d3.js and so on, especially D3.js, are almost magic tools in the direction of big data front-end, which is worth learning.
Again, as engineers, suffering consciousness, must not to meet with these a few tools in the actual business scenarios, more need your extension framework, produce their own components, it requires you to have a certain knowledge of mathematics, graphics and OpenGL layer, can saying is very large technical barriers and entry barriers.
6.2 WebVR
This year can be said to be the explosive year of VR technology, a number of VR game devices were launched in the market, and Taobao is the development of the civilian buy+ shopping experience, and so on popularized, can almost overturn the traditional online shopping way.
The development of VR cannot be separated from the construction of 3D environment. WebVR standard is still in the draft stage, a-frame can be used for experience, and another three.js framework is A relatively mature tool for constructing 3D scenes, which can play A big role in future VR applications. It is also essential to build a rich 3D interactive mobile page, and Taobao is a pioneer in this respect in China.
6.3 WebAssembly
Asm.js has evolved into WebAssembly and is being pushed by Google, Microsoft, Apple, and Mozilla, which seems very welcome given that the major browser kernel vendors are here. One of the problems with collaboration is inefficiency. This year we finally got a demo that allows you to write C++ code to run in a browser, which requires you to download a bunch of dependent libraries and a very time-consuming build, but it’s an improvement.
We’re unlikely to change the status quo of writing front-end code in JavaScript any time soon. Dart failed and we can only hope for future WebAssembly. With it, the front end will be much more efficient and secure at runtime, and all the other issues that come with it will have to wait until that day.
6.4 WebComponents
What can WebComponents do for us? HTML Template, Shadow DOM, Custom Element, and HTML Import? Yes, a perfectly componentized system. Component-based systems like Angular and React combine HTML with Custom elements, but this is an illusion; they will eventually be compiled into JavaScript and executed. But WebComponents is different. Custom Elements can be parsed by browsers natively. DOM Element methods can be customized. This is what componentization is supposed to look like, with the external only caring about the interface and not caring about or manipulating the internal implementation.
Current componentization is dependent on a particular framework, be it Angular or React. Porting requires a complete reboot, which means they are incompatible. With WebComponents, a common standard that browser vendors follow and support, this status quo is likely to change.
The future of front-end componentized distribution will not be as simple as NPM, probably just a reference to an HTML file, more likely a directory containing CSS, HTML, JavaScript, and other binary resources.
Only the latest Chrome fully supports all of WebComponents’ features, so it will be some time before it can be used. Due to technical limitations, the ability of WebComponents polyfill is very limited. Shadow DOM is impossible to be implemented, while the other three need to be compiled offline. You can refer to the implementation of Vue.js 2, which is very similar to WebComponents.
6.5 About wechat applets
Micro channel small program for this year have to say, but I have nothing to say. Relying on the large number of users, wechat has officially produced its own set of development technology stack, which can only be said to fill a role for complex front-end development – wechat front-end engineer.
Seven,
There are a few final points to note.
7.1 engineering
First of all, there’s a lot of talk about front-end engineering, people learning to build, people packaging. In my opinion, the key point of engineering lies in “balancing the advantages and disadvantages of various schemes and maximizing the weighted benefits of each index”. Just adding project construction is far from enough. In practice, we often need to consider two directions: one is r&d efficiency, which should directly respond to business needs; The second is runtime performance, which directly affects the user experience and is also the concern of product managers. Both have a direct impact on the company’s revenue and performance.
Specific questions, such as:
-
If static resources are organized and packaged, how can they be packaged to minimize the number of code downloads (performance) for a product with many pages, given the constant iteration of updates? Don’t say use Webpack to pack into a package, or compile Common Chunk and you’ll be all right, do you need to constantly tweak the build script (efficiency)? What if I change it wrong? Is there a test plan?
-
How to ensure the performance of the first screen when building pure front-end rendering pages with Angular, especially React? Introduce server isomorphic rendering, okay, so who writes the server? It must be written by the front-end engineer, so what is the data layer architecture of the server side? From the perspective of operation and maintenance, how does the front end ensure the stability (efficiency) of the service?
-
How is the componentization scheme developed (efficiently)? How to ensure easy distribution and reference of components? How to ensure plug-and-play (performance) of components on the user side?
For engineers, it is necessary to first quantify the weight of each indicator, and then calculate the weight value one by one for alternative schemes, and take the maximum value, which is the scientific method of technology selection.
However, in the industry, we rarely see more in-depth sharing and discussion on engineering. Most of them stay in the stage of “which framework is good” and “using XXX to achieve XXX”, often focusing on the advantages and disadvantages of a specific direction, and seldom have a scientific overall view. They even see the advantages of a particular solution, but ignore its disadvantages and sustainability. The causes of this situation are various, it is technically, engineers ability to reason and does not take into account, the second is politically, engineers need to quickly achieve a certain goal, in order to obtain the visible KPI, complete the team performance target, but more likely is that the vast majority of domestic product complexity is not high enough, There is no need to consider the impact of long-term sustainability and large-scale teamwork on technical solutions.
Therefore, you have to accept that whether you use CSS preprocessors, Webpack or Grunt, React or Angular, RN or Hybrid, is most likely not that sensitive or important to the product, and is often more dependent on the personal preferences of decision makers.
7.2 Role Positioning
Indeed, in the last two years, Web front-end engineers have become less honest, either with Node.js on the server side or RN on the client side. What about these behaviors?
In my opinion, it is ok to get involved in server side development, because it only involves the rendering level, and it belongs to the “front end” category. Moreover, in actual engineering practice, it has been proved that a good front-end development system really needs the participation of the server side. Think of Facebook’s BigPipe. However, this requires a well-layered architecture on the server side, where the data and rendering are completely decoupled and the back-end engineer is only responsible for CRUD of the business data and provides the interface from which the front-end engineer retrieves the data and pushes it to the browser. Data decoupling is superior to interface decoupling. So now that Node.js is mature as a Web service, there is no problem with the front-end taking care of server-side rendering as long as your server architecture allows.
Front-end involvement in client development is also reasonable, after all, are running on the client side, also belongs to the category of the front-end. Apart from Weex of Alibaba, NativeScript and RN are lack of large-scale and continuous use precedent, which is different from setting foot in the server field. The solutions on the client side are not mature enough, and the limitation of tools hinders the transition from the front end to the client side, which still needs the test of time. However, there may not be much time. Future Web technologies, relying on high-performance hardware and popular WebGL, WebRTC, Payment API and other capabilities, will challenge the status of Native in terms of performance and function. At worst, you can build on Hybrid and take advantage of Native’s ability to properly expand, which is cooperative rather than competitive.
In short, the front-end engineer’s roots are still in the browser, and at this point, the scope is broad enough that no one can claim to have truly “mastered” the front end. Branching out into other areas is also encouraged if conditions permit, especially after the technology matures.
7.3 Write at the end
The front end is bound to be one of the more demanding development roles. At the end of each year, we see an almost entirely different world, the result of the intense thinking and passion of countless people at the front. Whether the final product is popular or not, it is driving the rapid upgrading of the front-end technology field. It confirms that “only change is constant”. As business line r&d engineers, our responsibility is to select the best combination of solutions to maximize the company’s benefits. The scope of this “best” is very wide, depending on the breadth of the designer’s technical vision, as well as the management experience of the decision maker. It is never easy.
The future Web front-end development experience must be richer. Relying on the standardized component system of WebComponents, the high-performance runtime code based on WebAssembly, and the high-speed resource loading backed by HTTP/2 protocol, front-end engineers do not have to disperse too much energy in performance and compatibility. So that we can focus on developing the next generation of Web apps with rich interactive experiences, be it VR or games.
As we head into 2017, we need to be prepared for new concepts, new frameworks and tools, and new grammars to be produced, and the imperfect status quo to continue.
Because the level is limited, the author is unavoidably biased in the above content, please bear with me.
At the top of the front end
Top of the Front Is InfoQ’s vertical community focused on front-end technology. Welcome to join us! Add group please pay attention to the “top of the front” public account and send “Add group”, please send email to [email protected], marked “top of the front contribute”.
Broaden our
Each encounter is a reunion after a long separation. After a year, QCon Beijing station returned magnificently. 20+ hot topics were presented, covering blockchain, VR, TensorFlow, deep learning and other trend technologies, as well as first-hand practices in front-end engineering, R&D security, mobile special, intelligent operation and maintenance, business architecture and so on. Domestic and foreign technical experts participate in the event, register now, enjoy a 30% discount.
At present, with the rapid development of front-end technology, we have a large number of technical solutions, but at the same time, the complexity of business and the size of the team is increasing, and the engineering difficulty is constantly increasing. How can front-end engineering be systematically built and maintained using existing technologies and platforms?
Did this article help you? Welcome to join the front End learning Group wechat group:
