The application development world is continuously changing, evidenced by the analyst community’s frequent revisions of their various categories, definitions and scope of application development tools and platforms.

The state of industry flux is fuelled by organisations clamouring for a single platform and tool set that can help them quickly deliver omni-channel, customer-grade apps spanning desktop, web, mobile, wearables and chatbots.

The right low-code solution based on open standards can be invaluable in an era of ‘more apps, faster, that run anywhere’. That said, not all low-code solutions are created equal. Here are three red flags to watch for when evaluating a solution.

1. Black Boxes

Low-code gets a bad rap due to an ‘impenetrable black box’ perception, which is understandable considering developer reluctance to run mission-critical services on something over which they have no control.

The answer to increased productivity in a fast-paced environment shouldn’t be the extreme of no-code black boxes, but a low-code solution that’s an ‘open box’ – based on open standards and with a full view of the source. Low-code at its core is merely a tool whose value is derived from those who use it – and that calls for a professional developer, not a no-code business user.

Low-code for pro developers is about writing once and running across platforms, while maintaining full control over the user experience.

2. Monolithic Architectures

App development was already complex. Today’s expectations include limitless scalability across multiple channels, compounded by a rapid shift to cloud-based development using containers and microservices. Development teams need to meet those expectations while maintaining focus on the user experience.

Developers are skeptical of low-code solution architectures, viewing them as antiquated, monolithic, and unfriendly to application deployment. Some of the reasons for this are:

• Monolithic low-code architectures can be easy to develop and deploy initially, but in the long run tend to be ‘tightly coupled’, making them difficult to scale and maintain. If any program component needs to be updated, this often requires large portions of the application to be rewritten
• Monolithic low-code architectures can be difficult to understand because they frequently have dependencies that aren’t apparent because they’re baked into the solution. With many low-code solutions, you’re saddled with trying to manage the development, testing and production work for a monolith, minus the ability to develop, test, deploy and scale components individually.

3. Proprietary Toolsets

A plus of having proprietary tools bundled into a low-code solution is alignment of the tools and hopefully the platform, since they come from the same vending source. In theory, this should benefit developers and ultimately the business.

However, the realities of proprietary tools include steep learning curves, vendor lock-in and an ecosystem of code samples, tutorials and communities applicable only to that vendor – all of which could be spotty or non-existent.

In some cases, a platform vendor promotes their use of standard languages but still locks it within proprietary development process.

Besides the expense and time involved in learning and integrating niche skills, seasoned developers will likely resist transition to a vendor’s proprietary tools. It separates them from mainstream development communities and isn’t impressive on a resumé.

In addition, proprietary code can be tough to debug with fewer resources available to find examples and address issues.

With a view now focused by the inflexibility and risk, it’s clear why professional developers are reluctant to recommend proprietary tools.

What’s an ideal solution?

The ideal would be to have the cloud capabilities provided by the likes of AWS or Azure at your disposal, combined with the ease of low-code deployment.

Developing on a serverless cloud-based platform allows the platform to manage and auto-scale the microservices and functions. If you combine this with a Node.js backend and a JavaScript-based frontend for web and mobile, you have a full-stack option. The benefits are manifold:

• Combining a serverless and low-code platform built on JavaScript allows organisations to meet demand for consumer-grade omni-channel experiences using existing developer skills
• Different developers or even different teams can work on their portion of the application independently without conflicting with changes made by other teams
• Updates can be made without rewriting or redeploying the app code
• Code is reusable across apps and easier to maintain as functionality is isolated.

The result is developers are freed to focus on app capabilities and user experience, while the platform manages the rest.

The key is having a low-code platform based upon a widely-used and standardised language that has a strong ecosystem of tools, libraries and learning material. I believe that language is JavaScript.

JavaScript offers the ability to use a common language on both the front and backend of an application, and it has the added benefit of enabling frontend developers who are already familiar with its capabilities.

And for organisations moving to full stack development, they can use a full stack approach leveraging JavaScript for both front and backend development.

Mark Troester, VP of Strategy, Progress 

The post When developers shouldn’t trust low-code solutions appeared first on DevOps Online North America.

One of the hardest things about being a front-end developer comes from the fact that everybody has very different expectations of what it means to be one. This, along with a technology stack that changes at the speed of light, makes interviewing for a front-end position tricky.

To help you out, and to give an idea as to Zalando’s views are on the role in question, we have prepared some points on what we consider essential knowledge for a frontend developer.

The ability to solve problems

This sounds quite abstract, so let’s talk about what it means. Unlike many other developer positions, a front-end developer wields the power of multiple languages and technologies. Being able to look at a task, split it up into necessary steps, and choose the right technologies for the job is an essential skill—some things need just a line of CSS, but implementing them in JavaScript would require a 100k library and vice versa.

Sometimes you won’t know the perfect tool for the situation at hand, and this is also fine. However, you are still expected to provide a solution. This solution may not be the nicest in terms of code quality or speed, but it needs to work, at least for the cases presented.

A knowledge of the following:

1. JavaScript

React and Angular, along with other front-end frameworks, are quite impressive pieces of engineering, and it is important to know them well if this is the primary framework you are using for the job. That said, knowledge of JavaScript, it’s core libraries, and browser APIs is something that will support you no matter which framework you use. Additionally, JavaScript is a general-purpose programming language, so doing some simple array or tree processing shouldn’t cause you any problems and shouldn’t immediately trigger the reflex to include that nifty 100k library that you would barely use.

One more thing to pay attention to is asynchronous, the single-threaded nature of JavaScript. You should be comfortable with scheduling pieces of work into the future in various ways and know how to execute some code after those asynchronous calls.

2. CSS

In the world of component-based frameworks and living style guides, you can get away with minimal CSS knowledge most of the time. Yet, when something goes wrong with your layout, or when you need to implement something unique, you need to know how the laying out of a browser works. In short, we want you to understand CSS, but not necessarily keep all the flexbox properties, or browser-specific hacks in your head, although it is certainly a plus if you do.

3. Network

Every awesome front-end application needs to get to the user’s browser somehow. It’s also likely that you will have to make some asynchronous fetch requests to backend services. All of this makes use of network, which means you should be aware of what is involved in making an HTTP request, at least on the level of Wikipedia with a sprinkle of cache-related topics, plus what request latency is composed of.

While it is not a requirement for a front-end developer, knowing the connection on a TCP level is a nice thing to have, as is awareness of HTTP/2. Knowledge of REST services, at least from a consumer perspective, is certainly helpful as well.

4. Debugging

This goes back to the initial section on problem-solving but also touches on every other front-end topic. Browsers are extremely complicated pieces of software with years of legacy, but still evolving at great speed, and this software is our domain as front-end developers. So whenever something goes wrong there, it’s our job to figure out why.

Sometimes it means looking for JavaScript errors, other times you may need to profile your code to check for slow code paths, and occasionally you may need to use CURL to fire off some requests from your terminal.

5. Security

The web, being an open platform, is constantly under the threat of various attacks, targeting both users and companies. Every piece of code and every call that the browser makes is a potential source of security vulnerabilities—initial load of the page, AJAX request, external scripts or iframe, and even a simple DOM manipulation can be vulnerable to XSS, CSRF and various other vectors of attacks. Being aware and vigilant is an essential requirement for the safety of the data of your customers and your company.

6. Testing

QA, as a department or a position, hasn’t existed at Zalando since we brought in Radical Agility in 2015. We believe that it’s each developer’s responsibility to ensure the quality of their produced code, and front-end has some very specific strategies for testing and asserting non-functional properties of the code.

We believe that unit testing is a must for any project, and we highly encourage TDD, especially for a dynamic language like JavaScript. Generally, you would also want to supplement this with some end-to-end or functional tests to make sure users can do what we expect they should be able to do.

7. Tooling / Automation

All of the topics discussed here also require very specialised tooling. You should definitely be comfortable with the concept of resource bundling and the tools available for this purpose. As mentioned above, testing by hand is not our thing, so a setup with automated tests is a must for every project.

Ideally, tooling and automation should be complemented by CI/CD to make sure no code slips past without running those tests. Depending on the project, you might also want to use a transpiler like PostCSS or Babel to help you write more modern code.

Know the standards and stay up-to-date 

Nothing gives you as much appreciation of the complexities involved in making the front-end work as reading the standards do: HTML, CSS, and ECMA. It’s easy to get overwhelmed with more than 2,000 pages of quite dense and very specific reading, so start small. Websites like SmashingMagazine, PonyFoo, HTML5Rocks (and many others) will keep you up to date on the latest developments and might trigger an urge to understand things deeper.

Conclusion

What we’ve collected above is obviously an enormous amount of knowledge and will rarely exist in a single mind; however, you should have an overview of these topics and have a keen insight with a select few to stand out as a front-end developer.

Edited for web by Jordan Platt

The post What knowledge should a Frontend Developer have? appeared first on DevOps Online North America.