... And what new things changed it the most?
For further actions, you may consider blocking this person and/or reporting abuse
... And what new things changed it the most?
For further actions, you may consider blocking this person and/or reporting abuse
Top comments (38)
A couple of decades here.
My hopes for the future
One of the best overviews I've seen here :)
We used to make sites with Internet Explorer in mind. (40-50% market penetration, Moz was around 30, Chrome around 10-15%). MS dictated the web in some way or other.
Now we make websites with Chrome in mind(90% is either Chrome or Webkit based, Moz is at 4% ). Google dictates the web.
I remeber when DHTML was a thing, it was when I've started learning JavaScript. And my dream was to create Modal Dialog that you can drag & drop. But the tutorials I've seen was way to complex for me, and I was never be able to do that back then.
So I think that biggest change for me was appearning of frameworks and libraries that was making things like this easy. First DojoToolkit, Prototype.js, Script.aculo.us and later jQuery was first game changer for me.
Also before the frameworks there was AJAX revolution that was big thing, that give birth to JavaScript applications.
Second big thing was AngularJS that was probably the first ever full framework where you could create your own SPA in better way. AngularJS was pioneer after it came the Trinity: Angular, React, and Vue. Each of them can be its own milestone in JavaScript development.
I think that major thing was also NodeJS and appearing of NPM (anyone remembers Bower?). And of course Babel (with other tooling like Grunt/Gulp/Webpack) that allowed to use Latest ECMAScript right now.
Framworkization, mostly.
In 2012, jQuery was a good gateway drug to JS. You didn't necessarily have to get it's syntax details, async weirdnesses or compatibility issues, but you'd still have to understand how JS worked.
Now most people learn JS through React, Vue and Angular. Those bring a very nice DX and speed with them, but devs who have no experience outside their framework are on the dry.
The same goes for HTML and CSS, by the way.
Utility-first CSS (i.e. Tailwind) was a major step in this direction — In a good way for the sake of productivity within that environment. But possibly in a not-so-good way for dependency dependence and learning.
A decade ago I found the CSS libraries available were generally worse than just writing plain old CSS with some sort of self-imposed structure. These days I think some of the new stuff is truly really awesome to use, but it's not necessarily a good thing if it reduces peoples' capacity to interact with CSS proper or write websites that don't require the build step.
This is so true... the days of adding Bootstrap (or some terrible WP theme) to your project and then having to go through sooooo many classes to overwrite them shudder. I'm so glad those days are gone.
It's become ridiculously overcomplicated and over-engineered
I made my first public website in 2011. Back then, the files I wrote were the website. If you used View Source or Inspect Element, you saw the code exactly how I'd written it. No transpilers, minifiers, bundlers, linkers, anything. Cross-browser compatibility was a huge issue; I had to test everything by hand in Chrome, Firefox, and IE. But still, it was a great time to get into the web. All you had to learn was HTML, CSS and JavaScript. Maybe a bit of jQuery.
Today, very little translates literally from the development environment to the public webpage. My code is compiled from TypeScript to JavaScript, from Angular templates to HTML, from scoped SASS to CSS. Every function sits under ten layers of framework code. It's much, much harder to learn anything about a website by opening the dev tools in your browser.
I enjoy using these tools. A lot of them save me time and energy. Smaller teams can take on more ambitious and complex projects. The web can do more than ever before. It's becoming the default platform for small-to-medium-budget software. But I feel a lot of trepidation on behalf of new developers. Just to keep up with modern web development they have to learn HTML, CSS, JavaScript (which is more complex than it used to be), a JS framework or two, a JS testing framework, a JS utility library, a state management library, TypeScript, Webpack, a CSS preprocessor, a CSS framework or component library, NPM, bash/shell, Git, and a handful of third-party packages. And that's just the front-end. A lot of companies want full-stack devs.
Yes, you can still build websites the old way. Yes, each of the technologies I've listed provides unique value. And sure, not all of them are necessary in every project. But still, if you're a new dev trying to land a job in a market that overwhelmingly caters to mid-level and senior devs, you'll likely be expected to interact with all of these. It's overwhelming. I'm lucky I was already in the field when they were being invented and popularized. If they'd all been sprung on me at once it might have scared me off.
Anyway, my hat goes off to anyone who's gotten into web development within the last few years. It's a lot. And if you've been in the field longer than that...well, give an encouraging high-five to the nearest junior dev. They probably need it!
Thanks to babel, typescript and standardization the language became not only powerful but also reliable, compared to 10 years ago.
On the framework and library side we see a huge fragmentation and as an engineer I wonder how many hours/days other people invest into choosing the right tech stack for a certain project. To me it starts to become highly unproductive unless I either stick with big names or with what I am familiar with.
The noise around the Types as Comments proposal seems to confirm that there is a lot of wishful thinking in the industry.
For an example of how the TC39 committee operates look at the ECMAScript Observable proposal from 2015 with the last review in 2017:
"Why does this need to be in the standard library?"
Or in terms of the "Types as Comments" proposal: "How does this need to be part of ECMAScript?".
Clearly it benefits TypeScript but it also delegates the implementation effort to the JavaScript engine teams which cannot derive any benefits as "types are comments".
In conclusion I would be extremely surprised if the "Types as Comments" proposal gets anywhere near Stage 4.
Given the tooling involved from the ECMAScript perspective this is much less invasive:
largely inspired by the Hindley–Milner notation used in Haskell - which also happens to cleanly separate TypeScript's type space from ECMAScript's value space.
Basically this approach puts all the effort on the TypeScript team
@type)Simply focusing on promoting
@typeusage and improving ease of use of all TypeScript features within ECMAScript would be helpful; i.e. streamline today's JSDoc TS features to make TypeScript much more JS friendly.But even that would be likely ignored by the existing TypeScript userbase because of the familiarity trap even in the face of endorsement by leading personalities.
So it's unlikely that much is going to change in the "typed ECMAScript" landscape (short of V8 just implementing it anyway - but their incentive is pretty low).
The proposed 'types in comments' stuff belongs in a browser extension for TS developers. It has absolutely no place in the JS engine
I think Microsoft finally ending the browser wars started a new era that made compatibility-centered frameworks like jQuery mostly obsolete, new MVC-pattern frameworks took over in the front-end.
At the same time, transpilation really took off, hastening the adoption and development of new language features in JavaScript/ECMAscript and Web APIs. The overall tooling improved beyond recognition.
This powered moving logic from the back-end into the front, blurring the lines between web sites and applications. Static apps, powered by minimal back-ends, became the new norm.
Interestingly, the revolution keeps turning. With JavaScript running in the back-end, we're going full circle with remix or astro and having the same logic that we previously moved to the front-end inside the server to increase rendering speed.