When I was a kid, my grandfather used to tell me about his wartime adventures. He served in both World War I and World War II. He was a boy of 1899...
For further actions, you may consider blocking this person and/or reporting abuse
Hi Andrea, Thank you for an excellent article.
Back in year 2000 we came across the forerunner to the XMLHttpRequest component in the form of MSXML2.XMLHTTP.
MSXML2.XMLHTTP was introduced to the Windows environment courtesy of Microsoft Outlook but could also be used in MS Internet Explorer (5/5.5) to enable 2-way communication between the server and browser. With an XSL-T transform into HTML and some JS-based DOM manipulation (the hard way) the screen could be updated without the need for a page refresh, improving the user experience. Thus the SPA was born and a few years later Jesse James Garrett would dub the technique AJAX. It would be some years later with the release of MS IE 7 ( and other browsers) we would get XMLHttpRequest integrated into the browser and IMO Web 2.0 was born.
I have been designing and developing web-based business applications ever since.
Regards, Tracy
Hey Tracy, thank you for your reply.
You may be right. There was a lot of excitement in those years, and the idea of an application that could run in the browser was in the air. It was not called SPA, but very often it was called RIA (Rich Internet Applications).
The point is that there is no scientific definition of SPA, although it is commonly understood to mean an application that runs in the browser without the aid of an external runtime, such as Flash, for example. In the case you mention, there was a dependency on
MSXML2.XMLHTTP.However, at the time, IE introduced several innovations that went in the direction of today's SPAs. I also remember the XML Data Islands, the ancestor of JSON.
By the way, I think the page address you mentioned is this one.
Oh blimey. You've rekindled some painful memories. There was a time when I wrote a search interface to a large Domino backend that used the MSXML2.XMLHTTP component. MSXML2.XMLHTTP to fetch the search results. XSLT to draw the interface and results. And.... my memory tells me that it worked pretty well.
Webcomponents are basically Javascript modules, that are called through HTML-tags. They can provide some fancy, well-encapsulated building blocks for your page. But the backbone of your page will be limited to what HTML provides. Is this really enough? Are we still only "composing" our content?
Everyday new properties are added to CSS to meet growing demands. But it is really hard work to create a fully responsive app using CSS only. What, if your page needs to be completely different on a smaller device? Or you want a different appearance at night? Should we add new CSS-properties for every possible situation?
Modern Applications act more like desktop apps, they need a lot of reactivity and responsiveness. And they need a lot of internal communication. This can be provided by modern Javascript without adding new extensions every day. It is easy to create a different page, if you build your UI programmatically. So, possibly frameworks like Svelte or even more radical VanJS will do a better job.
If you need completely different page on smaller device consider building 2 pages instead of trying to smush it into one. Apply concepts of composability. Design 2 pages but identify reusable pieces. HTML components really are perfectly scalable. In the end of the day all frameworks builds on top of same DOM api so DOM is always limitation and the bigger the more complex app gets typically the more direct-dom hacks are necessary to overcome framework's limitations. HTML components don't really have more limitations compared to any framework - they are more scalable than any framework overall - main issue is developer-ergonomic as api is little more cumbersome to use and you need to have more knowledge of possible architectures to use them effectively and majority of developers simply haven't got working knowledge about it.
What a great post, thanks! So many memories... I remember back in the day when the only way to update a page without reloading was submitting a form to an iframe and returning a script tag that called a function in the parent window.
Our life as developers is so much easier now :)
We’ll written and very informative article! 👍🏻 I actually remember a lot those things as they became popular.
I think PHP deserves to be mentioned here as well. I remember it as the de facto way to build dynamic websites, if you didn’t want to get started with Flash or Java Applets. And then came Node.JS…
Hey @chris, thank you for your feedback!
I deliberately wanted to focus on front-end technologies. These are the ones that have undergone the most disruption and caused the most problems for developers, users, and browser vendors.
The evolution of server-side technology is a different story. It has been quieter and users have generally been unaware of it (as it should be)
That’s true and makes sense!
Great post
What a great article!
Awesome! By the way, I wrote a book about Web Components a few years ago :-)
Great post! it was fun reading and an opportunity to rethink about the goal of the web development not just for a 'job'. Thank you!
Сongratulations 🥳! Your article hit the top posts for the week - dev.to/fruntend/top-10-posts-for-f...
Keep it up 👍
python is envious about kingdom of javascript at the front-end
Who knows what we will see of Javascript vs Pyscript in future
Isn't already everyone free to use the tool of their choice to create components that can be used on the Web ?
Sure, everyone is free to use the tool they prefer to create components. But the point is: are components created with the tool A interoperable with components created with the tool B?
This is the missing piece to restore the original interoperability of the World Wide Web project IMO.