To me, frameworks are all solutions to the wrong problem. As I see it, the great majority of web pages can be described in fairly plain English. OK, there are chunks of functionality like Google maps and weather widgets, but these are standard library components that are imported, not created by the main page code. The rest is just a set of boxes within boxes and the description is quite simple. It's HTML (or JSX) which is line for line equivalent to plain English commands.
So the problem isn't with structure, which is what frameworks deal with, but with language. It's simply that JavaScript isn't as good as English when it comes to describing what a web page looks like.
JavaScript is a complex system programming language, but everywhere people are falling over themselves to add frameworks that are at least as complex as JavaScript itself. When did adding complexity become the solution to complexity? Where does it stop?
Programming a web page entirely in JavaScript is like playing golf with a single club. So let's have two clubs. Keep JS - with React and the rest if you choose - for the complex components that once written will never change, and do the UI and the business logic with something simpler.
Over the years a few computer languages have been created that look more like English than any of the mainstream programming languages. I cite HyperTalk, which eventually became AppleScript, and of course SQL. These languages start by asking what domain they are addressing; they don't aim to be totally general-purpose. Instead, they comprise commands specifically designed for the job in hand, making them easy to read and to write. Programs get shorter, leaving fewer places for bugs to hide, and long-term maintenance can be done by any intelligent person.
I write web apps using a high-level scripting language of my own devising, written in JavaScript and inspired by HyperTalk. The compiler and runtime (about 250kB) run in the browser and the scripts are raw text. If a complex item like a GMap is needed I code a 'plugin' that extends the language syntax to deal with the new API, so the main scripts never have a line of JS in them. My pages load quickly and because the system implements load-on-demand there's no limit to the size of app it can handle. And when other programmers see the code they can tell at a glance what it's doing, so who cares if it's a non-standard language?
Keep It Simple, Stupid. Then it really can get better.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Getting better? Getting more complex, certainly.
To me, frameworks are all solutions to the wrong problem. As I see it, the great majority of web pages can be described in fairly plain English. OK, there are chunks of functionality like Google maps and weather widgets, but these are standard library components that are imported, not created by the main page code. The rest is just a set of boxes within boxes and the description is quite simple. It's HTML (or JSX) which is line for line equivalent to plain English commands.
So the problem isn't with structure, which is what frameworks deal with, but with language. It's simply that JavaScript isn't as good as English when it comes to describing what a web page looks like.
JavaScript is a complex system programming language, but everywhere people are falling over themselves to add frameworks that are at least as complex as JavaScript itself. When did adding complexity become the solution to complexity? Where does it stop?
Programming a web page entirely in JavaScript is like playing golf with a single club. So let's have two clubs. Keep JS - with React and the rest if you choose - for the complex components that once written will never change, and do the UI and the business logic with something simpler.
Over the years a few computer languages have been created that look more like English than any of the mainstream programming languages. I cite HyperTalk, which eventually became AppleScript, and of course SQL. These languages start by asking what domain they are addressing; they don't aim to be totally general-purpose. Instead, they comprise commands specifically designed for the job in hand, making them easy to read and to write. Programs get shorter, leaving fewer places for bugs to hide, and long-term maintenance can be done by any intelligent person.
I write web apps using a high-level scripting language of my own devising, written in JavaScript and inspired by HyperTalk. The compiler and runtime (about 250kB) run in the browser and the scripts are raw text. If a complex item like a GMap is needed I code a 'plugin' that extends the language syntax to deal with the new API, so the main scripts never have a line of JS in them. My pages load quickly and because the system implements load-on-demand there's no limit to the size of app it can handle. And when other programmers see the code they can tell at a glance what it's doing, so who cares if it's a non-standard language?
Keep It Simple, Stupid. Then it really can get better.