231–240 of 241 posts
I note that all those ecstatic quotes are from executives. Because the way I remember it, technical people hated it with a passion, from its design to its implementation. In fact, the most popular JS projects have always been to avoid writing ES5, its DOM API, or depending of one of its implementation: - scriptaculous: we hate even the basic types, so we monkey patch our own code into it. - jquery: don't use any of t…
Earlier quoted context omitted.
Why would you direct new comers attention to eval'esque functionality? They should stay far far away from it. Come to think of it, everyone should stay away from eval functionality!
Because students can understand "code being run every x seconds" easier than "reference to function being resolved then called every x seconds". Once they do, you show the problems with it and show why callbacks are better. When it comes to pedagogy, I'll use every trick I can. And I always win.
Earlier quoted context omitted.
Because students can understand "code being run every x seconds" easier than "reference to function being resolved then called every x seconds". Once they do, you show the problems with it and show why callbacks are better. When it comes to pedagogy, I'll use every trick I can. And I always win.
Agreed. In my class I always start with the hard/wrong way. Point out why it's hard/wrong. Let them hate it. Then show the easy/correct way. You can't just point them at something and say, "Do it this way or else." That's not teaching. That's directing.
Earlier quoted context omitted.
I meant creating a GUI from scratch. Creating a GUI using the DOM is easy. Working with the DOM overall is simple. What I mean is that the DOM do so much work for us (that we take for granted). What I mean by slow is for example adding a element to the screen, or updating some text. Compared to for example everything that happens on the screen in a 3d game. I do everything using vanilla JS and I cannot understand why…
I worked with vanilla JS for some time (before Prototype.js or jQuery existed) and used a bunch of incantations of different libraries and frameworks over the years and I cannot understand why anyone would choose to use JS for platforms where you can use any other language (aka... any platform that isn't a browser). No construct or design decision of JS is better than in other languages, the lack of a basic standard…
In order to improve as a programmer over the years I have had to learn to improve my writing. This requires a clear vision before putting keys on a keyboard and a solid sense of organization. You should know what you are going to work on with a strong confidence on how to go about it before doing any of the actual work. Sure rough spots will emerge along the way, but that shouldn't stop you from solving for the original vision. Then once the original vision is achieve refactor, debug, and refactor again. In writing that is call drafts and second opinions. This applies to any programming language equally.
A confidence of data structures is also critically important. Once skills and conceptual mental modeling of data structures becomes as common as spelling your name algorithms and logic almost write themselves. JavaScript does some things right by providing simplified data structures (objects, arrays, sets, maps, and such) and is really expressive in how you use them. JavaScript also does a lot wrong in this regard with its loose typing and some of its sloppy conventions. Fortunately, TypeScript interfaces coupled with consistent use of strict type declarations close many of those gaps.
---
I have heard so much hope for WASM killing JavaScript over the last 3 years, and almost all of it based on ignorance of how the technologies work. So much of this hope hinges on the availability of the page's DOM to a WASM instance by people who have never written to the DOM and have no idea what they are really asking for. While the WASM working group says this will never happen I suspect that very simple technology reasons will get in the way first regardless of what anybody wants.
If, however, WASM does replace JavaScript because the page's DOM becomes available to a WASM instance I suspect it will be the same clusterfuck that those developers were hoping to replace. I suspect if those developers couldn't figure out the relationship-oriented tree structure of the DOM using JavaScript they fail all the same when using their favorite language.
I can understand replacing JavaScript for other reasons, but rarely (extremely rarely) are the well grounded reasons ever a primary motivation for wanting JavaScript replaced.
Earlier quoted context omitted.
You're right that Java was being promoted as a front-end language at first (Sun found a customer for Java), but I'm pretty sure the intent was to generate excitement by finding a killer app and then expand the market from there. Also, Java applets and JavaScript were added to Netscape 2.0 at the same time and were meant to complement each other, not compete. It may seem like Java came first because JavaScript was cal…
Sorry, didn't mean to imply that my reaction was any kind of truth about the situation. I'm just recalling the thoughts I can remember from that time, hoping that they have some relevance.
I think the point I'm really trying to make is that the Netscape team had a much richer vision of the web than what we use today. Before they built Netscape, Andreessen and Clark were considering building an online gaming platform. I'm sure you remember how big multimedia was back then.
If you look at the timeline, you can see where the were going. They started off with a focus on dominating the browser market, which they did in 4 months. In less than a year after their first release, they released the first version of an online platform. It added Java, JavaScript, and a plug-in architecture with standard plug-ins like Live3D so you could embed VRML into your HTML page. No one was even sure HTML wasn't going to be replaced by something better, so I have to imagine they were hedging their bets by adding three different ways to build on their platform.
If anything, I think your original comment reinforces that strategy. They knew there were a lot of C++ developers who wouldn't take to Java for whatever reason, so they offered a plug-in architecture for people who cared more about performance and experience than being cross-platform.
Had things gone differently (Microsoft not woken up), I can easily see Netscape creating a dominant internet platform that went beyond HTTP and viewing hyperlinked documents. They were already bundling email, website editors, conferencing, news clients, etc.
JavaScript is a fascinating example of Microsoft successfully getting a giant own goal. The promise of the web was cross platform applications that required no installation. Microsoft's fear was that cross platform applications would make the operating system irrelevant and reduce Windows lock-in. Both Sun (with Java) and Netscape wanted Microsoft's worst fears to happen. This was the era of Embrace-Extend-Extinguish…
Microsoft did a really great job of making MSIE a platform, too, with active scripting you could write browser programs in REXX or Tcl. It was really wide open.
That made it appropriate for intranet applications, but not the internet.
Earlier quoted context omitted.
You were able to use document.write somewhat dynamically, but the not reliably across all the browsers. Even if you did make an RPC call, there wasn't a lot you could do with it presentation wise because DHTML was two years away. (Even then, IE was the only one who had a decent implementation for a number of years after that.) Plugins and applets filled a huge gap functionality wise.
You must have been before me. NN and MSIE 4 both had what we now call DOM Level 1, in 1997.
I don't say that to crap on Netscape. Microsoft was a well-funded company with a lot of experts who had years of experience create applications with DOMs. Also, they had the luxury of delivering a browser for one operation system.
Netscape was a brand new company that went public 7 months after it's first release and 1.5 years after its founding. They sold investors the premise they were going to become the Microsoft of the internet. They had a fraction of the resources while they were trying to creating browsers, email clients, collaboration software, web server, and a host of other software for multiple platforms.
I note that all those ecstatic quotes are from executives. Because the way I remember it, technical people hated it with a passion, from its design to its implementation. In fact, the most popular JS projects have always been to avoid writing ES5, its DOM API, or depending of one of its implementation: - scriptaculous: we hate even the basic types, so we monkey patch our own code into it. - jquery: don't use any of t…
JS oftentimes reminds of Apple: there's the industry standard or some already well stablished way of doing things, and they go like "Well, flip it. We're doing our own way, just because".
Earlier quoted context omitted.
Re: It's easy to forget, but for years after its introduction JavaScript didn't work well. And STILL doesn't, at least for anything non-trivial. New browser brands or version often "break" a lot of libraries and code. It's not really JS's fault: HTML wasn't meant to be emulate real desktops, and shoehorning it to do so has made a giant tangled multi-layer mess. Browser standards should be split into three focus areas…
I used to think so, but with reactive components and css layout like grid, you have enough clear paths for most use. This dom thing seems like it's here to stay for a few decades more.
Earlier quoted context omitted.
With scheme perhaps, but the Lua of 1995 was a much more primitive language which didn't even support closures. It had the opportunity to break backwards compatibility and refine itself numerous times - as the defacto language of the web I think lua would have turned out much poorer rather than the web much better.
Lua is pretty terrible in how barebones it is. I don't think anyone on HN who raves about Lua yet complains about JS has done much work with either. There's a reason it has zero traction beyond embedded application and niche application like Pico8.
But as far as the language itself goes, Lua is far superior, with a lot more consistency all around, and fewer traps.