... 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
sameer -
Himanshu Aggarwal -
Anish Ghimire -
Sai Charith Puligilla -
Latest comments (38)
Nice video that show the JavaScript development progress:
The Story of Next.js
It definitely could be that way still but the critical thing promises added over callbacks was an immediate return (of a promise), where as callbacks didn't immediately return.
This lent itself more to a chainable
.thenstyle that could be structured into a relatively flat format. async/await just took that one step further by enforcing the linear progression. Interestingly, I see people awaiting every possible async call now even when it's not necessary.I no interest in furthering this narrow discussion on node for the server when a large proportion of my node apps are tools, good day.
You can say whatevery you want, but I don't think you're right. Of course you don't need to agree with me. You have your own option I have mine.
Also I think that you don't understand the purpose of this post and my comment. This is my personal milestones in JavaScript development. You can't say that I'm wrong if I write my own experience with JavaScript development. Your experience may be different why don't you write your own milestones instead of jumping on me.
Also I've written:
It was first framework that added reactive way of writing SPA with double data binding, with declarative way of writing components.
Not sure how math being slower relates to complexity but okay nobody claims that node is the fastest, it's not supposed to be fast is not the only metric I suppose.
The question Ben asked was what has changed and JavaScript moving to the backend was absolutely one of them.
I can see you have some issue with JavaScript people getting involved in a really complected world of backend and screwing it all up which is really short sighted, you can know a lot of typed languages and still write JavaScript
That is completely fictional, your tech stack matters to it's particular application, high per for high perf requirements.
Choosing a language for light speed when your making a to-do list is not a good idea contrary what some might tell you.
Being able to maintain a stack is, look at dev.to it's ruby, is ruby known to be fast? No, is it beloved, I hear it is
Yes but you write your code in ASP, you can write application and don't touch JS at all. The same Google GWT and R Shiny are not JavaScript. We talk about Pure JavaScript, not some Hybrid. ASP.Net is C# framework not JavaScript framework.
Check Wikipedia there is only one mention of JavaScript in this article. I think that you're confusing web app development with JavaScript development.
ASP.Net is not JavaScript if you're not aware. There was also GWT but we don't talk about other langauges.
Evidence to support these claims?
Lots!
I'll leave it to others to expand on the details. But believe me, it's lots! ;-)
From front-end dev perspective...
In 2013 we could have maybe 10 mostly small scripts on a major site that did all the necessary UI things, loaded when needed per page basis, controlled manually. Most of the time went into ensuring cross-browser compatibility. Fancier ultra interactive and complex UIs were kinda hard to maintain. It was the end of an era just before React become a thing. We lost Opera Presto, we were freed of IE8.
In 2017 sites were written in full JS with massive bundles which resulted to time spent into researching optimization. Code splitting, tree shaking etc. were becoming a thing. Most of your time went into dealing with all the code now in front-end that you never before had to care about as a front-end dev. But hey, you could make maintainable fancy ultra interactive complex UIs. For mobile phones, with responsive design! And curse that you still had to maintain IE11 compatibility.
In 2021 we got started getting solutions that allow getting the performance of 2013 and small bundles, but now with new modules and tooling. But really there are two major changes: you no longer spend much time at all dealing with cross-browser compatibility, and you are not controlling script loading manually as that can be automated by tooling. Every few months a new great HTML/CSS feature lands that allows you to throw away tons of JS.
Overall, from pure front-end developer perspective, there was a lot of innovation and organic progress, but most of it wasn't really focused into solving things that mattered the most. It was a noisy road. But it is now in the past. I think 2022 is probably the most friendly times ever to become a front-end developer for the web. We have moved away from slowly evolving stagnated browser space to true evergreen browser era, and we have tons of JS solutions to pick the best one for each job (or pick the wrong one and figure it out too late).
A couple of decades here.
My hopes for the future
One of the best overviews I've seen here :)
Back in 2000 I used to build website for IE 5.5 and Netscape Navigator using HTML, CSS and vanilla JavaScript. There were WYSIWYG editors for HTML like Microsoft Frontpage and Dreamweaver.
Today to publish front-end code the developer has to use several tools and technologies like IDE, Browser Support, Responsiveness, React/Angular/Vue/preact/next/gatasby etc., LESS/SCSS/Styled Component ,TypeScript, Unit Testing, linting, Github/BitBucket, NPM, Webpack, Node.js, DevOps and the list goes on...
Frankly speaking I just miss those days!!
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!
JavaScript Web Almanac 2021 covers exactly that!