We asked six experts about the status quo of web development. What is the current JavaScript scene? Which trends are important? Which challenges need to be mastered?

Let’s take a closer look at the scene of the JavaScript Frameworks. We also look at techniques of using CSS and Sass and clarify the benefits of approaches such as OOCSS, SMACSS and BEM.

JAXenter: Let’s take a look at the scene of the JavaScript frameworks: React, Angular and Vue.js are currently set here. Nils, what are the latest developments at React? Right now we’re at version 16 – how’s React 17 going?

Nils Hartmann: The versioning of React is relatively conservative, and there are rarely releases that are reflected in the increase of the major version. React 16 is now almost a year old, but versions 16.3 and 16.4 have been released during the year, which contain some interesting new features. For example, a now officially supported context API was introduced at 16.3, and support for PointerEvents was added in React 16.4. All in all, it can be said that React moves steadily, but not in a hurry. This is also because new features should have enough stability before being included in a release. In addition, much emphasis is placed on backward compatibility.

However, there are currently two major new features that could be released in a release 17 later this year (React developers are usually very cautious about announcing specific release numbers and appearance data). Both features pay for an improved user experience. On the one hand, it is about being able to interrupt “unimportant” updates of the UI and to prefer “more important” updates (“time slicing”). For example, with limited CPU resources, it can be prevented that the application “jerks” when displaying a text in an input field, for example, because components have to be updated elsewhere. In this case, React would prioritize the input or presentation of the input higher and make other updates in the back.

The second feature, Suspense, allows the rendering of components within a hierarchy to be paused until the data required for rendering is loaded (asynchronously). Once the data is loaded, React automatically resumes rendering from the interrupted point. This makes it very easy, for example, users of the application a Loading Indicator or similar. display. In my opinion, this could simplify a topic that is particularly difficult for React newcomers, working with asynchronous data access.

JAXenter: Golo, what highlights are you looking forward to in React?

Golo Roden: One of the big issues is asynchronous rendering . So far, a rendering process blocks the entire UI, which you can feel in complex changes, because the UI only lazy or no longer responds. Asynchronous rendering is no longer blocking, which means that the UI remains responsive even when, for example, a large component needs to be redrawn.

So the feature is very interesting, especially in terms of the UI’s performance, but it sometimes requires new APIs and therefore some changes that are no longer backwards compatible. For example, some functions are eliminated from the life cycle of components, as it will be structured differently in the future.

It is noteworthy, however, that the developers of React – as in any previous version – ensure that the break does not happen suddenly from one day to the next. Instead, features that are no longer needed are marked as obsolete, leaving application developers ample time to customize their code.

Personally, I find that a very sympathetic approach, because you are not just faced with fait accompli, but gradually adapt to the changes and adapt them.

JAXenter: Tobias, what’s the exciting thing about React for you?

Tobias Struckmeier: Especially exciting is the Context API, which is coming out soon, so it’s not final yet. The context that I already have in the React application, I can further unify with this API. This removes the pain that I had with the context so far. This will also help Redux to better bond to the React components.

JAXenter: A JavaScript framework that is currently receiving tremendous popularity is Vue.js. What are the differences to React?

Tobias Struckmeier: Many concepts known from React can also be found in Vue.js. A big difference is working with templates. While working on React with JSX, you can also use templates in Vue to separate its HTML from its code. So you already know it from Angular and other template languages. I personally see the advantage of JSX that I have my code and my template in the same place together. Of course, that’s a matter of taste, but Vue is actually a bit more flexible. There is also the possibility for Vue to work with JSX. Then it looks very much like React. So I would say that a developer who gets on with React also gets in quickly in Vue.

JAXenter: Karsten – you’re an Angular expert: Where is the development of Angular now? What innovations are in progress?

Karsten Sitterberg: Recently Angular Version 6.1 – and thus probably the last 6-series Minor version – was released. For example, this release adds support for the latest TypeScript version 2.9. Also the official Shadow Dom v.1 specification is now implemented. The most important innovation at Angular, which will be released with the next major version, is certainly the new Ivy Renderer. The Ivy Renderer completely changes the way Angular interacts with the browser. This will be reflected in better tree-shaking features, which will then produce smaller and faster apps. These enhancements will also enhance the properties of the Angular Elements – the Angular Web Components – of the Ivy Renderer, making them independent of external Angular applications.

JAXenter: Yara, your hobby is CSS. Unfortunately, CSS is often not taken so seriously. This can be seen, for example, in the fact that CSS is sometimes still written to the end of a current file. What kinds of bad habits have you encountered in your practice with CSS?

Yara Mayer: What I see most often is:

The main reasons for this are lack of time, communication and / or lack of knowledge or experience.

JAXenter: Jens, you plead for creating CSS modular. Is not it enough to see CSS as a central, monolithic artifact that gives the modules of a website a consistent look and feel?

Jens Grochtdreis: Can you do it. That is certainly enough for many small projects and individual fighting colleagues. But I always assume that as a self-employed person and above all as an agency, you have many different projects, often with the same or similar modules. So by isolating these modules and creating their own “bootstrap”, you have saved a lot of work and, above all, a lot of testing effort.

You can then use them again and again in a new compilation. In addition, working in a team is easier, because each developer is only responsible for his module. Therefore, it is in the self-interest to create the CSS in individual bits (modules) and take from project to project when they are needed. Preprocessors like Sass are very helpful, but not necessary.

JAXenter: À propos Sass. The criticism of Sass as a metalanguage for CSS is often that the use of a preprocessor makes the development process more difficult. Are such objections justified?

Jens Grochtdreis: Since you can program with Sass to a certain extent, developers are always in danger of putting too much energy into the “simplification” of the development process. Especially at the beginning of my occupation with Sass, I often made this mistake myself. Everything had to be in a Mixin, which also had ten parameters. That was not manageable. But the creation was fun. But that was not the aim of the exercise.

I know a project in which I definitely do not understand the structure of the Sass files. Among other things, they work with JSON and outsource a lot to Mixins, which sometimes find only one use, but are used to get a simple reference to breakpoints. Such Sass projects are not easy to understand at the end of lateral entrants and only take a lot of time. I have the impression that it makes less work easier than stroking one’s own ego.

In this form, I find Sass only partially helpful. But despite everything, I do not want to give up Sass anymore. Two years ago I created a small application – an advent calendar – without Sass. It felt wrong and awkward.

Yara Mayer: I’d rather say that it does not hurt, unless for some reason you do not have the option of using a preprocessor. That being said, there are a few reasons why it actually makes sense: mixins (with parameters), functions, autoprefixing …

JAXenter: Currently, approaches such as OOCSS, SMACSS and BEM are discussed. When are these useful?

Jens Grochtdreis: OOCSS is more of a basic sketch on how to approach a comprehensive CSS and how to mark modules in HTML. It has never been extensively formulated, but inspired all other approaches. I find SMACSS and BEM more interesting.

In terms of content, I have always found SMACSS class, especially because its “inventor” Jonathan Snook has understood his rules not as absolute laws but as rough orientations. BEM, in turn, has the advantage of being a strict, logical, stringent system optimized for large and very large projects. It is now a kind of industry standard, which is understood and followed by many developers. This makes it easier to understand a project that you can get into.

Yara Mayer: A few rough concepts from these approaches are, in my opinion, always important. The rest depends on what kind of project you are developing. If it should contain themes, then something like OOCSS or SMACSS. But there are also other solutions that are made possible by a preprocessor or CSS variables. Much more important to me is that you use the same strategy from start to finish.

JAXenter: Thank you for your statements!

Source: jaxenter.de

Share This:

The post JavaScript Expert Check: Recent Developments at React, Angular, Vue.js appeared first on FrontNet Blog.