5 ms·

1. What's so horrible about JavaScript? Could you give a few examples? 2. "one DSL that was designed to mark up content in simple ways" - With custom elements,

1. What's so horrible about JavaScript? Could you give a few examples? 2. "one DSL that was designed to mark up content in simple ways" - With custom elements, we can extend that simple language to our liking. There are no bounds anymore. 3. "everyone ignores or overrides them even to the extent of building preprocessing tools" - Problem? We write in Sass/Less/Stylus/etc. which are capable languages that are continuously improved. 4. "It offers limited separation of concerns in terms of content, presentation and behavior" - What do you mean? You can separate those things just fine. 5. "It offers almost no tools for modularity" - npm is full of tools for this. You can have modularity in your source code and rely on tasks to package it for production. 6. "the Web is somehow a special thing" - Hm, it's open-standard and fully cross-platform. Looks pretty special to me. 7. "and run-time environment that a diverse range of programming languages can use as a stable, secure, reliable foundation" - Isn't JavaScript just that? I'm not an expert on this, but it looks like the general trend is that more and more languages are being compiled to JavaScript. 8. "to build more suitable replacements that are designed to be fit for purpose from day one" - I think we can all agree that this would be better, but it's just entirely unrealistic. We can't just ditch stuff that has become common. The Web is here to stay.

innguest 13y ago
1. http://www.youtube.com/watch?v=hQVTIJBZook http://www.youtube.com/watch?v=hQVTIJBZook around 11:30. This is common knowledge, we should not have to repeat this every time we talk about this topic. 5. Where in npm (I've no clue what that is) can I find: 1. a calendar widget to put on my page? 2. an email, password, confirm password form to put on my page? You're not getting his point.
- SimeVidas 13y ago
  1. JavaScript has "bad parts", yes, but we can just ignore them. Allow me to use an analogy here: Image you have a smartphone that has 100 apps installed, and of those 100 apps, 10 are crapware (e.g. pre-installed vendor-specific apps that are just bad). Does this make the phone horrible? No, of course not. Just ignore that crapware. Even if you can't uninstall it, it's not an issue for you. Use the good apps, install more good apps if you like to (analogy to JavaScript libraries) and ignore the crapware (JavaScript "bad parts"). 2. That's literally what web components are for. Read OP's post. We will have <calendar-widget> and <login-form> and many more custom elements with plug-and-play functionality.
- kyllo 13y ago
  npm = node package manager. That's for server-side javascript with node.js. Totally different deal from what we're talking about here, which is client-side javascript.
  - SimeVidas 13y ago
    Server-side and development. In a nutshell, npm is used to install development tools for building and packaging your source files, running a local server and even deployment.
  - nDmitry 13y ago
    You can use npm modules on the client via Browserify. And there is a dedicated to client-side package manager called Bower.
    - kyllo 13y ago
      Those are some pretty cool projects. This sort of thing really needs to be supported natively in the browsers and written into the ECMAScript standards, though. It looks like what both Browserify and Bower are doing is basically a macro expansion that outputs regular Javascript, which is interesting, but really shouldn't be necessary. Basically the current state is that everyone knows that HTML/CSS/JS sucks (by sucks I mean not adequately productive to work in, relative to the feature demands of modern web applications), so we're building languages that compile to them so that we don't have to write them directly. JS is becoming like the assembly language of the web. Some cool stuff has come out of that, but it doesn't mean we should give up on trying to make HTML/CSS/JS better. They were designed to be written by humans, so we shouldn't need to compile to them in order to be productive.
      - nDmitry 13y ago
        JavaScript is all about lack of standard solutions. Take any aspect of the development and you will get a million of possible solutions, whether they are classes implementations, package managers or build tools.
kyllo 13y ago
Javascript has plenty of terrible language features, particularly in the scoping rules, but the biggest problem is the lack of any concept of modules/packages, or namespaces. <script> tags just dump everything into the current page context. So you get stupid issues like name conflicts between all the different libraries that define a "$" function. Refresh the page or navigate to a new page and the context gets wiped out, so you have to store state in cookies to mimic the concept of a session. The 'Back' button often breaks everything. The whole platform was just designed for rendering simple documents and forms, not complex applications. The deficiencies of HTML/CSS/JS are why stuff like ActiveX, Flash, and now PNaCl even exist. They are workarounds, but they are proprietary and break portability, so they are not the way forward. Yeah, you can make some pretty amazing applications with HTML/CSS/JS, but it's unnecessarily hard, you have to fight against the platform constantly, and the only reason why we do it is because we currently have no good alternative. Don't let the status quo blind you to the possibilities of how much better portable networked applications could be.
- SimeVidas 13y ago
  ECMAScript 6 modules: http://www.2ality.com/2013/11/es6-modules-browsers.html http://www.2ality.com/2013/11/es6-modules-browsers.html. The JavaScript language is evolving and the issues you mentioned have been addressed.
Silhouette 13y ago
What's so horrible about JavaScript? Could you give a few examples? I don't want to bore everyone with some huge post, but among other things: 1. It's full of awkward edge cases. (See the 'Wat?' talk for numerous examples.) This is bad generally, and terrible if you want to use the language as a least common denominator foundation on which other languages and tools might be built. 2. It has little if any meaningful support for things like modularity, composition, separation of interface from implementation, and other basic software development good practices. 3. It is highly dynamic. This is good for prototyping and small, quick enhancements to web pages, which is what we used to use JS for. However, it is not good for building stable, robust, secure, large-scale systems that will be built and maintained by lots of people over extended periods, which is what we (reportedly) want to do with the Web now. 4. It doesn't work like any other major programming language. Hardly anyone seems to use prototype-based inheritance well, and most of those who do are probably experts working on libraries rather than everyday web developers. It seems more common for people to try and use class-style OO with JS, first resulting in a lot of ugly hacks, and I gather soon resulting in various syntactic sugar being built into a future version of the language, making this area not just esoteric but also more complicated. Don't even get me started on function-based scoping rules, whose primary functions in JavaScript appear to be being abused to make up for the lack of any sane module system and causing frustration to JS beginners whose loops don't do what they "obviously" should (and would in just about any other mainstream language). With custom elements, we can extend that simple language to our liking. There are no bounds anymore. Not really. You can add new vocabulary, but you can't change the grammar. In particular, you're still essentially assuming that the application is built around one big hierarchy of elements in a DOM. Except that then we get to Shadow DOM to try and work around that. And now we're back to trying to do modularity, but making what should be a trivial and widely used concept absurdly overcomplicated. Again. Problem? We write in Sass/Less/Stylus/etc. which are capable languages that are continuously improved. Sure, and so do I. But no matter which preprocessing tools we use, CSS is still woefully underpowered for designing even moderately complicated web pages, never mind full-on user interfaces, and while SASS and the like are great for things like shorthand notations/macros, they ultimately still get turned into CSS and rely on its limited/broken models. At least these days we can use box-sizing to fix one of the long-standing headaches, but we still rely on abuses like combining floats and negative margins to set up layouts. You still can't specify even very simple dynamic layouts that adapt to the actual size of content; a lot of Web developers still think a concept as simple Responsive Design is clever, because in Web world it is, but UI designers building native applications have been working around similar problems for several decades. For that matter, a bunch of awkward dependencies still exist between CSS and the order of elements you give in HTML, so you can't fully separate content from presentation and keep your layout away from the content you put in it. Consider the impact of order of mark-up on how floats are rendered, for example, or the need for extra wrapper elements so you can set position:fubar on things to get your latest layout hack to work. Web Components offer various tools for hiding some of this, but the same junk is still happening under the hood, and it's still creating complexity for both those who develop the components and those who write the browsers. What do you mean? You can separate [content, presentation and behaviour] just fine. No, you can't. You might think you can, but every now and then you run into the kinds of examples I mentioned above, which you can't fix because the underlying HTML and CSS models were designed for a different purpose and are broken for what you want to do with them. Then you have to resort to JS to work around the problem, which is time-consuming and gives up the whole idea of specifying a layout and then putting the content into it in the way we're usually trying to. npm is full of tools for this. You can have modularity in your source code and rely on tasks to package it for production. But npm doesn't run in browsers, so now everything is complicated by yet another up-front build tool, which seems to be the modern web developer's answer to everything. And sure, it works, as long as someone is wasting huge amounts of time writing and maintaining all those tools, and as long as the tools always work properly, and as long as everyone knows how to use them, and as long as everyone agrees on which "them" to use, and a whole bunch of other overheads that are a systemic drain on the efficiency of the entire development process. The thing is, I shouldn't have to rely on a bunch of infrastructure to do something as simple as writing modular code for a large-scale application. It should be a completely stable, simple, universally applicable feature in any serious programming language, and doing things like making code available as a module with a clearly defined interface or accessing code from somewhere else via that interface should be one-liners. JavaScript, and the numerous related tools from npm to RequireJS via who even knows how many others now, aren't even in operating the same universe as I'm describing. Also, please note that I wasn't just talking about JavaScript there. Both HTML and CSS have related problems, and again, while there are some changes in the works to help work around these issues, the basic models are fundamentally broken. Why should any serious, large-scale application start from the idea that a single page of mark-up/single DOM should be the foundation on which everything else, including any code and stylesheets and other HTML/DOM data for different parts of the system, should be found? The entire premise is kind of absurd, if you stop and think about it, but because the Web offers us no real alternative today, the average Web designer/developer doesn't get that far or just resigns themselves to dealing with it anyway... Edit: I see the parent post has grown some more questions while I wrote this, but this post is way too long already so I don't think I should extend it any more.

innguest 13y ago

1. http://www.youtube.com/watch?v=hQVTIJBZook http://www.youtube.com/watch?v=hQVTIJBZook around 11:30. This is common knowledge, we should not have to repeat this every time we talk about this topic. 5. Where in npm (I've no clue what that is) can I find: 1. a calendar widget to put on my page? 2. an email, password, confirm password form to put on my page? You're not getting his point.

SimeVidas 13y ago
1. JavaScript has "bad parts", yes, but we can just ignore them. Allow me to use an analogy here: Image you have a smartphone that has 100 apps installed, and of those 100 apps, 10 are crapware (e.g. pre-installed vendor-specific apps that are just bad). Does this make the phone horrible? No, of course not. Just ignore that crapware. Even if you can't uninstall it, it's not an issue for you. Use the good apps, install more good apps if you like to (analogy to JavaScript libraries) and ignore the crapware (JavaScript "bad parts"). 2. That's literally what web components are for. Read OP's post. We will have <calendar-widget> and <login-form> and many more custom elements with plug-and-play functionality.
kyllo 13y ago
npm = node package manager. That's for server-side javascript with node.js. Totally different deal from what we're talking about here, which is client-side javascript.
- SimeVidas 13y ago
  Server-side and development. In a nutshell, npm is used to install development tools for building and packaging your source files, running a local server and even deployment.
- nDmitry 13y ago
  You can use npm modules on the client via Browserify. And there is a dedicated to client-side package manager called Bower.
  - kyllo 13y ago
    Those are some pretty cool projects. This sort of thing really needs to be supported natively in the browsers and written into the ECMAScript standards, though. It looks like what both Browserify and Bower are doing is basically a macro expansion that outputs regular Javascript, which is interesting, but really shouldn't be necessary. Basically the current state is that everyone knows that HTML/CSS/JS sucks (by sucks I mean not adequately productive to work in, relative to the feature demands of modern web applications), so we're building languages that compile to them so that we don't have to write them directly. JS is becoming like the assembly language of the web. Some cool stuff has come out of that, but it doesn't mean we should give up on trying to make HTML/CSS/JS better. They were designed to be written by humans, so we shouldn't need to compile to them in order to be productive.
    - nDmitry 13y ago
      JavaScript is all about lack of standard solutions. Take any aspect of the development and you will get a million of possible solutions, whether they are classes implementations, package managers or build tools.

kyllo 13y ago

Javascript has plenty of terrible language features, particularly in the scoping rules, but the biggest problem is the lack of any concept of modules/packages, or namespaces. <script> tags just dump everything into the current page context. So you get stupid issues like name conflicts between all the different libraries that define a "$" function. Refresh the page or navigate to a new page and the context gets wiped out, so you have to store state in cookies to mimic the concept of a session. The 'Back' button often breaks everything. The whole platform was just designed for rendering simple documents and forms, not complex applications. The deficiencies of HTML/CSS/JS are why stuff like ActiveX, Flash, and now PNaCl even exist. They are workarounds, but they are proprietary and break portability, so they are not the way forward. Yeah, you can make some pretty amazing applications with HTML/CSS/JS, but it's unnecessarily hard, you have to fight against the platform constantly, and the only reason why we do it is because we currently have no good alternative. Don't let the status quo blind you to the possibilities of how much better portable networked applications could be.

SimeVidas 13y ago
ECMAScript 6 modules: http://www.2ality.com/2013/11/es6-modules-browsers.html http://www.2ality.com/2013/11/es6-modules-browsers.html. The JavaScript language is evolving and the issues you mentioned have been addressed.

Silhouette 13y ago

What's so horrible about JavaScript? Could you give a few examples? I don't want to bore everyone with some huge post, but among other things: 1. It's full of awkward edge cases. (See the 'Wat?' talk for numerous examples.) This is bad generally, and terrible if you want to use the language as a least common denominator foundation on which other languages and tools might be built. 2. It has little if any meaningful support for things like modularity, composition, separation of interface from implementation, and other basic software development good practices. 3. It is highly dynamic. This is good for prototyping and small, quick enhancements to web pages, which is what we used to use JS for. However, it is not good for building stable, robust, secure, large-scale systems that will be built and maintained by lots of people over extended periods, which is what we (reportedly) want to do with the Web now. 4. It doesn't work like any other major programming language. Hardly anyone seems to use prototype-based inheritance well, and most of those who do are probably experts working on libraries rather than everyday web developers. It seems more common for people to try and use class-style OO with JS, first resulting in a lot of ugly hacks, and I gather soon resulting in various syntactic sugar being built into a future version of the language, making this area not just esoteric but also more complicated. Don't even get me started on function-based scoping rules, whose primary functions in JavaScript appear to be being abused to make up for the lack of any sane module system and causing frustration to JS beginners whose loops don't do what they "obviously" should (and would in just about any other mainstream language). With custom elements, we can extend that simple language to our liking. There are no bounds anymore. Not really. You can add new vocabulary, but you can't change the grammar. In particular, you're still essentially assuming that the application is built around one big hierarchy of elements in a DOM. Except that then we get to Shadow DOM to try and work around that. And now we're back to trying to do modularity, but making what should be a trivial and widely used concept absurdly overcomplicated. Again. Problem? We write in Sass/Less/Stylus/etc. which are capable languages that are continuously improved. Sure, and so do I. But no matter which preprocessing tools we use, CSS is still woefully underpowered for designing even moderately complicated web pages, never mind full-on user interfaces, and while SASS and the like are great for things like shorthand notations/macros, they ultimately still get turned into CSS and rely on its limited/broken models. At least these days we can use box-sizing to fix one of the long-standing headaches, but we still rely on abuses like combining floats and negative margins to set up layouts. You still can't specify even very simple dynamic layouts that adapt to the actual size of content; a lot of Web developers still think a concept as simple Responsive Design is clever, because in Web world it is, but UI designers building native applications have been working around similar problems for several decades. For that matter, a bunch of awkward dependencies still exist between CSS and the order of elements you give in HTML, so you can't fully separate content from presentation and keep your layout away from the content you put in it. Consider the impact of order of mark-up on how floats are rendered, for example, or the need for extra wrapper elements so you can set position:fubar on things to get your latest layout hack to work. Web Components offer various tools for hiding some of this, but the same junk is still happening under the hood, and it's still creating complexity for both those who develop the components and those who write the browsers. What do you mean? You can separate [content, presentation and behaviour] just fine. No, you can't. You might think you can, but every now and then you run into the kinds of examples I mentioned above, which you can't fix because the underlying HTML and CSS models were designed for a different purpose and are broken for what you want to do with them. Then you have to resort to JS to work around the problem, which is time-consuming and gives up the whole idea of specifying a layout and then putting the content into it in the way we're usually trying to. npm is full of tools for this. You can have modularity in your source code and rely on tasks to package it for production. But npm doesn't run in browsers, so now everything is complicated by yet another up-front build tool, which seems to be the modern web developer's answer to everything. And sure, it works, as long as someone is wasting huge amounts of time writing and maintaining all those tools, and as long as the tools always work properly, and as long as everyone knows how to use them, and as long as everyone agrees on which "them" to use, and a whole bunch of other overheads that are a systemic drain on the efficiency of the entire development process. The thing is, I shouldn't have to rely on a bunch of infrastructure to do something as simple as writing modular code for a large-scale application. It should be a completely stable, simple, universally applicable feature in any serious programming language, and doing things like making code available as a module with a clearly defined interface or accessing code from somewhere else via that interface should be one-liners. JavaScript, and the numerous related tools from npm to RequireJS via who even knows how many others now, aren't even in operating the same universe as I'm describing. Also, please note that I wasn't just talking about JavaScript there. Both HTML and CSS have related problems, and again, while there are some changes in the works to help work around these issues, the basic models are fundamentally broken. Why should any serious, large-scale application start from the idea that a single page of mark-up/single DOM should be the foundation on which everything else, including any code and stylesheets and other HTML/DOM data for different parts of the system, should be found? The entire premise is kind of absurd, if you stop and think about it, but because the Web offers us no real alternative today, the average Web designer/developer doesn't get that far or just resigns themselves to dealing with it anyway... Edit: I see the parent post has grown some more questions while I wrote this, but this post is way too long already so I don't think I should extend it any more.