If you’ve been in web development for more than five minutes, you know the drill. Every few months, a new JavaScript framework pops up, promising t...
For further actions, you may consider blocking this person and/or reporting abuse
There are many things you got right and almost as many wrong.
The Right Ones
I don't intend to make this section the smaller one. Is just that, because these are the things we agree on, there's nothing else to add. The next section will be more elaborated.
The Wrong Ones
Being a Svelte fan I just have to ask about Svelte's "but": Why "but you're locked into a compiler". So what? C++ has one, and I don't hear anyone saying "it is so much better to just write assembly". This is not a "but" in any shape or flavor.
Yes, it is true that many frameworks don't really advance anything. However, some do, and a few of those really do it. Let's go back to the jQuery days. jQuery is awesome, even if it is already in the list of banned technologies at companies. I agree. But the "ridiculous amount" of websites still using it may not be due to its greatness. It might be because of its timing: It was the first of its kind.
Moving forward, we encounter React. This one was the child with the silver spoon: Not only was it the child of a big company, it appeared early enough to wow the world. In retrospective, people should have stuck with knockout.js, but that's a different story.
Moving forward, enter Vue, Svelte, SolidJS. Vue did a great job bringing simplicity to the now chaotic React, but then, the next kings came. Yes, I do consider Svelte and SolidJS the next royalty. Why? Because these are the frameworks that really did it. But I'll talk about that a bit later.
Point being here: If we discourage innovation, if we are dismissive of new attempts, we will not advance. Just because only a few percentage is worth it, we should... nay, we must never stop trying new things.
About the money: Job security is around React and Angular, true. But will this hold true forever? No chance. Actually, if you're really smart, you'll promote and foster change and research. Better than hoping things will never change is driving the change yourself. Embracing change is always the better option, but has to be done responsibly.
The New Royalty
Before Svelte, "React is so performant because of its Virtual DOM algorithm". After Svelte, "React is so slow because of its Virtual DOM algorithm". This is a well-proven fact. What once was a great strength, Rich Harris tore down to tiny pieces and fed the dogs with the remains.
Close by was Ryan Carniato cooking something just as awesome, aguably more awesome to be exact: Signals. Well, at this point I should bring knockout.js again, as it was, to the best of my knowledge, the first signal-based library. Still, full credit to Ryan Carniato, author of SolidJS. He saw it, he evolved it, and damn, it was great. So great, Svelte favored signals over compiled reactivity, which brings us to present times.
Have We Advanced?
Yes! There is no doubt. For people that are unaware, see the benchmarks for yourself. The once great React is in the bottom. Angular? Definitely hotter, but still significantly down. And who's on top? You guessed it: The new royalty. Svelte and SolidJS are the top performers that are in good enough shape to be seriously considered to take over.
But we haven't advanced in performance only. Svelte is so much simpler than React it's scary. Svelte can do React's job in around 30% less code, and can do it better. Svelte's DX is superior, and I don't say this, developers around the world say this.
So what should we infer of all this? That trying and failing is not a futile exercise, because without trying there won't be successful instances. We just need to be cool-headed about the "next best thing".
Svelte is one of the most beautiful things that have ever happened to frontend development.
The reason is that HTML is static. People looking for a way to display content dynamically. HTML should work on supporting something like loop or variables, instead of those new tags that no one bother use. Btw, why didn't W3C provide an official template engine? Companies just want something future proof.
Are you asking me? Because I don't drive the standard.
HTML is a markup language, not a programming language. I don't personally think HTML will ever get programming-like behaviors like CSV will never get them, like Markdown will never get them, etc. You get the idea: Clear separation of duties.
As for the new tags "no one bothers to use", they are very helpful and you should start using them. They come with great benefits for interoperability, such as the thumbnails that you see when you embed URL's in comments here, to accessibility for screen readers.
oh...sorry I was intended to reply the author. But thanks for your reply. That's very kind of you. I agree with the separation of duty. But being a markup (or markdown) language, doesn't mean it has to be static. One example is XML. It has XSLT for more programmatic features, while HTML didn't get enough love for an HTSLT, what a pity.
Ah, but XSLT is not, XML. XSLT is an extension, something that goes on top of XML. In that sense, HTML could get an extension, but HTML itself shouldn't be given logic-driving tags. At least that's my personal opinion.
Still, I understand now where you come from. Cheers.
came to ask about the same thing. how is a compiler going to lock you in? what does that even mean?
I don't know. I guess it's the only thing the author could think about being "bad" for Svelte, but Svelte is perfection! 😄
I get paid way, way, way more working with svelte than any other js framework because I can deliver 10x as much as any other developer specialising in another framework. And no shortage of work!
So you're making way less, because you're working 10x faster. Unless you're doing fixed fee projects?
Fixed project fees are one way.
For muself, it was a little unique to my set of circumstances:
On a team with 10 FE Devs: 2 svelte 8 react. Working on 4 sub projects for a large financial institution. They needed the projects "done yesterday". Svelte Devs were delivering results 10x faster than the react Devs. They fired 6 of the react Devs and forced the other two to learn svelte. Svelte Devs got a handsome raise plus big, big bonuses at the end of project. Bosses some to other bosses at other financial institutions and other big companies around the world and we got a reputation. Our hourly rate went from $48 USD p/h at the start to $190 USD p/h now working on other projects for other companies. 👍🏼
I have no way of verifying anything you just claimed :B but it sounds like you dealt with some pretty bad (React) developers 😛
True, and I'm sorry about that. I mean I could PM you some of the emails, but I think that's a bit too much. 😅
I'd rather make the argument that I've got nothing to gain my lying to you, not will it benefit myself. 🤷🏼
Or, rather is just recommend you learn svelte and go hard and see what happens to your career in a year or two. 🤷🏼👍🏼
Hmm. 🤔 I wouldn't call them bad react developers-- I did work, (briefly), on a react project with a few of them and they were nothing to sneeze at.
I once did a Pomodoro FE challenge in both react and again later using svelte, and I was significantly faster in svelte than react.
Happy to screen record me doing it in svelte and compare you doing the same with react of you want. 🤔😉
I'm not really interested in competition as it proves nothing. The measure to which I hold my code are all not related to speed. Yes I've used Svelte and I might consider using it more if the ecosystem grows. However I'm principally not a big fan of framework code that needs a compiler to mean anything. You're not learning JavaScript, you're learning Svelte and if Svelte dies, or makes a big shift, you're back at square one. I'm more interested in acquiring knowledge and skills that are transferable between frameworks.
Aww. Son I am disappoint.
I guess you proved my point that your not in the top 10% or developers.
I have no interest in being in the top 10% if they're all as arrogant as you 😛 I prefer being in the top 90% who try to lift people up, instead if putting them down.
... while the old frameworks (or (software) products), if they can, adopt their contenders' most crucial innovations, so there are even less reasons to change.
So, your next jump will from tree to tree (
js -> rs) instead of branch to branch (react -> vue -> angular -> solid).I think, you should focus more on frontend (UI) instead of DevEnd, mean to say you should stick to one base framework (although you can choose from a variety of js and ts libs for third party tasks) that fits your level and favor (speed or style or support) and try inventing new things in frontend (UI) and that matters the most, in my perspective.
The issues I'm having with these JS frameworks are:
many (or I'll just say the majority) of the so called react, vue, .. developers don't even understand the difference between '1' and 1. Don't have a clue what http request is and do not even understand the whole of the web as it is. So many of them call themselves react, vue, etc. developers but when site is running slow, when JS they use is not working as intended, then they are lost and provide extremely invalid solutions.By default they are writing the poor code. Also it's mostly the wrong tool to use for the things they do.
these new frameworks were developed for client side apps. Fact . They were solving one thing and they did it well. To stop annoying server for the stuff when not needed. Now they are doing SSR which is wrong on so many levels. There are just plenty of WAAAAAAAAAY better frameworks for SSR stuff and they do it way better then all of the current JS.
In these days all of these frameworks should be working off the main thread and they are not, thus all kinds of rendering issues and cumbersome results.
I completely agree with your perspective, and I've been following a similar approach for quite some time now. It's crucial to focus on understanding core concepts and problem-solving techniques rather than getting caught up in the ever-changing landscape of syntax variations.
Front-End domain is constantly bombarded with new NPM packages claiming to be the next big thing. However, more often than not, these are just repackaged versions of existing solutions with slightly different syntax and API names.
My strategy is that keeping things simple (KISS and DRY principle) and minimal is the best approach which involves writing custom code where it's truly needed and only use NPM packages when they provide significant value. This approach has benefited me in keeping my applications healthy and performant, makes scaling much easier, improves maintainability and manageability.
I can't help myself being a bit nostalgic for the days when web development was more straightforward – just HTML, CSS, and vanilla JavaScript (No bells and whistles). Those technologies, in their purest form, were often all we needed to create functional and efficient websites. I hope many agree with me if you are from the era of IE 5.5 :)
While modern frameworks and libraries certainly have their place, there's something to be said for the elegance and simplicity of the basics. By focusing on fundamental skills and concepts, we can adapt more easily to new tools and technologies as they emerge, rather than becoming overly reliant on specific frameworks or libraries that may become obsolete.
While I share your sentiment, I'd say we have made good progress in all this. JavaScript that works like CSS? ESM. The tree shaking, just transpile and import? That's a full circle on our plain old script tags that are so modern now.
This is the setup I'd go for any day today: vite with a index.html, typescript with esm. Boom! every performance out there today out of the box with best developer experience. All the original bells and whistles.
The Web you're nostalgic about still exists with the best experience yet 😊
GP, I share your feeling nostalgia for simple web standards. In a recent project we have abandoned JS frameworks in favour of HTMX for server interaction, Alpine for progressive enhancement of the UI and Web Components based on Lit. I have found this combination, with the backend (templating engine) of your choice, to hit the sweet spot. Say goodbye to building/bundling the frontend. It's working well for our CRUD applications.
You're absolutely right.
I'd prefer those three than any frameworks anyday
I also think front-end frameworks change too quickly. We should focus on understanding the core theories and design ideas of these frameworks, rather than getting caught up in their syntax.
Feel this! I got tired of having ssr frameworks shoved down my throat for building frontend web apps. In most cases, a well designed single page app and nginx will blow any ssr framework out of the water.
So I was like thats it (╯°□°)╯︵ ┻━┻ , time to revive an ole strategy i wrote about a while back on dev.to ...
but this time I am going to open source it and make it easy to use for FE devs. So I bring you, GoDeploy, a CLI written in Go. It will containerize your single page application and automatically setup nginx configs to cache your hashed SPA assets with cache busting built in. You can build single page apps or static sties/apps with any framework and deploy it anywhere that runs docker.
Then I remember I missed the good ole days where you could deploy a single page app in one command, I missed that, so I built that as well. Which is an option for anyone who wants to just deploy and not deal with docker, or cloud providers, infra/devops etc...
Would love feedback from anyone who is willing -> godeploy.app
More on this here dev.to/matsilva/anyone-else-tired-...
Didn't jQuery just get a facelift too? That includes a compiler, or atleast I know npm has packages for react , next etc... the difference being that next.js for example is all about the virtual Dom and not actually manipulating the actual Dom. Which is why lately I've been considering jQ to do this instead of fighting the useEffect(). Thank you for the article, I'm going to have to see if I can make jQ be as fast as nextjs. I still use php servers and wp backend for CMS so why not? I can't tell you how often I'm thinking, "jQ would have cleared that up much easier." Than fighting the react next only using static practices because I don't have clients needing dynamic content...
You're mixing up so many things I don't even know where to start...
But you wont beat Nextjs static rendering with vanilla PHP and jQuery. These frameworks apply massive amounts of bundle optimization and caching.
My opinion only.
Much of this is not worth debating. Each framework has its flaws and advantages.
Use what fits you or your company’s policy.
If you’re in the position of choosing which framework or no framework is to be used, gather a consensus of the team.
Maybe consider what is more important of the result of that decision; the developer experience or user experience.
Move forward.
There are also state management libs other than Pinia and VueX for vue.js like rstore and nanostores, although I haven't tested them.
P.S. - I know it's not place to write ps at top, I just wanna say that I'm still newbie, 1 year old I guess and currently learning React😅
If.im being honest, I read this yesterday night and thought about this that you were correct from start to end but in those midnight thoughts, I researched with myself and found many conflicting things.
There are many rights which were totally right like don't go in hype ( your hype cycle was totally agreed. I also found someone who had same thoughts just like me🤣🤣🤣 ), but then my mind came to something when you said there's still thousands of websites running on jQuery the og, it's not because people loved that, it's because at that time it was only one and just like you said companies can't change thier working app ( just because someone hyped it ), same goes for php, there are Manu sites running on it not because it's great but because at that time it was only one.
Most old thing came to end, found better alternatives, jQuery is nearly dead ( as from current people choice, php is dead.
Only Bootstrap I guess is exception ( I know it's not js, it's css framework, I mentioned this cause just like js, css also has nearly same lib/firework hype and new new things ), cause it's great and then few years back came tailwind, which gave more customization and became favorite, and I don't think for next several years they are going anywhere.
Now come to React and Angular, yeah, they have great community and people, has nearly job securance so why would I learn to go towards Solid or Svelete where in my country React, Angular, Vue is dominant. I know it's cowardness to support wrong ( which still isn't wrong ), but I can learn other things when I've a job, then after learning I can tell anyone with my own experience that what is nice or not, should we change over app framework to x to y just for few milliseconds/microseconds. I also learnt React Router, Redux cause they were ( are ) popular, but I just finished learning of TanStack router ( I can't give my real opinion until I taste that with thousands of time ), learnt Zustand, and I can tell that not all needs Redux, if can work with smaller, go for smaller.
All I just wanna say is If I've job then I'd like to try new things, just because it's fast and better but no job then what imm gonna do with that thing.
And bro, I don't know what's future of React, Angular, thay can also become just like jQuery or php, and more better things come ( always hopeful ) which actually changes WINDS.
I've heard from many people that Svelte and Solid are great ( even I talked with Solid creator ), and heard many people saying that React becoming chaos tonnage, don't go for react, but instead of listening to any of those, you've a family to feed, should consider for yourself first.
Note : I know flow of this replay is total mess🤯
Edit : same goes for code editors, many IDE came and many IDE gone, many came with built in AI and gone and many of people are still comparing one with another, after writing this article, I just found a article Co.aring two AI ides and came back here to edit this. People still love VS code even I tried few of them and always found VSC as per needs, it gave me confortaness, it has mostly all features I think of ( if you belive I've 250+ modifications in my settings of vscode which shows how greatly customizable it is and each month they're adding new to it ), and for something which isn't builtin in default, I finds an extention. And 2 Iade foeyself ( 1. I guess majorly for react, you all time needs to create 2 files, one compo file and second it's corresponding module css file, so I made that and Happily using it,,, 2. About organization of import, I made custom script with high customization and will publish after more testing and implementing everything )
I agree on all accounts.
Now day frameworks are all doing the same, you do not switch for performance or a different syntax.
But you need to ask yourself, what kind of features will make you switch framework, now that you know a few?
I am exploring the areas of design to code at the framework level, 3rd party security at the framework level and full stack components at the framework level. Those are features that are not present with other frameworks.
But before I go to convince you to switch, I am mostly interested in what do you expect from a future framework, one that worths the pains of a switch?
I agree completely. Chasing the shiny object is risky and often wastes time while you're ramping up on the new tech.
We only just decided to adopt Vue.js for our app. It currently relies heavily on jQuery. We feel like Vue is mature enough, and we've used it on a handful of other projects so we are familiar with it.
But still, I find myself wishing that I could just manipulate the DOM with some jQuery at times.
It is hard to learn but not when you are ready to give 10 hours a day for 1 month you can learn it i can make you learn it.of course you don't have to give 10 hours everyday but in business days 8 to 10 hours and in weekends 4 to 5 hours is enough and must to have dedication to learn.
I completely agree with this perspective. Constantly jumping between new frameworks can be more of a distraction than a benefit. Instead of chasing the latest trend, focusing on mastering core JavaScript concepts and building solid, maintainable applications should be the priority. danchoi.com At the end of the day, the best framework is the one that fits your project needs, not what's trending.
I have faced issues with Javascript frameworks in security tests (like VAPT) and decided to go back to plain Javascript. This is not because of any issue with framework, but the frequent new versions. My product's various versions run at different cloud environments for specific clients. Clients run security test on their instance at their time and interval. Security test suggest upgrade of Javascript framework if it's latest version. For me it's applying upgrade to different versions of product just to match latest version of Javascript framework.
This is a great piece. Often, I get confused about what framework to jump on next.
Thank you. You are right. Learning database and API and security is more important than new frameworks. I hope others use this brilliant experience and doesn't waste time. Regards
My approach to this is to play "King of the hill". For a given problem, I have a tool. Unless what I proof-of-concept knocks it out, it stays in belt. That's why I moved from jQuery to angular.js to react in 2015 and still use it. Moved from custom webpack config to vite for spa and nextjs for full stack. Still use redux in spa, no mobex or saga. Vitest from jest. RTL from enzyme.
Although I try a lot of things, not many of them impressed me in the last 15 years my frontend career. Very few managed to replace my go to tools to become the next one. So, hype? Try it, learn from it, sometimes they teach you unique patterns to augment your toolset. If it's same grind, keep an eye on it for it's promises, otherwise forget it.
Currently I'm eyeing web-components to augment react, but it's still a challenge. I shall probably revisit after another couple of years...
Working in an enterprise, a tip: a company usually follows my strategy at a large scale. 10 years ago everyone in my company was using angularjs. Enter react, every single one adopted it. Although we are on different versions now, we are all on react. Unless vue, svelte or another shiny thing manage to outclass react, we probably won't switch. Does that mean we don't try other frameworks? No, we still do. There are some sporadic teams that use Angular, Jekyll, home grown frameworks, but mostly because either it's convenient, not maintained, or just want to try.
I'm sticking with react for now. It's not worth rewriting thousands of LOCs in vue or svelte just because it builds faster or runs faster or outputs smaller. If you know what you are doing, you won't see difference in any of these.
This happened a long time ago. It is measurable and quantifiable.
You are missing my point. But that's okay 😌
Hmm, I don't think so. You're clearly stating a premise that has already fulfilled, yet you claim to continue using React. You are therefore not upholding your own "King of the hill" approach: React has been dethroned long ago. You're not being consistent.
Now tell me: If this is not the point of your comment, which is it?
This is my point:
In other words, they are not that impressive just because of their performance numbers. There's is little to no impact in developer experience. There's even smaller impact in decision to switch from one to another.
Let's try this to get the point across to you:
jQuery -> angularjs = B
angularjs -> Angular = A+
angularjs -> React = A+
React, Angular -> Vue, Svelte, Solid = C
You are not gaining much that's worth the cost of conversion. In a few years, maybe. Not now.
If you are starting a new company and ask everyone to use svelte, yes, it's good to go. But try convincing 5000+ developers to switch their codebase to svelte without showing them the difference. That's my point.
Well, you may be getting your information from the incorrect sources. Have you seen the difference in performance? React is surpassed a lot. From where are you getting those grades? The difference is night and day.
Code reduction is super significant, too: 30%. Developer experience? Stack Overflow survey says Svelte is the best.
So with all this evidence, you gave the change a grade of C. This is why I don't get your point. I do understand your logic. Your logic is good. Your data input is completely lying to you, though. With the correct data, that C should have been A+++.
Again, missing my point. It's the effort. It's the time. It's that one selling point that's missing to get over the hump. I'm not saying they don't have better numbers. Just that the numbers and ecosystem not worthwhile to convert all the projects from react or angular. And the grade I have involves time + effort + return on investment + longevity of code. It's just not worth it.
Trust me when I say I'm tried of react. I'm not learning anything anymore from the frameworks. But neither am I learning anything new from svelte and vue. It's same grind in different format.
Performance alone won't make a difference in conversation.
If you know a tool that converts all the projects over night, let me know. I can sell everything else.
I have never missed your point. You did not say that "migrating easy" had such heavy weight in the calculation.
Anyway, here's your solution: Micro-frontends. If you use
single-spa(andvite-plugin-single-spaif you use Vite in your React project), you can convert your current React project to a root config project (the project that loads other MFE's). At this point, you are free: Start converting your UI away from React and into your new best friend of choice. Do this as fast or slow as you like, with big or small changes. You have total liberty.So there you go, the solution fell in your lap. Happy Getting-Rid-Of-React day.
I wonder if people really need to hear this message. Like isn't this the obvious argument? Obvious to the point of being uninteresting. If no company is switching tech stack based on trendiest why even write the article. There is a lot of good advice here adjacent to the topic of framework, but why the feeling that the frameworks are somehow the problem.
The reason I dislike this line of thinking is it is self fulfilling. If you never want change, you will never get any change. React is 12 years old, Vue 10, Svelte is 9, and Solid 7 years old at this point. They aren't new frameworks. If you feel you are still getting pulled into a hype cycle with tools pushing on a decade I don't know what to tell you.
But this fixation on holding the line sure slows progress. Most frameworks will turn into Solid over the next few years and the developer will be no wiser that they could have been doing this for 10 years at that time. The gap between jQuery and React was less than 7 years.
Not everything needs to be cutting edge. But things don't gain ecosystem or traction unless people try it. The fact things are approaching only syntax being different is a sign of how much stagnation has been happening. There is still more to advance here but people can't handle changes that are a decade in the making? It is ridiculous. Equally so to suggest this is a rinse repeat scenario. Each iteration is a marked improvement and never gets to where the past was.
When I look at what has happened with Qwik it is obvious how much the community has matured. People used to get excited about technology that could make a real difference. Now it's taking years to see the writing on the wall right in front of us.
This isn't about hype. It has been for 10 years atleast. Hype was switching to React when it had been around for less than 2 years. Not suggesting Svelte at 9 and Solid at 7 are new frameworks. Yes frameworks aren't everything. But there is only positives in pushing innovation. Natural factors will restrict movement anyway.
Everybody has a favourite framework, but in the end, the websites look similar and have the same basic stack (HTML, CSS, JavaScript). React is my preference, but I have no issue with other developers using a different framework so long as the work is done.
Multi-Page Applications > Single-Page Applications. Some frameworks support Progressive Web Apps, which download html/css and gives you a partially functional web app. Then the javascript trickles in
JavaScript should be optional for your users
PHP is a multi-page, no-JavaScript needed, web app creator. This is nothing new
We just realized single page applications are bad
Yes i had experience the same thing and wasted my time. Then realized that every framework will come and go but the main foundation html, css, js, ts will be the game changing even after a decade. So i need to invest my time learning these languages
My approach is to use minimum from the given framework. Implement what is possible in pure (vanilla) js independently from the fw. Wire them together within a fw using bare minimum features.
This immediatelly drops out any opinionated architectural dictatorship. So, Angular is out of the scope.
Then I simply check which syntax and philosophy is closer to the pure js without need to learn unique mindset of the publisher. So, React is out.
I dropped myself out 99% of globally available jobs at this point, I know.
What I identified as the closest to the pure js is Vue. I can use it without using all features of it. I can cherry pick what I really need from it. Most of my codes resides in independent js modules. I use Vue basically just to maintain the render lifecycle and bindings.
I don't use nuxt or pinia because those are also overkills.
So, I dropped out myself from 100% of globally available jobs.
Still happy, by the way ;)
Appreciate your points, but maybe it's not just hype, but natural evolution?
New design patterns are also created, some are so sound they guarantee higher quality, more robust code in general, so some frameworks may well adopt it.
The web platform and the TC39 also come up with new primitives that bring a lot of goodness.
Old frameworks are often unable to adopt these and will be left behind, leaving space to the next generation.
This happens in nature, as well. Do we have the power to counter all this? Should we really oppose innovation and stick with jQuery?
As long as you don't use React, I don't care what you use.
(Note: In the following, replace "English" with your native language.)
Once you step outside the corporate world, things get rather messy. There's a whole world of ad hoc programming where a framework makes little sense. Firstly because it's usually overkill for the kind of jobs that were common when JQuery was built - minor tweaks to web pages to give them some interactive features. And secondly because it's very hard for small companies to hang on to the kind of skill set required to maintain a project built using a complex framework. Once the skills have gone, the project is unmaintainable as it simply costs too much to regain them.
I'd be the first to admit my own programming skills are limited, even after doing 50 years of not much else. But I doubt I'm untypical (other than for that length of time). Even after so long I still can't think in computer code or understand a mathematical expression at a glance. Where I'm strongest is in using English to describe things. And with the rise of AI there will soon be little reason why I should need to translate my work into "code".
The single requisite for a computer program is that it must be unambiguous, so English isn't the ideal vehicle, but it's what most people use daily for all communication. When a human being has to translate clearly-expressed English into computer code, errors will always arise. AI can - or soon will - do better.
Natural language is object-oriented, and we use a huge built-in set of objects, each with its own properties and behaviours. A dog and a tree are very different but we have no trouble using them without confusion. We constantly invent new objects, such as "laser" or "defibrillator" and make them a seamless part of our vocabulary.
With care it's possible to use English - supplemented by a rich domain-specific vocabulary and a few pictures - to fully describe the huge majority of problems. And we're getting very close to the point where AI can take over from there. The key skill will be the ability to express a problem clearly in English, not to churn out computer code.
To round off, here are two guidelines for the future of programming:
1 If it can be expressed in English it should be.
2 If it's too complex to describe in English, it's probably too complex. Period.
"Great take on the JavaScript hype cycle! Constantly switching frameworks can be a huge time sink with little real gain. Instead of always chasing the latest trends, focusing on solid, scalable development practices is key.
If you're interested in a structured approach to web development and SEO, check out SonicMenu for tools and insights that help developers build efficiently without getting caught in endless rewrites."
**Effective Lottery Spell By Lord Meduza
The sole individual I'm aware of who can provide you with a winning lottery number is Lord Meduza. This man assisted me in finding the lucky number that led to my lottery win of $112 million dollars in Arizona through his powerful spell. For a transformative chance to gain wealth in life, contact him via Email: Lordmeduzatemple@hotmail.com
Call/WhatsApp: +1 807 907 2687
You can also search him on Face Book via: Lordmeduzatemple**
Give web assembly access to the dom, then we can ditch JavaScript and it’s constantly breaking framework all together!!
PHP backend and js frontend is classic and perfect. You handle things separately on the frontend and separately on the backend. Livewire has that and its enough for most intermediate-advanced webapps.
Golang is changing this dilemma.
How are Vuex and Pinia opinionated? Did you use Redux/Recoil?
Vue/Svelte keep things simple, unlike React/Angular
Forget frameworks. Use VanillaJS and focus on your product/app - not on the framework.
I have stepped off the hype train because there is lot of this to implement in application, instead of crafting the same thing in the another framework.
Another reflection on nothing...
Each framework has its own community, its own problems solutions and its own comfort bubble.
Such articles only encourage shit in the comments.
React, Svelte. Tomayto tomahto 🍅😊
Informative
design software that works, scales, and is easy to maintain—regardless of framework ❤️
Hay
Well said! Chasing every new framework often means spending more time relearning the same concepts instead of focusing on building great products.
Is this news? You’re in an echo chamber if you disagree with this post.
And yet AI can create everything you can imagine
So false. AI can write bits here and there. That's it. Rarely can an AI write decent code, much less at a large scale, and only GitHub Copilot seems kind-of consistent. Maybe we can see about this in a year. Right now, jobs are secured. At least for seniors.