JavaScript Slows Progress, Should be Retired, Argues JSON Creator (devclass.com) 220
JavaScript, the world's most popular programming language according to most surveys, has become a barrier to progress, according to Douglas Crockford, creator of the JSON (JavaScript Object Notation) specification used everywhere for serializing data in web applications.
Crockford made this assertion in an interview last month:
"The best thing we can do today to JavaScript is to retire it. Twenty years ago, I was one of the few advocates for JavaScript. Its cobbling together of nested functions and dynamic objects was brilliant. I spent a decade trying to correct its flaws. I had a minor success with ES5. But since then, there has been strong interest in further bloating the language instead of making it better. So JavaScript, like the other dinosaur languages, has become a barrier to progress. We should be focused on the next language, which should look more like E than like JavaScript."
According to a StackOverflow survey earlier this year, JavaScript is used by over 65% of developers, way ahead of second placed Python at 48 percent (ignoring HTML, CSS and SQL which are not general purpose languages).
Crockford also acknowledged there's be two difficulties in replacing browser-based JavaScript, according to the article. "First, we don't have the next language yet. It needs to be a minimal capability-based actor language that is designed specifically for secure distributed programming. Nothing less should be considered.
"Second, we need all of the browser makers to adopt it and to simultaneously replace the DOM with a well designed interface. Good luck with that."
Crockford made this assertion in an interview last month:
"The best thing we can do today to JavaScript is to retire it. Twenty years ago, I was one of the few advocates for JavaScript. Its cobbling together of nested functions and dynamic objects was brilliant. I spent a decade trying to correct its flaws. I had a minor success with ES5. But since then, there has been strong interest in further bloating the language instead of making it better. So JavaScript, like the other dinosaur languages, has become a barrier to progress. We should be focused on the next language, which should look more like E than like JavaScript."
According to a StackOverflow survey earlier this year, JavaScript is used by over 65% of developers, way ahead of second placed Python at 48 percent (ignoring HTML, CSS and SQL which are not general purpose languages).
Crockford also acknowledged there's be two difficulties in replacing browser-based JavaScript, according to the article. "First, we don't have the next language yet. It needs to be a minimal capability-based actor language that is designed specifically for secure distributed programming. Nothing less should be considered.
"Second, we need all of the browser makers to adopt it and to simultaneously replace the DOM with a well designed interface. Good luck with that."
I was going to write a comment but... (Score:5, Funny)
"Good luck with that" says it all.
Re: (Score:2, Redundant)
He literally says the same thing, quote:
"Second, we need all of the browser makers to adopt it and to simultaneously replace the DOM with a well designed interface. Good luck with that."
Re: (Score:2)
Re: I was going to write a comment but... (Score:3)
WHOOSH!
Re: (Score:2)
Correct lol
Re: (Score:3)
Do we get to rewrite all the websites out there, too?
Cuz that sounds like it'll be super fun and something everyone will be happy to do.
Re: (Score:2)
It's almost certain you'll be rewriting your websites again soon anyway. The tools we have now (for frontend) are not stable.
Re: (Score:3)
I'm almost wrapped up with a project of updating some company internal web pages and programs. They were originally perl (who knows what before that) and had been converted into PHP3 in the late 1990s, back when the php file extension was literally "php3". There had been very, very minor updates over the years (e.g., mysql_ -> mysqli_, other small PHP version incompatibilities), but these things have kept running largely untouched. The javascript I think was literally entirely untouched since about 20 ye
Re: (Score:3)
In some cases, re-writing would be a HUGE improvement. In the summary he says "We should be focused on the next language, which should look more like E than like JavaScript." Then the summary gives a link to the E rights website. [erights.org]
Holy Batman! The 1990s called and want their site design back. Literally. If you look at the source of the page it says the last modification date is Nov 1998.
If Douglas Crockford wants everyone to transition off Javascript, he should suggest something that is younger than Java
Re: (Score:3)
Don't worry. Once a new language is in place they will still support backwards compatibility with JavaScript in all major browsers for the next 50 years. Today's JavaScript developers will be the Cobol programmers of the future.
Re: (Score:3)
I don't think he's saying that. He wants to introduce a replacement for Javascript, get all the browsers to support it, and encourage programmers to start using it. That doesn't mean the browsers will drop support for Javascript and break existing websites. Same way they can still render HTML 1.0, even though web development moved on long ago.
Re:I was going to write a comment but... (Score:5, Interesting)
Obligatory: https://xkcd.com/927
There is nothing wrong with JavaScript. Google (through chrome) will end up ruining it. Which is why Webkit and Firefox need to resist calls from Google to depreciate JavaScript features, or Javascript itself. The problem itself is "the web browser" itself. There is no longer a "web" underneath, just a bunch of centralized services with their own proprietary JavaScript libraries.
So let's start with the reason why. "something better" . There is nothing "better", what has been largely proposed is compiling things to WASM, which is a massive mistake. If I had the reins of the internet, WASM would be on the top of the list of things to get nuked. Why would anyone be so stupid to try and inefficiently cross-compile something into a pseudo-assembly language that is hamstrung by JavaScript itself. That is so utterly stupid.
What we should have been doing the entire time, would have been to migrate Flash and "Java" itself into native browser API's. That didn't happen. Instead we ripped it out. So now Flash has been replaced by "the canvas tag", by which you now need a 300MB browser just to play a game written in JavaScript that uses nothing but the Canvas tag. THAT IS STUPID. The Canvas tag itself is stupid. We had SVG, and then decided to re-invent it again.
Websockets instead of raw UDP? Wow look at that entire overhead of serializing and deserializing things into JSON, including things like sounds and images. Massive overhead.
Like don't get me wrong, the problem isn't JavaScript, the problem is "the web browser". If we want to re-invent a decentralized web, we need to start from the top by solving the problem of "landlording" domains and services (like video.) We need to rip those back away from centralized services, and that will only happen by going back to what existed before the web. Remember Gopher? That was the alternative to "the web"
Blame the University of Minnesota for destroying gopher and leading to everyone throwing their eggs into the http (web) bucket. If we need a better "programming language" than Javascript, then go back to Gopher and create one for it.
Re: (Score:3)
This Toggl Comic is also applicable:
https://toggl.com/blog/world-c... [toggl.com]
Re: (Score:2)
Re: (Score:2)
I would say that both are true. The "web" in general and web browsers need to be re-invented.
The web browser has become the operating system.
But also, javascript, as a language, is a mess. From the non-parallel async functions, to us still using xhr to make network calls, to the lack of a deep copy for nested objects/arrays
All of those can be fixed without throwing away JavaScript. One round of browser updates and the whole world can have a new network call and a deep copy.
JavaScript is perfectly good for what most web pages need. If you're trying to rewrite Microsoft Office and Autocad in a browser? You have other languages that compile down to JavaScript.
Or... just don't bother. Native apps still exist.
Re: (Score:3)
You have other languages that compile down to JavaScript.
Plenty of languages also compile to WebAssembly, including C++, Rust, Golang, and many more.
Re: (Score:3)
Best troll I've seen in ages. Bravo.
Re: (Score:3)
I thought it was GPT at first. Then I didn't think so, and then I thought so again. Now I'm not sure.
Re: I was going to write a comment but... (Score:2)
The first thimg that should be imposed would be a total lock on cross-site data exchange/code execution in the browsers.
The mess we have today is caused by a lot of cross-site dependencies.
Also drop any copyright protection on script language code.
One additional concern is that since javascript runs in the clients it's a power efficiency concern too. Not much for a single client, but when you have millions of accesses daily it adds up.
Re: (Score:2)
then go back to Gopher and create one for it.
The Gemini protocol [gemini.circumlunar.space] exists. Just saying. Been in gemini space for almost a year. Love it. You should perhaps give it a try?
Re:I was going to write a comment but... (Score:5, Insightful)
> There is nothing wrong with JavaScript.
Riiight, because misspelling a variable and the browser using the undefined value with NO WARNINGS is SUCH a great idea. There is a reason BASIC from the 80's is dead and professionals use statically typed languages. "Fail Early" helps catch errors at compile time, not at run time.
In order to fix that you need to use the stupid "use strict"; string literal HACK.
Javascript's retarded equality operator [github.io] is a complete clusterfuck. [destroyallsoftware.com] What moron decided that the STRING literal "1" should be equal to 1 with console.log( "1" == 1 ); ??? Disciplined programmers will use "===" but not every programmer is disciplined.
JavaScript's ASI (Automatic Semicolon Insertion) is another retarded design which can introduce silent bugs. Douglas Crockford himself famously said said [youtube.com] "Why am I betting my career on this piece of crap?"
JS is full of subtle bugs such as console.log( 0.1 + 0.2 ); printing off 0.30000000000000004. Every language has to deal with values that can't be exactly represented in Base-2 but in what world does the default output make sense?
Every time you turn around you are running into a badly designed language. Originally there was no way to include other .js files. Bone-headed decisions like this meant JS was a toy language for the longest time.
Do you even use the language???
JS designed in 10 days, and 10+ years of suffering for programmers.
Re: (Score:2)
JS is full of subtle bugs such as console.log( 0.1 + 0.2 ); printing off 0.30000000000000004. Every language has to deal with values that can't be exactly represented in Base-2 but in what world does the default output make sense?
Oh, that's a funny one.
Re:I was going to write a comment but... (Score:5, Informative)
Don't blame 0.1 + 0.2 on javaScript. That's literally hardware floating point rounding error and happens in any language that uses the native floating point types, For most applications the level of precision is acceptable. It's like complaining PI isn't exact because it can't be represented exactly in base 10. Well 0.1 and 0.2 have the same problem in base 2.
Though I still agree mostly with you. Not sure why the other guy was advocating bringing back Flash and Java. There are very good reasons why those went away from the web. Namely because they contributed to the bulk of security vulnerabilities, if by no other way than being very attractive targets for exploiters.
.
Re: (Score:2)
There is nothing wrong with JavaScript.
You watch this [youtube.com] and then try to justify that statement.
Re: (Score:2)
Remember Gopher? That was the alternative to "the web"
I remember Gopher. It was highly restrictive in capabilities and never evolved as the "the web" ate its lunch. It *was* the alternative to the web but only in the early 90s. By the late 90s it stopped being an alternative despite being widely supported by all browsers and yet it still would have died even without help from the University of Minnesota's shenanigans.
general purpose language (Score:5, Funny)
"ignoring HTML, CSS and SQL which are not general purpose languages"
YOU'RE NOT TRYING HARD ENOUGH
Ray tracing in MySQL:
https://boingboing.net/2019/10... [boingboing.net].
HTML + CSS Turing Machine:
https://github.com/brandondong... [github.com]
Elegance always loses (Score:5, Insightful)
Those who prefer languages with elegance always lose to people who prefer languages with features.
Re: (Score:3)
To be more specific, people would rather just program in whatever language paradigm they already know than learn a new language paradigm, even if the new one is better.
Re:Elegance always loses (Score:4, Insightful)
Because it rarely is better, or at least better enough. If learning the new language, libraries, paradigms etc will put me at 50% capacity for a year, and then make me 10% more efficient afterwards- I need to use that stack for 6 years to break even. I need to use it for at least 10 to get a reasonable return for the investment. And I think both of those numbers are generous. That's also ignoring the dubious definition of "better", which can be widely debated. I even know a few people who like Javascript, and Perl used to be popular.
Re: (Score:2)
If learning the new language, libraries, paradigms etc will put me at 50% capacity for a year,
That seems really unlikely.
Re: (Score:2)
To be more specific, people would rather just program in whatever language paradigm they already know than learn a new language paradigm, even if the new one is better.
Well, how long does it take to master a new language/paradigm? Or, how long does it take you to start from scratch with a new language/paradigm and get up to at least the level of your previous environment?
I mean, any decent programmer can pick up the bones of a new language in anything from 30 minutes to a few hours, right? But learning all the popular idioms? Unexpected oddities? Knowledge of libraries? Those are the kind of things that can be so time consuming.
Plus, don't forget job security. I know a gu
Re: (Score:2)
It shouldn't be too long. I have no problem with people who write awkward code because they are still figuring out the new language.
The problem is people who ask for new features to be added to a language because they don't understand they way of the language.
Re: (Score:2)
^^^^THIS
Elegance is great but I don't always have time to be graceful, sometimes I just need shit to work.
Re: (Score:3)
Elegance is great but I don't always have time to be graceful, sometimes I just need shit to work.
Yeah, this is exactly why I keep falling back into writing more perl...
Re: (Score:2)
Re: (Score:2)
That's what she SED.
Re: Elegance always loses (Score:5, Insightful)
What? What makes a language elegant is a mix of power and simplicity That's why the two most elegant languages I know are Lisp and Forth. They're absolutely works of art.
This is also why I've called JavaScript almost elegant. At its core is a very simple, powerful, and highly expressive language. That "happy medium" you've been looking for could very well be JavaScript.
Crockford is right that ES6 ruined the language. It's a real shame. Had the standards committee not decided to carter to the bottom 10%, we'd have a much better language.
Re: (Score:2)
Crockford is right that ES6 ruined the language. It's a real shame. Had the standards committee not decided to carter to the bottom 10%, we'd have a much better language.
As far as I can tell, ES6 did bring a few syntactic sugar to the table and not much else.
Arrow functions are easier to use because they do not start a new 'this' context.
Promises are useful and do not remove anything that was already there
String interpolation, the spread operator and object destructuring are just simpler ways to do simple mundane tasks.
let and const make just more sense than var
Maybe I forgot something ?
Would you care to elaborate in which way ES6 ruined the language ?
Re: Elegance always loses (Score:4, Insightful)
Arrow functions are easier to use because they do not start a new 'this' context.
Arrow functions break the language. Now, functions work differently depending on how they're defined. They are in no way "easier to use". In fact, they're far less useful!
The way 'this' worked in the language made perfect sense and was essential to the way objects worked. It was only confusing to people who refused to learn even the very basics of the language and insisted in writing code like they were using Java or C# in a language that is absolutely nothing like them.
Essentially, ES6 creates two completely different languages conjoined in the most awkward way possible. One that wants to be a poor imitation of C#, and the sensibly designed language that JavaScript used to be. For added extra fun, new APIs tend to use the ES6 crap, meaning that you can't even ignore it if you want to. Older APIs, naturally, do not. So you can't ignore the other side if you're one of those confused people that think ES6 is great. The language is now deeply confused, torn between two competing and mutually incompatible philosophies.
Re: (Score:3)
What? What makes a language elegant is a mix of power and simplicity That's why the two most elegant languages I know are Lisp and Forth.
[...]
Crockford is right that ES6 ruined the language.
What makes a language useful though is features, the opposite of elegance and simplicity. I mean that in a specific way. LISP is so powerful it doesn't even need a loop construct built in. The minus side is no one writes programs in LISP, they write an elegant DSL perfectly tuned to the domain in LISP and then w
Re: (Score:2)
Python? Now you're just trolling. Python is the opposite of elegant. What a nasty, ugly, thing that is.
if you're a mathematician
That is the kind of beauty we're talking about here. Power and simplicity.
If you want elegance and readability, there is a subset of JavaScript that could be exactly what you're looking for.
Re: (Score:2)
You wouldn't recognize elegance if it hit you in the face. But at least that explains why people don't like elegance: it's not a matter of preference, you can't even see it.
Re: (Score:2)
But JS has neither elegance nor features.
Re: (Score:2)
According to Crockford, that's because Google hijacked the standardization process. And I have to admit, the shadow DOM is really a weird way to do things.
Seriously? (Score:4, Insightful)
Look, I hate JavaScript as much as the next guy, but he is saying get rid of JavaScript while knowing there is no replacement. What is he, some kind of an ass? If something sucks, you better have a replacement. In 1920s Germany, the Weimer Republic sucked .. but it got replaced by the Nazis. In Iran, the Shah was a terrible ruler, but he got replaced by religious whackos. When something sucks, you better be damn sure the replacement is ready and won't suck.
Re:Seriously? (Score:5, Insightful)
Re: Seriously? (Score:2)
Hm, agreed.
Re: (Score:2)
I'm just waiting for a spirited discussion about "systemd" to start in 3...2...1...
Re: (Score:3)
There's no meaningful discussion anymore. You have believers and realists, both sides start with ad-hominems then get bored.
Re: (Score:2)
I'm not too firm in English, "spirited" means "sounding like it's alcohol fueled", right?
Re: (Score:3)
...It needs to be a minimal capability-based actor language that is designed specifically for secure distributed programming. Nothing less should be considered.
Re: (Score:2)
Yeah. I mean this is reasonable and accurately describes the point of the original post. But how can you compete with backslashdot's angry old man rant? I mean, it mentions Nazis... and Nazis BAD mmmkay? so therefore it wins, regardless of whether it addresses the point of the original post.
Re: (Score:2)
> Look, I hate JavaScript as much as the next guy ...
Ssssh! ...
Are you sure?
How much?
A lot!
Re: (Score:2)
but he is saying get rid of JavaScript while knowing there is no replacement.
No he's not, he's saying we need to work to get rid of JavaScript by focusing on replacing the language. I mean a good half of TFS is dedicated to talking about developing another language. A base level of reading comprehension would really help here.
Re: (Score:2)
These are quite orthogonal concepts.
In the future, you can avoid this kind of pie-in-the-face by dialing down your attempted-snark by a notch or two.
Re: (Score:2)
Hot damn, all you Oregonians are an ass.
Re: (Score:2)
Because to understand it you'd need actual programmers instead of WebDevs, and they in turn wouldn't willingly touch HTML with a 10 foot pole.
ClojureScript (Score:2)
capability-based actor language that is designed specifically for secure distributed programming. Nothing less should be considered.
That's just a techno-word salad.
Re:ClojureScript (Score:4, Insightful)
No, thank you.
Clojure and Haskell are the epitome of languages that only a purist could love. They are pure functional languages, with all the benefits and drawbacks that come with that paradigm. But the real problem with these languages is readability. They rely so heavily on symbols that only an expert in the language can even follow the code. In my 30+ years of writing code, I've used more than 25 languages, including all the major languages used for commercial purposes. I can read most any language, even if I don't "know" it. But not Haskell or Clojure. I suspect I'm not alone in this view, which is why adoption of these languages remains low.
Re: (Score:2)
Clojure is easy to read for someone like me who doesn't know the language. I think you may have confused it with some other language, or mistaken in for Common Lisp.
https://kimh.github.io/clojure... [github.io] This positively looks like something any old JS code monkey can handle.
There's nothing wrong with functional programming either. Most parts of
We have the next language (Score:3)
It's WASM. It allows you to bring your own language
The rest of his problems have good answers too:
JS lang isn't good enough? Typescript
Runtime is too slow? Bun
Tooling too much hassle? Also Bun or Vite
Other languages are nice and all, but I haven't found a better DX setup than JS/TS for the kinds of things that get built with it.
Re: (Score:2)
Forgot to mention Super JSON, for those times you need Dates, Maps, Sets, or a -0
https://github.com/blitz-js/su... [github.com]
Re: (Score:3)
Of course, WASM code doesn't have access to any semblance of networking, storage, or the DOM. So you may be able to have your code run in browser compiled from a number of languages, but you'll still need to use Javascript (or something that transpiles to Javascript) to interact with any of those things and move data explicitly in and out of the WASM realm.
For most code running in a browser, it's mostly dealing with things WASM is explicitly forbidden from doing.
Re: (Score:2)
This could be fixed quite easily by web browsers providing a library to interact with networking, storage, and the DOM just like JS has, and replacing transpiling with a virtual machine. It didn't because it was easier to get the browser makers to support this, they didn't have to write or include a VM- less QA time and risk. It also means we just have one step to go and we're where we need to be.
Re: (Score:3)
The rest of his problems have good answers too:
JS lang isn't good enough? Typescript
If your problem with Javascript is that you want types, then Typescript is an acceptable solution.
If your problem with Javascript is that you want an elegant language, then Typescript is absolutely not a solution. It's awkward.
Like trying to replace C... (Score:2)
...and with an equal chance of success, imagine.
Re: (Score:2)
Lol, no problem, gimme a sec (Score:2, Funny)
"The best thing we can do today to JavaScript is to retire it."
Lol, sure, that sounds super quick and easy to accomplish.
If you can get that done by the end of the month, I'll be all like, "Damn, what took you so long?"
So what would be the DOM successor? (Score:2)
I am sure we could easily get TypeScript to replace JavaScript just by having browsers natively support it. MS would no doubt be on board and their contributions to Edge's webkit engine could probably be easily absorbed into Safari and Chrome with minimal effort. HTTP servers could dynamically serve JS vs TS vs anything else based on headers as can modern CDNs.
We can definitely do this! I think JS's dominance is not as insurmountable as people think.
Re: (Score:2)
I am sure we could easily get TypeScript to replace JavaScript just by having browsers natively support it.
The only problem with that plan is that people would actually have to want to use TypeScript. And for whatever reason, most people don't want to use TypeScript.
Re: (Score:3)
All that gives you is a less useful version of JavaScript. TypeScript is niche for a reason.
Re: (Score:2)
Typescript is a niche because people are lazy they will generally pick the fastest solution now. Types are a hassle now even they save a lot of time in the future for any project of a reasonable size.
Re: (Score:3)
Yeah, that's mostly a myth. I use C pretty extensively and I can't tell you the last time I had the compiler catch a type error. It's just not a thing that happens.
I do love the myth of the large project though. If your project has become so complicated that you're having trouble with types, that's the fault of your design. At that point, catching type errors is the least of your problems.
As I've said countless times before, a properly designed large project will feel like a bunch of small projects. The
Re: (Score:2)
Funny, I write C, Java, and Kotlin. Those are the most common types of errors. You mix up the parameters to a function, or you forget one. You get a red squiggly line in the IDE and immediately fix it. It's so common that you forget how often it happens. Outside of typos it's by far the most common error, it just gets caught immediately before you even get to the "hit the compile button" step.
Re: (Score:3)
Yeah, that's mostly a myth. I use C pretty extensively and I can't tell you the last time I had the compiler catch a type error. It's just not a thing that happens.
Like never never? Like forgetting a * before using an int* then the compiler giving an error about not converting a pointer to an integer without a cast? Or having a brainfart and trying to add a struct to an int because you forgot to put .member_name after the struct etc etc etc. We're talking trivial shit that happens ALL the time.
In a dynamic
have you ever worked on a team? (Score:3)
Yeah, it happens so rarely that I can't remember the last time it happened. I don't believe that I'm particularly special that way. Type errors just aren't a big problem.
Maybe they aren't to you because you're the sole author and know your shit...or what you do is pretty simple. I have seen many node.js projects fail hard because a 3rd party vendor changed the API signature and it was at that moment (when we had to upgrade to address a vulnerability that we realized the original author wrote shitty tests and didn't think about all the use cases, so our customers found the error for us. If the app had been written in Java, it wouldn't have compiled.
A mistake that beginners often make is thinking that they don't need to worry about types when using a dynamic language. I would expect a lot more from a professional. Also, shouldn't your tests catch obvious mistakes like that?
On typos, a linter should catch those if your language doesn't already have something. JavaScript has "use strict", lua has strict.lua, I don't think Python has anything but I go out of my way to avoid using it. Actually, you should be using a linter anyway. It keeps you from getting too lazy.
There's so much wrong wi
It's a big barrier to a simplified Web, too. (Score:2)
But a huge contributor to the development of browser plug-ins to block and/or control Javascript---I can't live without them. Heck, some badly-written pages will just sit there and consume system resources without end if I leave a tab open overnight after having enabled Javascript in it. Would the web suffer greatly if it were retired? (Frankly, that text-only internet revival that was reported on a few weeks ago actually seems like good idea.)
Re: (Score:2)
The problems you describe are not specific to javascript. Whatever language one might dream up for browser programming, it would be easy for badly written code to lock things up or require blocking.
You can your closest friends can have you lynx-friendly web sites. The rest of the world needs something a little more interactive.
Hmm ... (Score:3)
So JavaScript, like the other dinosaur languages, has become a barrier to progress.
Not sure to which "dinosaur languages" he's snobbishly referring, but pretty sure they still... get... shit... done. Also not sure to what progress he's referring, but progress simply for the sake of progress isn't something to aspire to. Keeping things running as just as noble.
Re: (Score:2)
WebAssembly (Score:2)
Re: (Score:2)
It's available now as C# [microsoft.com]. Kind of surprising Microsoft was the first one to do it, although I think they also pioneered ASP, so they've been trying to get away from standard web stuff for a long time.
Wrong set of concerns (Score:2)
We don't need a language for distributed programming in a browser. The vast majority of code in a web application is really dealing with interactions and presentation. You know, your standard MVC stuff. We have plenty of object oriented languages that would do fine.
You should be able to use WASM for some of that already or tweak it to be a good intermediate language that balances the ability for high level analysis (security and sandboxing) with quick and effective compilation/interpretation.
No, the problem
Re: (Score:2)
MVC doesn't work so well on the frontend because the M is all on the backend. You need to extend the paradigm a bit to deal with that fact.
Re: (Score:2)
the problem is what was stated at the end. It's the DOM and replacing it with an API that really allows for UI components to be built and assembled in a web application.
The DOM makes sense in its way (for documents) and isn't really a problem for anything else now since we got positional control over everything. If you want to draw every element independently and never have anything nested inside of anything else, you can do that. Or you can draw the whole "page" out of one SVG, or one big raster image, or anything in between. So consistency is up to you, if you want to do everything yourself. It's not like you don't have the option.
why allow for much larger consistency in web applications? Much better to have to pay coders 120K+ to constantly reinvent things like "enter CC information here" or "login/account info".
There are plenty of frameworks, and ther
a minimal capability-based actor language? (Score:3)
What? No. it needs to be a Z80 emulator with 64K of RAM. Write your web pages in assembler. You can't have any logic that doesn't fit into 64K. You can't run code faster than 4 MHz. Suddenly all the browse bloat shit goes away, and you are totally free to use SmallTalk or Lisp for Z80 in your own projects without inflicting your weird language fetish on the world.
Re: (Score:2)
Ha! A few years ago, I actually wrote a Z80 emulator in JavaScript to run a Spectrum program. I couldn't get Mame to load it for some unknown reason and knocked it together out of frustration. It took a longer than expected. The Z80 is a real pain to emulate.
The flaw in your plan is building a DOM interface. I'm guessing that you'll need an awful lot of that 64k just to deal with that.
Re: (Score:2)
You can cheat and handle the DOM with simple numeric handles as if it were coming through an OS, hardware, or channel controller. But then we're starting to creep towards a minimal actor language that happens to use Z80 machine language for the actor object's state machine. oops!
8080 is a bit easier than Z80 because there are fewer encodings to deal with. The Z80 Instruction Exerciser (Zexall/ /Zexdoc) can help tremendously with emulation development, but it's very tough to pass. Getting the core CPU instru
Re: (Score:2)
. The Z80 Instruction Exerciser (Zexall/ /Zexdoc) can help tremendously with emulation development, but it's very tough to pass.
Those are helpful, but I didn't have much trouble passing either one completely. Documentation is pretty good these days, so dealing with the MEMPTR / WZ register (for the X and Y flags) necessary to pass Zexall wasn't a problem. The problem is that those tests are not even close to comprehensive. I found some serious problems affecting most of the CB instructions after I achieved 100% on both.
There is a better test, an update to zexall, by a guy named Patrik Rak helpfully named z80 Tester [github.com] It still isn'
Re: (Score:2)
it needs to be a Z80 emulator with 64K of RAM. Write your web pages in assembler.
While that would fix the problem of bloated web interfaces, the artificial resource use limitation could not compete with a system that provides access to far more resources.
However, what might work is to have a fairly simple system for configuring how much of your finite computing resources are allocated to various tasks. I poked around with some Linux configs, to try and stop my web browser from slurping all my RAM and CPU, so I can actually do some work, using my CAD system, without closing down the brow
JSON should be retired (Score:2)
And promptly replaced with protocol buffers. JSON is after all a hacked together subset of JavaScript.
Thinking back over the years the only thing worse than XML was dealing with both XML and JSON because agreeing on one standard for half baked inefficient plaintext data representation was obviously way too hard.
Personally nothing but contempt for the "creator" of JSON. In my opinion JSON is right up there with REST in technologies that not only serves no constructive purpose actively wastes time and reso
Re: (Score:2)
JSON is after all a hacked together subset of JavaScript
No. JSON stands for JavaScript Object Notation and it is exactly that. No more and no less. There's nothing at all hackish about it. While it's technically true, it's misleading to call it "a subset of JavaScript." It's not a language, it's just some borrowed syntax.
The whole point of JSON is that it's incredibly simple so it's easy to understand, easy to write, easy to parse, and (this is very important) stable. The first version was the last version. It's also really nice to use, which is one of th
Re: (Score:2)
No. JSON stands for JavaScript Object Notation and it is exactly that. No more and no less. There's nothing at all hackish about it. While it's technically true, it's misleading to call it "a subset of JavaScript." It's not a language, it's just some borrowed syntax.
I don't think this is misleading at all because a subset is what it is. JSON was not designed for data interchange it was simply a cut and paste of JavaScript objects.
The whole point of JSON is that it's incredibly simple so it's easy to understand, easy to write, easy to parse, and (this is very important) stable. The first version was the last version.
Escaping is unnecessarily complex and there are multiple ways of encoding the same data. No schemas, namespaces, validation, path expressions, common data types, transform languages..etc. It was just an idea to use JavaScript and nothing substantive beyond that.
It's also really nice to use, which is one of the many reasons why it became so popular so quickly. Yes, XML being the worst possible thing helped, but it's actually really good on its own.
JSON and XML were introduced at about the same time within a couple years of eac
Re: (Score:2)
Actually, JSON is quite a good format for representing data in text. If you have some better system in mind, please let the world know.
One point I noted with representing numeric data as text is that the text representation can actually use less bytes that the binary representation. For example, consider the number 1.234. This requires 5 bytes of ASCII text. In binary form, it would require 8 bytes, if double precision were used.
Another point worth stressing is that a text format such as JSON or XML tends t
I have javascript... but it is what we got. (Score:4, Insightful)
Am i the only one that hates nested anonymous functions so that when you get to the end of a block of code there is a profusion of squigglies, parenthesis and semi-colons?
Minimal capability-based actor language (Score:2)
Stop calling JavaScript "Popular" (Score:5, Funny)
Yes, I use it every day. And I hate it every day.
It's like calling gonorrhea the most popular venereal disease.
Re: (Score:2)
It is therefor hard to argue that msgpack is "better", in at least the paradigm of JS data interchange.
With JSON, at the very least, you have the benefit of knowing that whatever parser you use is part of the browser, and is probably more performant than anything you can dream of.
Further, since whatever you're looking at needs to be parsed anyway, addition
Re: (Score:2)
With JSON, at the very least, you have the benefit of knowing that whatever parser you use is part of the browser, and is probably more performant than anything you can dream of.
Wasn't this the raison d'etre of JSON? Fuck it just exec data because why not? When CVEs started to pile up there were eventually JavaScript JSON parsing libraries then a native function.
Re: (Score:2)
Weak typing and doesn't catch its own typos... Given the context of the topic I'd say Javascript.