DEV Community

Michael De Abreu
Michael De Abreu

Posted on

A thought about the future of web application development

originally posted on my personal blog

Introduction

This will be a personal post about how I would like to see the web development in the near future. However, I will not simple say this should like that because I like it better, but will try to reason about behind that.

The web development is the future

With the introduction of Progressive Web Apps it is clear that the web applications should in the future replace the native applications. But, not quite at all. Technologies such NativeScript, ReactNative, ReactVR and a large renderers have teach us that the web development is not just about a browser, but instead this could be renderer by any kind of technologies.

Aside of that, the JavaScript language can now be used for Server side coding, and have also several others applications, that were just simple unimaginable when the language was created, robots and IoT, just to give an example.

This leads me to believe that web technologies will allow us to develop any kind of application in any kind of platforms, current or future.

The web development is the past

However, we need to change how we develop web applications. The languages that we use everyday have evolve for decades to become what they are today. But we should never forget how that languages were create and the reason why they were create. For example, Javascript was create in only 10 days, and just because they wanted to any developer could glue up some HTML.

Web languages was not created for any of the current applications, for that reason several other technologies and languages was create to allow a better development environment for the web, such Typescript, JSX and CSS-in-JS to name a few, but top used of that new technologies.

The browser itself haven't change much over the years. Of curse, web languages have become standardized and browsers now implements features for that standardizations, and new standards have allow us to develop with new features, but at the end, we are developing with the same languages, and the same syntax, to be interpreted in the same way. We are developing for a 25 years old system, and we have to maintain it.

The web development needs to evolve

I think that new web technologies need to be created, standardized and replace the current ones. We need to keep all the good things that we currently have, learn from the bad things, and apply the ones that the community have embrace over all these years.

Markup language

The bad about HTML

There is essentially nothing bad with HTML, but we need to start noticing the importance of a good write program. HTML was create to write simple elements,
with a predictable syntax, and I don't think we have that anymore. With libraries such Angular, React, and Vue, and future features as Web Components, we are no longer written simple elements, and by any reason we have a predictable syntax. We need to know the properties that the elements needs, and how they will be applied.

The good about HTML

HTML is a really simple to learn, and with that we could develop a skeleton application in seconds. The syntax is simple and play nice with other templates engines, such ejs, and other languages, such PHP.

What we could learn

We need a simple way to define custom elements and isolated templates. The way Vue define templates is really simple. I also like the way Angular consume templates, even when a template could be potentially used by many components, most of the times an Angular template is used by a single complement. Also, this new language have to be used for templates engines, and other languages without much effort, and have to be simple and effective.

What I think should be

HTML as is, is a great language. However, I think that this language have to evolve, and stop being a XML extension to become a complete language on its own, one that allows to grow, but also to keep backward compatibility with older implementations of the same language. Also, needs to have some template logic operations on its own, a syntax capable of be integrated with current and future languages, and maintain isolation.

I think a QML inspired language could be really good for the web. The tree structure that QML manages, resembles HTML, but its mean to be written for complex applications and to handle custom elements. It doesn't have to be QML as is right now. For me, this is just an idea, but I think we really need a markup syntax made for current applications. One more thing that I would like to see in this language would be typed attributes, and a simple way to define them in new components.

Style language

The bad about CSS

As with HTML, there is nothing really wrong about CSS, it is a simple language to learn, but is really hard to master it. Also a couple things that needs to be improved. One is the need for a way to apply isolated style in custom components, and restyle that components easily as well. And if you are thinking "Shadow DOM have that", yeah, it does. But Shadow DOM is still an experiment, and the specification is being developed, with several things being dropped, and replaced. Let's face it, adding a new feature to CSS is too slow, and even when we have it, we need to wait until majority of browsers could support it, and prefix the properties with the vendor name for properties that are not standardized.

And that leave us with the second thing to be improved. The current way to bring new features to older browsers is to polyfill them. CSS is really hard to polyfill, and effectively unviable.

The good about CSS

Like HTML, CSS is a really simple language, that can accomplish complex thing.
As I said, is easy to learn, and most of editors have autocomplete capability.

What we could learn

We could learn as much as SCSS let us to learn. I formerly thought that SCSS stands for Super CSS, I know, I know. I was just beginning in web development, but can you blame me? The syntax is identical to CSS, and it allows to nest selectors, apply mixins, use variables, and many other things. SCSS have become in many case the standard way of develop web styles.

What I think it should be

The new language for apply styles in complex applications should resemble CSS, with the features that SCSS allows us to have. What I'm saying is, the features that SCSS allow us to have should be standard. Needs support for better cross file references.

I think it needs some standardizations of the currently spec, including the initial value of the rules, and a standardized unit value, that would display nice in every device, and I not talking only about web consumer devices, but other renderer engines should display the same structure identical. In deep, it needs to be able to play nicely in older implementations of that language, and a simple way to polyfill when it need.

Scripting Language

The bad about Javascript

Javascript is broken. It was born broken, and it have been broken ever since. Nowadays, there are more, and more new features that are being added to the spec, but we are just putting some band-aid in a broken leg. That just won't work. Even now, when Javascript engines interpret scripts almost the same way, there are several things that are just wrong with the language, and they are in its bones, you can't just make Javascript work as a proper language anymore.

This, I believe, and no other, are the one thing that needs to be replaced. Javascript is a language that can now run in a multitude of device, in a large amount of platforms, and it is just broken. We don't need to keep adding new features to Javascript, we need to write and standardize a new scripting language that could be used to develop complex application.

The good about Javascript

Javascript is an incredible easy programming language to learn, and it's also powerful. Every single thing in the web right have some amount of Javascript, and now, even mobile and desktop applications run Javascript. I think that's amazing. You don't need a complex structure application to start a Javascript program, you just need to write a function and then called it. The simplicity is just beautiful. Adding new features on older browsers with polyfills are easy and accurate, most of the time.

What we could learn

Projects and languages as Typescript, Flow, Props, and several others, say to us, that even when we don't want to, we need this to be a typed language. Large enterprise level applications need a predictable way to work with, and Javascript is just not predictable at all.

New features such spread operator, decorators, template strings, and others, have show us that a language needs to evolve from what it is to what the community wants.

Even libraries should be something we need to learn from, for example Immutable. That brings something something like immutability to Javascript, and have teach us why this is should be important. There is even a proposal to bring immutable feature to current Javascript.

But, what we need the most, is to learn about the Javascript weirdness and just make a proper language. We don't need a triple equal operator, we need a equal operator that don't do weird things underneath.

What I think it should be like

No surprise here, I think Typescript needs to be effectively the Javascript superset that it says to be, or at least, something like it. Sure, currently Typescript compiles to plain old Javascript, some times even making ES7 features available to ES5 browsers, but what would be better if for the browser to properly understand what Typescript code actually mean. This would allow to take advantage about the type system that Typescript have, the better is that being a super set of Javascript, every program written in Javascript is a valid Typescript program.

Well, now that we are dreaming, we could deprecate keywords such var, and operators like === in favor of the new syntax let and const, and simple == without any casting. I would even say that const should be able to store a constant object and function, in which the assignment of new values for any of its properties, recursively would be impossible. classes would be classes for real, and could be written as any other class in other languages. interfaces would be a real thing that you could check in runtime. And several others features that would result in a better language.

The language would still the same function first language, with the nice syntax, optional typing, falling back to our dear any type when there is not assignment or type declaration. Well, if we still have any type, there should be a type transformation when dealing with equality, right? Not exactly. Even when the type is not specify, the variable still have a type when gets evaluated, that is somewhat the current behavior with triple check equality.

The Web apps

The good about the Web apps

The web applications are not compile for an operative system, nor they run on top of a virtual machine, they are run inside of a browser. But they can be compile for an operative system, and the could run on top of a virtual environment, and they could be used to program servers, and robots, and any kind of things now.

What is really good about the web applications, there are just developed using standards. You may notice that I use that word a lot along the post, and the reason is because Web as we know it, is just a complex series of standards, that can be implemented in anyhow, by anyone, anywhere. To do so, you just need to properly implement the current specifications about the technologies you want to use, as best as you can, and you can even decide what to do in things that are not properly describe. I think that is beauty. I think that is the future.

What I think it will be like

Maybe not in a year, maybe not in two. But sooner than latter, native web applications will be in our lives, they will behave like any other native application that we currently have, and will perform likewise. I'm not talking about Cordova, or NativeScript, but deep integration of web applications with the operative systems.

New operative systems that will only need to implement web technologies to be usable, and new web rendereres in devices we only dream now.

Applications will be develop like back in the days, when I didn't actually code, with a language for a feature, without bundlers, transpilers, or anything that we currently have. Because we will learn from what we have, and evolve.

That's all folks

If you really read all this, thanks you. It's a really long post, and it's very opinionated. I would like to read in your comments, how you imagine the applications development would be in a couple years.

Top comments (2)

Collapse
 
nektro profile image
Meghan (she/her)

I said this in a somewhat similar post the other day

I don't think web apps will entirely replace "native" applications, but I don't see any reason why these apps couldn't be made with tech very similar to JS, HTML, etc. On the other hand, I definitely do not think that web apps should ever get free roam access to a user's filesystem. I don't think native apps should even have free access to the filesystem but you can't fix the past, only build a better future.

For instance, it wouldn't make sense for a web site to have an API to host a web server. But a server and no-CORS networking is definitely an API some apps would want and make total sense in some cases. Something similar to ChromeOS is definitely the future, but it was ahead of its time because Google is really bad at advertising its own technology. The future I see is 99% of apps are web sites, and the small rest of apps use some standard for accessing native APIs (think POSIX 2042).

Web apps are definitely the future, and while there are some gaps that still need filling, a lot of work is being done to get us there.

Collapse
 
oneezy profile image
Justin O'Neill

Very nice article! I wrote a similar piece a little while back that talks about the future of web and where I think* we're heading.

Have a read,
medium.com/@oneeezy/frameworks-vs-...