"Type unsafe is not the same as not needing to declare a type." - yes, good point. Java, e.g., is needlessly verbose in that regard. Scala fixes that.
"functions usually still need to declare the returning type" - that's the real need. I have not coded in Javascript in a long time, so I don't remember the rules anymore. I know that Python and Ruby (and Go) are horrible in this regard, mainly in the instance of function (method) return types, having spent many hours reverse engineering people's code just to figure out what type is being returned and set to some variable.
"naming the variables properly" - yes, and unfortunately, programmer's follow the "language's culture" instead of using best practices; e.g., the Go community has a culture of very short variable names: try searching a source code repo for instances of a variable called "name", or "cr" - you'll find hundreds of matches, and two of them will be what you are looking for!
But the IDE cannot always know - the right hand side of the assignment often is a function (with an unspecified return type). I cannot tell you the angst I have had reverse engineering other people's code in Python and Ruby, costing me hours of wasted time and huge frustration, having to go hunting for a function to see what kind of object it creates, only to find that it calls another function, which returns some unknown object type, and so on. The same is true of Go, which doesn't really have types - hours of time trying to determine things that would take seconds in Kotlin or Java - and all for the sake of saving a programmer two seconds to specify a variable's type. I know that some people swear by type-unsafe languages, but I feel that they are looking only at the time it takes _them_ to code - not what is best for a team that has to maintain code over time. If you have to read other people's code, type-unsafe languages are a nightmare.
That's why Microsoft created Typescript - to fix Javascript. Javascript is great for hacking together something that no one else will use, but for use in a team, it fosters the creation of mountains of muck that no one can make sense of. The same is true of Python and Ruby. Sure, you don't have to worry about declaring types, but you pay for that big time when you try to figure out the code months later.
To visualize the colonization of Mars requires some imagination - the ability to think beyond current approaches.
I recall circa 1998 telling someone that eventually paper books would be mostly replaced by electronic sources, and the response was, "That will never happen - people won't want to read a book on a computer screen".
The person who said that was not able to imagine beyond the bulky and low resolution CRTs of the day.
To imagine the colonization of Mars, one needs to consider that (1) getting there and back might get a-lot easier and quicker, given that fusion propulsion is actively under development, (2) people who live there for years, on assignment, might well want to have their families with them, and (3) Mars is a potential base for mining asteroids, which is a very real prospect (http://www.asterank.com/).
Not everyone is able to imagine these things. Regarding Bill Nye, just because he likes science does not mean that he is someone with imagination - in fact, my impression of his is that he is something of a luddite.
Well, I did - I had that very thought! My book High-Assurance Design is all patterns and principles - all original content. I was first to tabulate a set of secure design principles before NIST did. But it sold really poorly. In contrast, my Java books with code in them sold really well.
Perhaps it was the topic. I think that programmers are generally not interested in security or reliability.
The book I am most proud of was a commercial failure, even though it got great reviews and IMO had better content than competing books. It was High-Assurance Design: https://www.amazon.com/High-As... . All these are out of print although you can still get them due to on-demand printing. The High-Assurance Design I collaborated with Peter Neumann, an author of Multics and the author of the ACM Communications Risk column. I learned from that experience that programmers have almost zero interest in building reliable and secure systems - they are interested in "how to" books that enable them to hack something together as quickly as possible. My first book was that kind of book; but High-Assurance Design was a thoughtful book, full of design patterns but no code and no APIs, and people were not interested in that.
Sorry angel'o'sphere. Your post started with something about a rant. I might have misunderstood the intent. So many posters on slashdot are immature, rude and nasty - like they surely would not be if they were talking to someone face to face.
Let's not debate our quals please. I am sure you are competent - most people here are. Please know that I am as well. I don't just coach - I code - have been for 40 years, many languages, written compilers, web apps, a relativistic 3D simulator, deep learning apps, container image scanner and other tools. Am current - latest tools, many languages. Know devops well enough that I am generally ahead of the teams that I coach, even in forward organizations.
About the qual of a book: you are right, it does not prove that one has practical experience, and I have read books that proved to me that the author did not know what they were talking about. But writing a technical book is an immense undertaking. Immense. (My books average ~800 pages each of all original content, with design patterns and code.) And if you _do_ know what you are talking about, writing a book forces you to organize everything you know, to think it through, to connect the dots, for refactor your knowledge and identify patterns and practices, to reflect on the causes of the causes. Each time I have written a book, when I was done, I felt like I understood the subject much better than before I started the book. A book is significant - or at least, it can be.
LOL - I have written books and blogs about these things; my own company (I was CTO) adopted XP in 2000. I have been an Agile/DevOps coach for a decade. I am sure I know more about it than you do;-)
But I agree with your other points.
You would do well to avoid making a personal attack against someone who you don't know. It shows immaturity.
They are different schools of thought, with different origins, and different communities. That said, there is overlap, and today many "Agile coaches" are intimately familiar with all three schools of thought, although the reality is that most Agile coaches know very little about DevOps.
In fact, DevOps arose partly out of the failure of the Agile community to address the things that DevOps addresses. The Agile community is largely controlled by the Scrum community, which is highly dysfunctional, because it is driven by a set of thought leaders who have turned it into a certification mill. It is their moneymaker, and they have proven to be rigid in their thinking (not very Agile!) and treat Scrum like an ideology. The Scrum community has done enormous harm to the Agile movement, which was founded on very strong principles (the Agile Manifesto), but which ran aground in the mid-2000s because of its inflexibility and dogmatic extremism. The ideas are not the problem - the "thought leaders" were the problem.
DevOps arose out of a need by big companies to deliver Internet scale things fast, while managing their risk. This later came to be known as DevOps. They did it by looking at the whole delivery process, end-to-end, and by creating enough automation and tests so that if something passed all the tests, it was good enough to release. Automation of deployment was an essential part of that, because end-to-end test require continuous delivery - you must deploy to a test env to run such tests. If you want to run those tests continually, you must deploy continually to the test env - hence the need for automated deployment. And of course A/B, canary and scaling deployments are a natural evolution of that. All this happened inside the Googles, Facebooks, Netflixes, and Amazons, and later came to be called "DevOps".
The Agile community was caught with its pants down, because it should have been talking about these things, but wasn't - it was stuck in the same old conversations over and over again - about how to have a good retrospective, how to engage the product owner, and so on - and completely ignored the technical side of things. This was regrettable because some of the early advocate thought leaders, such as Kent Beck and Ron Jeffries, were ardent advocates of automation and technical practices, but the Scrum community co-opted the whole thing and drove it into a ditch. Eventually, the Scrum community realized they were being overshadowed by DevOps, and they started to try to get back in the game by saying that one should use "Scrum plus extreme programming's technical practices". That's kind of weird because extreme programming also has ceremonies very much like Scrum, so if one uses XP, one doesn't need Scrum at all.
Now today the Agile community is trying to take itself back from Scrum, and get on board with DevOps.
Lean IT is another similar story. It because clear that the Agile community was not addressing how to "scale" Agile. The Agile community was saying useless things like "don't do Agile, be Agile" - yet offered no insights as to how to take action on that. So people looked to "Lean" and found some answers there.
And then there are things like Less and SAFe, which were attempts by some individuals to answer the question of how to scale Agile. The Scrum community was immensely derisive of SAFe - an indication of how insular and dogmatic it is, because they felt threatened by it - and indeed today SAFe is immensely useful in organizations that build big things - large programs needs actionable models for how to apply agile ideas at scale. Yet SAFe had its own gaps, namely it said little about the technical practices, but unlike the Scrum community, the thought leaders of SAFe embrace other ideas and have added DevOps to their mix of recommended things to consider. SAFe is not a methodology by the way - it is just a model for how to think about scaling issues.
So to bring all this "under one umbrella", one must consider that for those who know these schools of thought, they
One buys "Internet service" and "cable TV service", and perhaps other services. While TV service is perhaps an information service, Internet service is a telecommunications service - TCP/IP. So the "broadband companies" are providing both. Seems like their "Internet service" business is a telecommunications service.
The libraries grow, and libraries are statically linked. Further, languages with dynamic loading features cannot be analyzed at link time to include only what is needed, so everything must be included.
Back when people wrote in C, the C linker would strip out all the functions that were not called, so the resulting executable was tiny. Today, each entire project and each project that it uses must be included. E.g., a small Java app often includes hundreds of jar files from other projects. Same for Javascript. And the foundation classes - e.g., the Java runtime, or Windows.Net - those are all included which makes the app really huge.
To make small apps, one has to give up dynamic loading of classes, or at least have a declarative way to specify which classes should be included in a distribution package. Either that, or pull binaries as they are needed from their source (to do that safely, signatures would have to be checked at load time, which might be too slow).
Also, the size of the state is an important consideration. What works for a small European country will not necessarily work for the US, which is a hugely heterogeneous country that is better compared to the European Union than an individual European country. Further, there are models other than capitalism and socialism, e.g., a free market that avoids capital by using a different form of investment, whereby co-ops partner to do larger things. In a co-op, everyone is an owner - there is no separation between the owner and the worker. That can be achieved through a legal construct that replaces the corporation construct.
It will work fine for commodity jobs; but if someone is out of the ordinary - as most truly great people are - they will get screened by the AI system, which, after all, is really just a kind of filter. It takes true understanding to assess an extraordinary person, and they will get filtered out by the process. See my article on how we are being screened already: https://www.linkedin.com/pulse...
The comments here are mostly in two groups: (1) those who feel that programming is fundamentally simple and anyone should be able to do it, given simpler tools, and (2) those who feel it is fundamentally difficult and not everyone can do it.
Those in group (1) point to languages like Python and Basic as proof that anyone can program. However, there is an important issue that is missed in most of the comments: How productive a language is for the original programmer, versus how easy it is for someone else (on your team, or another team months later) to figure out your code and be able to modify it safely. These are very different things.
For an organization with lots of teams, it is very difficult to create maintainable, shareable code. It really takes a professional. I have been in many organizations that had to deal with "the end user computing problem". These organizations undertook large efforts to get code out of the hands of users and into the hands of professionals where it could be maintained properly.
Should it be so hard to code? No, but we are kind of stuck. The OSes and frameworks keep getting more complicated; and worse, the fundamental technology choices that underpin most things were deeply flawed choices - we are stuck with approaches that make things brittle and unnecessarily complicated. Thus, I see little hope of non-professionals being able to write code in the context of those flawed frameworks and technologies.
The original usage was someone who "hacked" at something, instead of crafting it. It was pejorative. If someone was a "hack", they worked without thinking and didn't really know what they were doing, and a "hacker" was the same thing. Then TV shows and news reports came out glorifying this, and the meaning became congratulatory.
1. That programming is not "coding". Programming should include designing - otherwise, it is "hacking" (pejorative).
2. Teach about race conditions, aka "TOCTOU errors". This problem is the most prevalent in real time systems - such as phone software, Web software, and pretty much everything we use today.
3. The value of type safety when refactoring.
4. Basic concepts such as information hiding, decomposition, interfaces, and that the more shared an interface is, the more stable it should be.
5. Some machine learning basics.
6. The value of a formal syntax, and the maintainability horrors of semantic free syntaxes such as JSON.
The average programmer is woefully untrained in basic principles related to reliability and security.
The tools available to programmers are woefully inadequate to expect that the average programmer can produce reliable and secure applications.
Organizations that procure applications are woefully unaware of this state of affairs, and take far too much for granted with regard to security and reliability.
Best to tell him that all we have is theories - but that we don't really know. For example, there have been many proposed alternatives to General Relativity. The most intriguing IMO is Erik Verlinde's. Note that the predictions of GR have been verified within long ranges and large masses (but not short ranges and small masses), but the interpretation of curved spacetime is not proven - it is just a mathematical construct that fits the observations. Also, Special Relativity postulates some things that are not proven - only the effects are proven. Even quantum mechanics postulates a foundational equation ("operator correspondence") that is just a guess that works. Bottom line: we don't really know. I strongly recommend the book Doubt and Certainty, by George Sudarshan and Tony Rothman - in that book you will see how little we really know. Tell you son that we have guesses that work, but don't know how the Universe is truly constructed.
Well he is referring to the whole Web ecosystem, which Javascript is a big part of, and he makes many points about web pages that try to behave like apps. Indeed, Javascript is not the only problem - HTTP is a horribly flawed system of headers and encodings rules that application programmers should not have to get involved with.
Yes, having a whole page reload from each click is very inefficient. Does HTML5 provide a way to avoid reloading a whole page, but without using Javascript?
Yes, malware is a terrible problem today: if someone wants to hack an organization, pretty much the most guaranteed path to success is to use Web based attacks, by hacking sites that staff of the organization visit. Read this article - it is very worth your time, I promise: https://blog.plan99.net/its-ti.... If you are impatient, skip down to the section "Web apps are impossible to secure".
Yes, I have wondered if OSes are going to move to containerization for apps, which would provide that level of protection for the average user who does not know how to run a browser in a VM. There is a product for Windows called Bromium that uses virtualization to sandbox web pages. I think some of the browsers do that to but I don't think they use virtualization - not sure. There is an interesting blog post about how hard it is to write secure web apps: https://blog.plan99.net/its-ti...
"tin foil hat" - ROTFLOL. Good to know about being able to provide for non-JS folks - thanks for the info - I am a server side guy so I don't know the Web frameworks like react except at a basic level. About the "tin foil hat" thing though - most people don't realize how vulnerable Javascript makes them. Those who do realize it are not "tin foil hats" - they are prudent. Here's a good article on this: https://blog.plan99.net/its-ti...
Slashdot Mirror
"Type unsafe is not the same as not needing to declare a type." - yes, good point. Java, e.g., is needlessly verbose in that regard. Scala fixes that.
"functions usually still need to declare the returning type" - that's the real need. I have not coded in Javascript in a long time, so I don't remember the rules anymore. I know that Python and Ruby (and Go) are horrible in this regard, mainly in the instance of function (method) return types, having spent many hours reverse engineering people's code just to figure out what type is being returned and set to some variable.
"naming the variables properly" - yes, and unfortunately, programmer's follow the "language's culture" instead of using best practices; e.g., the Go community has a culture of very short variable names: try searching a source code repo for instances of a variable called "name", or "cr" - you'll find hundreds of matches, and two of them will be what you are looking for!
But the IDE cannot always know - the right hand side of the assignment often is a function (with an unspecified return type). I cannot tell you the angst I have had reverse engineering other people's code in Python and Ruby, costing me hours of wasted time and huge frustration, having to go hunting for a function to see what kind of object it creates, only to find that it calls another function, which returns some unknown object type, and so on. The same is true of Go, which doesn't really have types - hours of time trying to determine things that would take seconds in Kotlin or Java - and all for the sake of saving a programmer two seconds to specify a variable's type. I know that some people swear by type-unsafe languages, but I feel that they are looking only at the time it takes _them_ to code - not what is best for a team that has to maintain code over time. If you have to read other people's code, type-unsafe languages are a nightmare.
How so? What runtime issues have you seen?
That's why Microsoft created Typescript - to fix Javascript. Javascript is great for hacking together something that no one else will use, but for use in a team, it fosters the creation of mountains of muck that no one can make sense of. The same is true of Python and Ruby. Sure, you don't have to worry about declaring types, but you pay for that big time when you try to figure out the code months later.
To visualize the colonization of Mars requires some imagination - the ability to think beyond current approaches.
I recall circa 1998 telling someone that eventually paper books would be mostly replaced by electronic sources, and the response was, "That will never happen - people won't want to read a book on a computer screen".
The person who said that was not able to imagine beyond the bulky and low resolution CRTs of the day.
To imagine the colonization of Mars, one needs to consider that (1) getting there and back might get a-lot easier and quicker, given that fusion propulsion is actively under development, (2) people who live there for years, on assignment, might well want to have their families with them, and (3) Mars is a potential base for mining asteroids, which is a very real prospect (http://www.asterank.com/).
Not everyone is able to imagine these things. Regarding Bill Nye, just because he likes science does not mean that he is someone with imagination - in fact, my impression of his is that he is something of a luddite.
Well, I did - I had that very thought! My book High-Assurance Design is all patterns and principles - all original content. I was first to tabulate a set of secure design principles before NIST did. But it sold really poorly. In contrast, my Java books with code in them sold really well. Perhaps it was the topic. I think that programmers are generally not interested in security or reliability.
Today it is hard to get a technical book published because the docs for everything is online and free.
I wrote the enterprise Java book for Prentice Hall and Sun Microsystems. The first edition did spectacularly well: https://www.amazon.com/Advance... . The second edition not as well: https://www.pearson.com/us/hig...
The book I am most proud of was a commercial failure, even though it got great reviews and IMO had better content than competing books. It was High-Assurance Design: https://www.amazon.com/High-As... . All these are out of print although you can still get them due to on-demand printing. The High-Assurance Design I collaborated with Peter Neumann, an author of Multics and the author of the ACM Communications Risk column. I learned from that experience that programmers have almost zero interest in building reliable and secure systems - they are interested in "how to" books that enable them to hack something together as quickly as possible. My first book was that kind of book; but High-Assurance Design was a thoughtful book, full of design patterns but no code and no APIs, and people were not interested in that.
Sorry angel'o'sphere. Your post started with something about a rant. I might have misunderstood the intent. So many posters on slashdot are immature, rude and nasty - like they surely would not be if they were talking to someone face to face.
Let's not debate our quals please. I am sure you are competent - most people here are. Please know that I am as well. I don't just coach - I code - have been for 40 years, many languages, written compilers, web apps, a relativistic 3D simulator, deep learning apps, container image scanner and other tools. Am current - latest tools, many languages. Know devops well enough that I am generally ahead of the teams that I coach, even in forward organizations.
About the qual of a book: you are right, it does not prove that one has practical experience, and I have read books that proved to me that the author did not know what they were talking about. But writing a technical book is an immense undertaking. Immense. (My books average ~800 pages each of all original content, with design patterns and code.) And if you _do_ know what you are talking about, writing a book forces you to organize everything you know, to think it through, to connect the dots, for refactor your knowledge and identify patterns and practices, to reflect on the causes of the causes. Each time I have written a book, when I was done, I felt like I understood the subject much better than before I started the book. A book is significant - or at least, it can be.
LOL - I have written books and blogs about these things; my own company (I was CTO) adopted XP in 2000. I have been an Agile/DevOps coach for a decade. I am sure I know more about it than you do ;-)
But I agree with your other points.
You would do well to avoid making a personal attack against someone who you don't know. It shows immaturity.
They are different schools of thought, with different origins, and different communities. That said, there is overlap, and today many "Agile coaches" are intimately familiar with all three schools of thought, although the reality is that most Agile coaches know very little about DevOps.
In fact, DevOps arose partly out of the failure of the Agile community to address the things that DevOps addresses. The Agile community is largely controlled by the Scrum community, which is highly dysfunctional, because it is driven by a set of thought leaders who have turned it into a certification mill. It is their moneymaker, and they have proven to be rigid in their thinking (not very Agile!) and treat Scrum like an ideology. The Scrum community has done enormous harm to the Agile movement, which was founded on very strong principles (the Agile Manifesto), but which ran aground in the mid-2000s because of its inflexibility and dogmatic extremism. The ideas are not the problem - the "thought leaders" were the problem.
DevOps arose out of a need by big companies to deliver Internet scale things fast, while managing their risk. This later came to be known as DevOps. They did it by looking at the whole delivery process, end-to-end, and by creating enough automation and tests so that if something passed all the tests, it was good enough to release. Automation of deployment was an essential part of that, because end-to-end test require continuous delivery - you must deploy to a test env to run such tests. If you want to run those tests continually, you must deploy continually to the test env - hence the need for automated deployment. And of course A/B, canary and scaling deployments are a natural evolution of that. All this happened inside the Googles, Facebooks, Netflixes, and Amazons, and later came to be called "DevOps".
The Agile community was caught with its pants down, because it should have been talking about these things, but wasn't - it was stuck in the same old conversations over and over again - about how to have a good retrospective, how to engage the product owner, and so on - and completely ignored the technical side of things. This was regrettable because some of the early advocate thought leaders, such as Kent Beck and Ron Jeffries, were ardent advocates of automation and technical practices, but the Scrum community co-opted the whole thing and drove it into a ditch. Eventually, the Scrum community realized they were being overshadowed by DevOps, and they started to try to get back in the game by saying that one should use "Scrum plus extreme programming's technical practices". That's kind of weird because extreme programming also has ceremonies very much like Scrum, so if one uses XP, one doesn't need Scrum at all.
Now today the Agile community is trying to take itself back from Scrum, and get on board with DevOps.
Lean IT is another similar story. It because clear that the Agile community was not addressing how to "scale" Agile. The Agile community was saying useless things like "don't do Agile, be Agile" - yet offered no insights as to how to take action on that. So people looked to "Lean" and found some answers there.
And then there are things like Less and SAFe, which were attempts by some individuals to answer the question of how to scale Agile. The Scrum community was immensely derisive of SAFe - an indication of how insular and dogmatic it is, because they felt threatened by it - and indeed today SAFe is immensely useful in organizations that build big things - large programs needs actionable models for how to apply agile ideas at scale. Yet SAFe had its own gaps, namely it said little about the technical practices, but unlike the Scrum community, the thought leaders of SAFe embrace other ideas and have added DevOps to their mix of recommended things to consider. SAFe is not a methodology by the way - it is just a model for how to think about scaling issues.
So to bring all this "under one umbrella", one must consider that for those who know these schools of thought, they
One buys "Internet service" and "cable TV service", and perhaps other services. While TV service is perhaps an information service, Internet service is a telecommunications service - TCP/IP. So the "broadband companies" are providing both. Seems like their "Internet service" business is a telecommunications service.
What's _your_ test coverage?
The libraries grow, and libraries are statically linked. Further, languages with dynamic loading features cannot be analyzed at link time to include only what is needed, so everything must be included.
Back when people wrote in C, the C linker would strip out all the functions that were not called, so the resulting executable was tiny. Today, each entire project and each project that it uses must be included. E.g., a small Java app often includes hundreds of jar files from other projects. Same for Javascript. And the foundation classes - e.g., the Java runtime, or Windows .Net - those are all included which makes the app really huge.
To make small apps, one has to give up dynamic loading of classes, or at least have a declarative way to specify which classes should be included in a distribution package. Either that, or pull binaries as they are needed from their source (to do that safely, signatures would have to be checked at load time, which might be too slow).
Also, the size of the state is an important consideration. What works for a small European country will not necessarily work for the US, which is a hugely heterogeneous country that is better compared to the European Union than an individual European country. Further, there are models other than capitalism and socialism, e.g., a free market that avoids capital by using a different form of investment, whereby co-ops partner to do larger things. In a co-op, everyone is an owner - there is no separation between the owner and the worker. That can be achieved through a legal construct that replaces the corporation construct.
It will work fine for commodity jobs; but if someone is out of the ordinary - as most truly great people are - they will get screened by the AI system, which, after all, is really just a kind of filter. It takes true understanding to assess an extraordinary person, and they will get filtered out by the process. See my article on how we are being screened already: https://www.linkedin.com/pulse...
The comments here are mostly in two groups: (1) those who feel that programming is fundamentally simple and anyone should be able to do it, given simpler tools, and (2) those who feel it is fundamentally difficult and not everyone can do it.
Those in group (1) point to languages like Python and Basic as proof that anyone can program. However, there is an important issue that is missed in most of the comments: How productive a language is for the original programmer, versus how easy it is for someone else (on your team, or another team months later) to figure out your code and be able to modify it safely. These are very different things.
For an organization with lots of teams, it is very difficult to create maintainable, shareable code. It really takes a professional. I have been in many organizations that had to deal with "the end user computing problem". These organizations undertook large efforts to get code out of the hands of users and into the hands of professionals where it could be maintained properly.
Should it be so hard to code? No, but we are kind of stuck. The OSes and frameworks keep getting more complicated; and worse, the fundamental technology choices that underpin most things were deeply flawed choices - we are stuck with approaches that make things brittle and unnecessarily complicated. Thus, I see little hope of non-professionals being able to write code in the context of those flawed frameworks and technologies.
Yes, exactly - to "hack" at something, until it works, rather than crafting it carefully. It implies incompetence.
The original usage was someone who "hacked" at something, instead of crafting it. It was pejorative. If someone was a "hack", they worked without thinking and didn't really know what they were doing, and a "hacker" was the same thing. Then TV shows and news reports came out glorifying this, and the meaning became congratulatory.
Best to tell him that all we have is theories - but that we don't really know. For example, there have been many proposed alternatives to General Relativity. The most intriguing IMO is Erik Verlinde's. Note that the predictions of GR have been verified within long ranges and large masses (but not short ranges and small masses), but the interpretation of curved spacetime is not proven - it is just a mathematical construct that fits the observations. Also, Special Relativity postulates some things that are not proven - only the effects are proven. Even quantum mechanics postulates a foundational equation ("operator correspondence") that is just a guess that works. Bottom line: we don't really know. I strongly recommend the book Doubt and Certainty, by George Sudarshan and Tony Rothman - in that book you will see how little we really know. Tell you son that we have guesses that work, but don't know how the Universe is truly constructed.
Well he is referring to the whole Web ecosystem, which Javascript is a big part of, and he makes many points about web pages that try to behave like apps. Indeed, Javascript is not the only problem - HTTP is a horribly flawed system of headers and encodings rules that application programmers should not have to get involved with.
Yes, having a whole page reload from each click is very inefficient. Does HTML5 provide a way to avoid reloading a whole page, but without using Javascript?
Yes, malware is a terrible problem today: if someone wants to hack an organization, pretty much the most guaranteed path to success is to use Web based attacks, by hacking sites that staff of the organization visit. Read this article - it is very worth your time, I promise: https://blog.plan99.net/its-ti.... If you are impatient, skip down to the section "Web apps are impossible to secure".
Yes, I have wondered if OSes are going to move to containerization for apps, which would provide that level of protection for the average user who does not know how to run a browser in a VM. There is a product for Windows called Bromium that uses virtualization to sandbox web pages. I think some of the browsers do that to but I don't think they use virtualization - not sure. There is an interesting blog post about how hard it is to write secure web apps: https://blog.plan99.net/its-ti...
"tin foil hat" - ROTFLOL. Good to know about being able to provide for non-JS folks - thanks for the info - I am a server side guy so I don't know the Web frameworks like react except at a basic level. About the "tin foil hat" thing though - most people don't realize how vulnerable Javascript makes them. Those who do realize it are not "tin foil hats" - they are prudent. Here's a good article on this: https://blog.plan99.net/its-ti...