19 ms·

Ask HN: Will front end development ever move away from JavaScript?

124 points by js-fiend 10y ago

Developers have done some amazing things with JS, but I think everyone can agree its not the most elegant language. I understand we are where we are because the its the only language supported by browsers. But will we ever move away from it? Could Google or Mozilla build support for another language into their browsers while developers gradually move away from JS? Will developers be open to alternatives? Will we finally standardize on a simpler set of tools and frameworks? Does WebAssembly solve this? Is TypeScript good enough?

coreyp_1 10y ago
Saying "it's not the most elegant language" is quite (mis)leading. While I would not claim that it is the most elegant language, I would most definitely claim that it is elegant. Two things that many people get wrong about JavaScript: (1.) Most of the ugly parts involve interacting with the DOM, and the DOM is NOT JavaScript, and (2.) Just because some people write ugly code with it does not mean that the language itself is ugly. ES6 and ES7 have done wonders for the language syntax, and the flexibility of the language allows you to write in any combination of procedural, functional, prototypical, object-oriented programming styles. I mix them together as needed to make programs more intuitive and easier to follow. Programming is an art, and JavaScript is a powerful and versatile tool. You are also wrong in that it being the only language supported by browsers. That may be the case now, but in the past many, many, many websites used flash and java applets. Quite frankly, the reason that JavaScript is what we have now is because it really is that good that it replaced all the other options. All of the other questions are all over the board... It sounds like you are trying to get us to write a homework assignment for you.
- sAbakumoff 10y ago
  >>Most of the ugly parts involve interacting with the DOM, and the DOM is NOT JavaScript, and Yeah, like dealing with "this" keyword or type coercion in JS is not the ugliest thing ever in the history of Programming languages
  - api 10y ago
    Try C++ template metaprogramming or Java collections before generics.
  - mschuetz 10y ago
    > Yeah, like dealing with "this" keyword or type coercion in JS is not the ugliest thing ever in the history of Programming languages Try python. Python's handling of this/self makes javasacript look like the most amazing thing ever.
    - krzyk 10y ago
      What do you mean? Could you give an example? I always regarded python self to be one of the cleanest ways to show that we have another parameter in a method.
    - _ZeD_ 10y ago
      are you joking, right? in javascript you cannot ever KNOW what this refers to (is the instance of a new Thing()? is null? is "window"? is something set with .bind()? is just "the left thing before the dot before the function"? is something else?
      - Sohcahtoa82 10y ago
        Does "this" work differently in JS as it does from Python or even C++? Is it not always the object that owns the function currently being executed? If the "this" is implicit, then how can you possibly know where the variable comes from?
    - tastyham 10y ago
      Eh. Python and JavaScript are very similar at the language level. They each have warts and are more expressive in certain areas, but at a high level they have the same semantics and the exact same advantages and disadvantages.
    - scriptkiddy 10y ago
      Could you please explain? It's always very clear in Python what `self` refers to. Self is always an instance of the parent object of a method. Some classes can also have static class methods that can be called from the class itself instead of one of it's instances. Maybe that is where your confusion is arising?
- js-fiend 10y ago
  I haven't looked at ES6/7, and its true that any language in the wrong hands can be ugly. But there's a lot wrong with JS besides how it interfaces with the DOM[1]. Which is funny because it was originally conceived as a browser scripting language[2]. And JS beating flash and java applets may be more a result of market forces (Apple) and the lack of better alternatives. Brendan Eich designed JS in 10 days for the early era of the web, which is very different today. Its both a testament to the language and the hacks on top of it that its stayed in use this long. But maybe its time to move on? [1] https://medium.com/javascript-non-grata/javascript-is-a-dysfunctional-programming-language-a1f4866e186f https://medium.com/javascript-non-grata/javascript-is-a-dysf... [2] https://en.wikipedia.org/wiki/JavaScript#Beginnings_at_Netscape https://en.wikipedia.org/wiki/JavaScript#Beginnings_at_Netsc...
  - graphememes 10y ago
    Why do you believe the language is dysfunctional?
- smonff 10y ago
  3) Maybe a language don't need to be that "elegant", it's not required in all situations. I think I would prefer a "practical" language over "elegance" but like the appearance.
- tobyhinloopen 10y ago
  [] + [] === "" Elegant... hmmmmm
  - ng12 10y ago
    [1,2,3].toString() === "1,2,3" [].toString() === "" It's only confusing to people who really don't know anything about the language.
  - js-fiend 10y ago
    this might be a better example https://twitter.com/codinghorror/status/476826733576847360 https://twitter.com/codinghorror/status/476826733576847360
  - graphememes 10y ago
    Are you arguing that this is confusing to you and therefore not elegant, or are you arguing that this code compiles and that means it is not elegant? Would you write that in production?
- tigershark 10y ago
  JavaScript is as elegant as a cat scratching his nails on a blackboard. it's a mongrel language without any whatsoever elegance. Taking your art metaphor further is like comparing the ceiling of the "cappella sistina" to a cut in a canvas.
billconan 10y ago
I really hope webassembly could introduce some desktop/mobile app development experience to the web. I want to use an api, similar to Qt, to write webapp.
- sanjeetsuhag 10y ago
  Working with Qt was detrimental to my mental health. Why does everybody like it so much ?
  - simplehuman 10y ago
    Those are strong emotions. What do you hate about it so much?
- adamnemecek 10y ago
  Cough cough https://www.webtoolkit.eu/wt https://www.webtoolkit.eu/wt
tommynicholas 10y ago
No.
inostia 10y ago
I think the better question is, "Will front end development ever move away from CSS?" In all honesty though, with ES6/7 writing programs in Javascript is a joy. CSS still sucks...
- vinnymac 10y ago
  Devs are certainly trying to make CSS not suck. It seems the number of CSS inline style, document.createElement('style'), etc libs are growing each month. Some library will hopefully hit the nail on the head for this problem in the coming years. The first project I worked on where I was able to isolate all my styles by component was eye opening. It becomes less like CSS and more like Androids XML styling.
  - inostia 10y ago
    > "the number of CSS inline style, document.createElement('style')" Can you expand? Which libraries, I know BEM hopes to isolate CSS styles to "components" by using strict CSS rules, but are you speaking of inline styles as they relate to JavaScript libraries like React?
    - vinnymac 10y ago
      I was referring to CSS-in-JS and what is coming out of it. https://speakerdeck.com/vjeux/react-css-in-js https://speakerdeck.com/vjeux/react-css-in-js Not all of them use inline styles and a lot are library agnostic. Here are just some of the ones I have played with, plenty more exist. https://github.com/rofrischmann/fela https://github.com/rofrischmann/fela https://github.com/FormidableLabs/radium https://github.com/FormidableLabs/radium https://github.com/Khan/aphrodite https://github.com/Khan/aphrodite https://github.com/threepointone/glamor https://github.com/threepointone/glamor https://github.com/MicheleBertoli/css-in-js https://github.com/MicheleBertoli/css-in-js https://github.com/styled-components/styled-components https://github.com/styled-components/styled-components https://github.com/css-modules/css-modules https://github.com/css-modules/css-modules https://github.com/cssinjs/jss https://github.com/cssinjs/jss https://github.com/smyte/jsxstyle https://github.com/smyte/jsxstyle https://github.com/rtsao/styletron https://github.com/rtsao/styletron
StClaire 10y ago
Yes. We moved away from Fortran, Cobol, and Basic when something better came along. Eventually we'll move away from Javascript too. Maybe it will be a language that spits Javascript, maybe it will be a language that runs on Chrome and Firefox. Right now I don't know what that language will be, but I'm sure it'll arrive one day
- cube00 10y ago
  We have, it's called TypeScript.
  - ubersoldat2k7 10y ago
    Or Dart... What ever happened with that?
  - scriptproof 10y ago
    Or ECMAScript 7 or 8 or 9...
- mabynogy 10y ago
  Or maybe JS is like shell ("Web as the OS").
- santaclaus 10y ago
  > moved away from Fortran Once in a blue moon I still have to hit up some damn Fortran because the latest badass optimization routine is cooked up by a crusty German. JavaScript is gonna be around for a minute, I'd wager.
vinnymac 10y ago
I would say it has certainly become elegant in recent years. I imagine instead of alternatives we will see a lot of things being compiled from X down to WebAssembly. I see Rust/Go/Haskell targeting WASM in the near future. WebAssembly has a lot of potential, but I think JS will have its place for a long time to come as it always has on the web. It makes me laugh whenever I think I might be writing Java for the frontend again, but it could actually happen! Asking if TypeScript is good enough is kind of an odd question, good enough for what exactly? If you meant web development it certainly has its use case, but I think the discussion around TS and Flow is still open.
- steveklabnik 10y ago
  Rust already has preliminary wasm support.
  - vinnymac 10y ago
    That is awesome, thanks for letting me know!
- WillPostForFood 10y ago
  Perhaps more elegant, but at the price of increasingly complicated tooling and complex ecosystem. The startup cost for a new user arriving into today's JS world is pretty high.
rayalez 10y ago
I don't see anything on the horizon that would be a good JS replacement. At the moment, frontend libraries like React, and the new ES6 features is the best we have. WebAssembly will allow other languages to run in the browsers, but how it will work is still unclear. The only other option I've heard of is Elm. I haven't used it, but many people claim that it might be a good JS replacement. Though I don't know if it offers enough of an advantage to cause everyone to switch. If anyone has more information or opinions - please share.
mschuetz 10y ago
With ES6, the only thing I'm missing in Javascript is static typing. Other than that, it has become a very nice language. There are some ugly sides, as in every language, but for the most part you can simply opt out of using these parts.
- digitalzombie 10y ago
  You can't opt out of implicit type conversion. I think this is one of the biggest issue Javascript have. I think the Wat lighting talk really hone this fact in far more than I can. https://www.destroyallsoftware.com/talks/wat https://www.destroyallsoftware.com/talks/wat ES6 did some nice things but at the core the language was never meant to be code more than 100 lines or so of code. You can tell when it didn't have module or package system in place from the get go. Also strict typing whether dynamic or static really goes along way in term of code maintainability especially more so when you're doing tons of lines of code. So I guess this reply is to say you can't really opt out of Javascript's hideous wart of all imo.
  - mschuetz 10y ago
    > implicit type conversion Yes, defenitely one of the biggest problems. However, after switching to === and never using == again, I've found that it's easy to avoid implicit conversions and I haven't had a problem with it in years. I totaly agree they should remove implicit conversions from javascript by yesterday, though. > but at the core the language was never meant to be code more than 100 lines or so of code. Lot's of things aren't meant to be used the way they are but things evolve.
BinaryIdiot 10y ago
Honestly JavaScript is not so bad but I could see multiple things evolving web development pretty significantly. 1. WebAssembly is cool but can't currently replace JavaScript. Now if the standard could get in gear and go a bit faster and work towards being the Java Bytecode / MSIL of the web? Then there would be zero reason to NOT develop in whatever language you want that compiled down to that. Yeah there is transpiling to JavaScript but that is more of a hack than anything; if you have to debug in an environment without source maps then it sucks hard core the further away you are from JavaScript. 2. The separation of HTML, CSS and JavaScript kinda sucks. CSS can do a lot but not everything, your HTML structure needs to be a certain way for some CSS to work correctly so the two are tied far more together than in the past. I'd like to see something eventually combine the two because let's face it, beyond basic things I almost never see the "swap a stylesheet to make everything different". Seems more of a novelty than a practical thing in my opinion. 3. I think the upcoming web component standards are going to make module web development a ton easier but the standards have been moving at a SNAILS pace. Poylmer's polyfills are great but don't cover everything and is extra overhead. When browsers support these natively it's going to make things so much easier to create 1 component that can end up being used in any web application regardless of framework.
- ktRolster 10y ago
  I think the upcoming web component standards are going to make module web development a ton easier but the standards have been moving at a SNAILS pace. Yeah tho, I'd rather have them go slowly and do a good job, because we're going to be stuck with it for a long time.
TheAceOfHearts 10y ago
It seems unlikely. Modern JS tooling has gotten very powerful, and it's still improving. Heck, even with WASM coming around, you need many external tools for building and deploying applications. If you're targeting the web you'll still need to be fully aware of its limitations as well as having a strategy for handling em. These problems won't get magical solutions all of sudden. I'd be interested in hearing of some ways in which you believe tools and frameworks could be simplified, as well as your current complaints with the ecosystem. It's important to understand that the JS world has many players, and different groups of people have vastly different requirements. For example, even if picking up Webpack takes a bit of tinkering first, once you have it in place it requires very little maintenance. If you're working on a larger web app, paying that price up front is well worth it, as you can tweak the config to easily handle most future problems and requirements.
dragonwriter 10y ago
It will, and wasm is part of that (though plain old compile-to-JS is too), but it won't be a fast transition, and it won't be all to one other option, and JS will be the main choice for many years to come; it's got lots of inertia.
watson 10y ago
I think it's a common misconception that JavaScript isn't an elegant language. The real issue is that it's the only language with a monopoly. So people who want to work on the web have to use it. This results in people being forced to use it against their will. So obviously a lot of people don't like it - probably because it doesn't have that feature they really like from their primary language - whatever that is. If we invented a replacement language, the issue would not go away, but simply shift. I think instead the real issue is that we're too bad at educating people in how to properly use the language. Sure there's corners of the language that are bad, but as a seasoned JavaScript developer you simply know to ignore those corners. So they don't bother you. You instead focus on the cool things about the language. Any programming language have good and bad things. And we as developers learn to focus and leverage the good parts to our advantage. The ideal of a perfect language is a pipe dream unfortunately - instead my advice is to really learn the language and embrace it instead of fighting it.
- GavinMcG 10y ago
  I don't think it's about missing features. JavaScript has a lot of footguns. You admit that, but dismiss the complaints. Sure, with experience you know what to ignore, but a well-designed language has fewer of those areas in the first place.
  - kelvin0 10y ago
    I've used JS enough to find that it's more like a nuclear powered .50 cal Gatling gun.
- golergka 10y ago
  > seasoned JavaScript developer you simply know to ignore those corners I'm sorry, but how does a seasoned Javascript developer ignores the absence of compile-time type checks? Aside from switching to a language that compiles to Javascript.
  - jcao219 10y ago
    I've always thought that Javascript makes up for its lack of compile-time guarantees with compensating tooling. For example, it's common to use Flow with Javascript to enable static type checking before actually running it. The language itself doesn't guarantee type safety, but when used with peripheral tooling, the developer isn't missing too much.
digitalzombie 10y ago
Too many man hours into optimizing Javascript. I doubt it. I think a realistic alternative will be transpilers. Say coding Clojure, Scala, etc.. and then it convert down to javascript. Also from what I've seen so far Mozilla really love javascript. It continues to push forward with no real alternative. Also the creator of Javascript is working with them. I love Mozilla but I wish they tackle on an alternative javascript, they're too busy with the wonderful looking Rust though. I can't blame them.
- watson 10y ago
  The creator of JavaScript stopped working there a few years ago. Now started a new browser company called Brave. The Brave browser is written entirely in JavaScript by the way
- bobbytherobot 10y ago
  I seem to vaguely recall there was a few years were Mozilla was shipping Python as an alternative to JavaScript. I want to say that HTML5 was what killed Python in Mozilla. HTML5 gained huge traction that Python never got. If someone remembers more clearly, please correct my cloudy memory.
smdz 10y ago
> Is TypeScript good enough? Yes. Once you move to TS, it's inconvenient to move back to JS > Will developers be open to alternatives? I would like to see GoLang supported in the browser (natively, not transpiled). Go has some awesome potential that's probably being wasted by limiting it to systems programming. Before Go I might have said C#. However, sometimes I want my stuff to be strongly typed, and sometimes I want to keep it flexible to change types.
- KirinDave 10y ago
  Do you really think Go is that good? I look at it as a very awkward language in many ways. 1. Go's got just... broken error handling. Please write a dozen if (err != nil) gates in a row and try not to mess up. 2. Go's principle concurrency primitive, channels, is actually very slow as per its implementation and is often avoided because of it. 3. #2 may be a blessing in disguise because working with large single-delivery channel pipelinesis actually quite awkward. Our normal go-to techniques of exception handling and trace debugging don't handle it well outside of very small contexts. 40 years of debuggers all focus on the call stack and Go smashes that. 4. Go's quite convenient for a small team banging out software but for a large team over a long period of time, we still don't have access to the versioning and build systems Google had that make a lack of good version control feasible. 5. Despite being a language all about I/O, Go brings no real new innovations in I/O to the table. 6. Go's developer mantra is at least as patronizing as Python's. Probably more so.
  - golergka 10y ago
    > Go's principle concurrency primitive, channels, is actually very slow as per its implementation and is often avoided because of it. I've only heard the opposite about it (only used Go on hobby project, so no first-hand knowledge). Can you please elaborate or give some links that discuss it? > Go's developer mantra is at least as patronizing as Python's. Probably more so. Are you referring to limiting developer's freedom?
    - holydude 10y ago
      Well channels use mutexes underneath and they are "slow". So slow in this case is very relative.
deleted 10y ago
[deleted]
mgalka 10y ago
Maybe it's just because I'm used to it, but I would say it is an elegant language. Either way, it's always under development. And any problems with the syntax can be changed in a future version, easier solution than establishing a new front standard. It also has NPM, React and other frameworks, V8. Any challenger has a lot to overcome before people will consider switching.
daliwali 10y ago
There is work on WebAssembly to add DOM support [1] but for now it is speculative. This is the main limiting factor since other languages have to use JS as a compile target instead of WASM if they want to interact with a web page. [1] https://github.com/WebAssembly/design/blob/master/GC.md https://github.com/WebAssembly/design/blob/master/GC.md
troymc 10y ago
I'm surprised at how many of the answers here are rationalizing JavaScript's monopoly, saying that it's a fine language / it's optimized / stop complaining / etc. That seems like the programming-language equivalent of Stockholm syndrome, i.e. "We're stuck with X, so we should justify and defend X as a coping mechanism." The question you should consider isn't, "Is JavaScript a good language?" The question you should consider is, "Is JavaScript's monopoly good for the web platform?"
- inostia 10y ago
  The same could be said for HTML.
  - bobbytherobot 10y ago
    And CSS
    - psyc 10y ago
      And FORTRAN.
      - pwdisswordfish 10y ago
        And my axe!
        mistersys 10y ago
        Reddit is leaking
- hasenj 10y ago
  Adjusting to reality is a good thing. Expecting reality too adjust to your personal whims and desires is kind of messed up. I don't see anyone defending JavaScript as if it had no flaws. So I'm not sure what your getting at exactly.
  - 10y ago
albertTJames 10y ago
Everytime I hear developers trash a language for this or that feature or more generally on its "elegance", it reminds me of the old debate people had over Mac being too controlling of what the user could do and PC with linux being the ultimate tool of freedom. In the end what won? The simplest, and the practical. With Linux inside it. Thinking a new language will or should come and replace JS for frontend after it has been developed and continuously improved with the web for 20 years is just tiring. JavaScript has been polished, it is practical, it has a plethora of tools and ressources. Improve javascript if you want to improve things, stop creating new paradigm all the time. I am quite happy that ES6 proved that JavaScript could become a very modern language although it is not strongly typed, tools like flow are filling the gap for now. I personally think Swift ans JavaScript are the most elegant language. And although I can see the beauty of functional programming - I dont see it being used widely or being very pratictal for frontend. As for typescript, it is a very good formalisms but it is made better by the tools built around it. I think JavaScript could go there on its own, no use having two languages in the long run. Some key improvements it does need would be to formalize flow types, more integrated linear algebra tools (or C++ extensions like numpy/scipy), a way to transpile/compile to native apps that is more efficient than electron (although electron is the bomb), and that's it. The rest has to be the job of browser making companies to comply to new standards. Developers always want to reinvent the wheel instead of submitting PRs and participating to the debate about the future of open projects as "participants". It's ok to "only" participate.
- coldtea 10y ago
  >it reminds me of the old debate people had over Mac being too controlling of what the user could do and PC with linux being the ultimate tool of freedom. In the end what won? The simplest, and the practical. With Linux inside it. Not sure what you mean. But Linux hasn't made any inroads to the desktop, and the fact that Android runs Linux is irrelevant as it's just an implementation detail (nothing Unicy is exposed to the users). What won is Windows (still) and OS X (4-5 times more popular than in 1999 when everybody predicted "Linux on the Desktop").
ubersoldat2k7 10y ago
The thing with Javascript is that, although the language may suck, it is a great ecosystem and platform to build on. It's what Java always dreamed of: build once, run everywhere. Literally! (Well, except for Node, but mostly) Don't think of Javascript as "the browser" since you've got browsers, Node, React Native, Electron, SmartTV, STB, Tizen, Xbox, PS, Wii, Switch (probably) etc. If it was easy, Java was the closest thing we ever got to this sort of portability across platforms, except for web frontend and this is what killed it. Java also has a great ecosystem and platform, it's open source (well, kind of), backed by several big software companies and lacks most of the things those who hate Javascript has (i.e. static typing). If Sun/IBM released their own browser engine with Java, instead of those stupid Applets or letting Javascript be built, the world would be different today. > But will we ever move away from it? The sheer amount of money for this to be possible is unimaginable and I don't think anyone's budget would allow for this. Hell, Facebook decided to invest on React Native when they could have done other crazy stuff like launching their own browser with ObjectiveC support. > Could Google or Mozilla build support for another language into their browsers while developers gradually move away from JS? Their engines are open source, and if this was easy I'm sure as hell someone would already have <script src="text/brainfuck"> working. You're also forgetting about Opera here. Opera is big and although its browser is not on all PC's it's on almost lots of media devices out there. Except for LG, Samsung, Roku and Android, all SmartTVs ship with an Opera browser which is what's used to run YouTube, Hulu, Netflix, HBO, etc. > Will developers be open to alternatives? Sure, Dart had its time, and TypeScript is getting lots of traction right now. You also see people writing frontend code on .Net and Java. > Will we finally standardize on a simpler set of tools and frameworks? Although I understand the frustration Javascript may raise with its tools (grunt, gulp, bower, webpack, babel, react, angular, etc), I don't see other platforms any better. I'm sure most C#, Java, C++, C, iO developers can give you great examples of how those systems are also complex, with shared libraries, low quality tools, integration, system and API problems, etc. I've used many IDEs and build tools, but the level of fear I have of XCode of breaking is huge. > Does WebAssembly solve this? No. Although some crazy people may decide to port a UI toolkit (Qt? GTK? WxWidgets?) or write a new one, the complexities this introduces are not worth it, business wise. Also, I'm sure it will also bring its own subset of problems. I particularly see WebAssembly used for two things: - Games. - Stuff you don't want people to mingle with: DRM, banking, cryptography, etc. Building a CRUD SPA in WebAssembly would be, IMO, a very stupid decision. > Is TypeScript good enough? Well, I work with quite a lot of people doing Javascript doing lots of FE projects and there isn't a big interest on it right now. Actually, Angular2 has been removed from any future projects roadmaps and we're moving to a React focused one. Thing with TS (or any other transpiling tool) is that, now you have to fight with TS problems and Javascript problems.
jedikv 10y ago
I'd just like to see the footprint (storage, memory & performance) of JS/Electron et all apps to be reduced to the levels of applications written with traditionally compiled code.
raquo 10y ago
There are plenty good languages today that compile to JS: Scala, OCaml, Clojure, just to name a few. And if you really like JS but want types, check out Facebook Flow, it's better than Typescript even though it's not as popular.
holydude 10y ago
I hate transpilers and the added complexity and abstraction layer. I love ruby but i cant imagine to write ruby in smh like coffeescript or opal for frontend. JS is the necessary evil but i would never join a company that does everything in js (frontend,backend, desktop / mobileapps ) you either love jd or you hate it.
- deleted 10y ago
  [deleted]
tastyham 10y ago
I doubt it. I think the opposite will happen: JS will become the defacto UI language for web, mobile, and desktop. The ongoing effort to improve the language has hit some stumbling blocks and made some outright mistakes, but overall has improved the language significantly. Competitors like Elm and Dart are certainly compelling, but I don't think they have enough weight to entice UI platforms to converge. The major players seem to agree that incremental improvements are easier than getting a huge amount of diverse vendors to converge on an entirely new/different platform.
krapp 10y ago
If we "move away" from Javascript, we also "move away" from being able to properly support and display much of the web in the future. We can either discard the current web as obsolete and start over with a new, stricter or more elegant framework, or else support something alongside Javascript, which only compounds the problem when every new browser then has to support every web language, and older browsers can no longer run code written in the 'new' languages. To say nothing of the likelihood that each language will have browser-specific implementations, so each language also gets its own unique ecosystem of frameworks and shims for cross-compatibility. All this towards the same end of doing stuff with the DOM, AJAX and Canvas. Doing what you can already do in Javascript, despite its issues. Why? How does it help the end user? Javascript may be bad, but the alternatives seem to be worse for everyone other than programmers who don't like Javascript.
- symboltoproc 10y ago
  WASM will become available on every major browser and there will be ways to backport the code to older browsers (i.e ASM.js or polyfilling). There are also multiple implementations but the community is not split into different ecosystems. Why do you think this is not possible again?
  - krapp 10y ago
    I don't think it's impossible, I just think it's not worth the effort. Other languages won't add any functionality that javascript doesn't already provide, or that isn't already served by languages compiling to javascript. It only adds unnecessary complexity to an already messy ecosystem.
andreapaiola 10y ago
What is elegant?
tmzt 10y ago
I think there's another way to look at this. Right now the DOM is exposed to the browser in a way that makes Javascript the most natural way to manipulate browser elements. There is a movement towards a more elegant way of expressing UI, where functional languages and imperative languages with functional features can both be used, but these currently require often large and complicated frameworks or even comete language runtimes. Ultimately these also require some kind of Javascript bridge which leads us back to it being central to web programming. You either use Javascript or you go to great lengths to hide it. The solution, which is slowly emerging in a de-facto manner, is to expose to any chosen language whether implemented in Javascript, wasm, or some new JIT compiled bytecode with dynamic features, a transactional, IPC-based API for rendering, diffing, and merging web content. JQuery inspired the selector APIs (querySelector*) which in turn improved the efficiency of, then mostly obviated, JQuery itself. I imagine the same thing could happen with React-like frameworks and things like Elm.
- scriptproof 10y ago
  There are sites written entirely in Flash and ActionScript, a platform that is now obsolete. Another attempt was Silverlight and XAML (and JavaScript), dead also. I am not sure the desire to abandon JS is shared by all.
  - tmzt 10y ago
    Yes, and to be clear I am not calling on developers or browser makers to abandon JS. I'm talking about an additional API that is more suitable to polyglot support in the browser and more in tune with how modern browser frameworks work. JS would remain a first-class language, and users of libraries or frameworks such a React would have to make very few changes to their application if they had to make any at all. The difference is the new API used by React itself to render HTML elements would be faster with native support for diffing and batching updates. Less work would be performed in blocking script contexts or on UI threads with changes to content being essentially atomic. A developer could decide to implement an ES6 module and use a new tag, <import module />, instead of <script>. This tag would support JS, WASM, and a new Dynamic WASM with support for interpreted and dynamic languages like Python or Ruby or Clojure or Elm using a similar bytecode and syntax to WASM. The <script> tag would not change and the window, navigator, and document objects and DOM APIs will be available as always. The same would be true for Angular, Ember and even JQuery.
theaustinseven 10y ago
I really suggest watching these talks for anyone who hasn't. The first especially gets at what kinds of issues javascript has, and what might happen to it. https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death... https://www.destroyallsoftware.com/talks/wat https://www.destroyallsoftware.com/talks/wat
tomatsu 10y ago
TypeScript and Dart are viable options for scripting. (Try it!) Wasm modules will be viable options for processing-intensive tasks.
campers 10y ago
I'm pretty happy developing in TypeScript these days, it at the stage where its more than good enough for most tasks. Just like the JVM is more than Java, JavaScript is the bytecode of the browser. There is plenty of languages which compile to JavaScript if you want a different style or expressiveness in your code. https://github.com/jashkenas/coffeescript/wiki/List-of-languages-that-compile-to-JS https://github.com/jashkenas/coffeescript/wiki/List-of-langu... How good the tooling is (maturity, source maps etc) for other transpiled languages may vary a lot but there is still a lot of choice. I'll be sticking to TypeScript for now.
- gefh 10y ago
  Typescript is good, I also like the closure compiler. Both help enormously when a project gets beyond a handful of files. But there's still an onus on developers to actually structure their code and do some 'engineering'; a ball of string in any language is still a ball of string. Not js's fault.
- Hurtak 10y ago
  "There is plenty of languages which compile to JavaScript if you want a different style." I hear this a lot, but when you actually look at the list, there is not much to choose from. - Dart - not used outside of Google. - CoffeeScript - people are leaving this for ES6+, does not provide anything other than nicer syntax. - TypeScript/Flow - is just javascript + types. This is bad because it doesn't solve any of JavaScript problems and good at the same time because it is easy to introduce incrementally and there are 0 problems with interaction with plain JavaScript code). This seems to be good enough for most people, as you mention. - Elm - Second most promising ATM but not mature enough, you still need to fall back to JS for lots of the browser API. You need to buy into the Elm world 100%, simple stuff like creating an element and using JS library which will modify that element still requires hacks (my info might be out of date, last time I worked on Elm project was ~4 months ago). - Reason - Probably the most promising because Facebook backs it, but nowhere near production ready. At least it seemed to me last time I checked - no tutorials, even installation was not straightforward and required some consultation with GitHub issues. - the rest is in the toy/abandoned/not mature enough territory.
cammio 10y ago
yes
bobbytherobot 10y ago
> Could Google or Mozilla build support for another language into their browsers while developers gradually move away from JS? I recall a time when Mozilla was shipping Python until HTML5 kill it. HTML5 gave features front-end developers desperately needed whereas Python honestly did not. > Will developers be open to alternatives? If the alternatives are significantly better at solving their problems, sure. People are switching to React despite React seemingly going against the 20 year paradigm of programing web UIs. Why? Because the pattern works for many people (not all people). > Will we finally standardize on a simpler set of tools and frameworks? Do other languages have a simpler set of tools and frameworks, or they simply better at hiding the complexity from you? In my first programming class, we were shocked to see how a 2kb C source code file was turned into a 200kb executable file by the compiler. I've worked at companies using Java and Scala where I spend my first two days just getting the code to run. Is that tooling really that much easier? > Is TypeScript good enough? TypeScript is just a superset of JavaScript that adds in types. If your only complaint about JavaScript is the lack of types, then sure. I think the JavaScript world is going to get better and worse at the same time over the next five years. I'm certain that we have even more tooling (which many people complain about) around code quality. We aren't going to be just doing static analysis, we will have new machine learning libraries, written in JavaScript, to review code.
- jcranmer 10y ago
  > I recall a time when Mozilla was shipping Python until HTML5 kill it. HTML5 gave features front-end developers desperately needed whereas Python honestly did not. Mozilla never shipped python in its browser. There was an extension called PyXPCOM that allowed python access to XPCOM, which also had an associated variant of PyDOM. PyDOM was apparently never allowed for content (I'm going by https://developer.mozilla.org/en-US/docs/PyDOM https://developer.mozilla.org/en-US/docs/PyDOM), only for chrome. In any case, PyXPCOM was mostly used only by the Komodo IDE.
ams6110 10y ago
Wondering how old you are. Javascript has only been "a thing" in front-end development for about 10 years. Before that, it was sort of a joke. IE used to (maybe still does?) support VBscript. It could support other languages also via ActiveX. I remember articles about how to use Python in the browser. Javascript will fade from the web scene, just as Perl has, when a new generation comes along who will once again reinvent everything with new languages.
- moron4hire 10y ago
  Google Maps was released in 2006, and it was not the first "single-page app". XmlHTTPRequest was invented at Microsoft for Outlook's browser-based client in 1999, and Mozilla had a compatible copy by 2000. The original iPhone was released in 2007 without 3rd party native apps or an App Store, pushing devs to build HTML5 apps instead. Even small consulting firms like the ones I worked at at the time we very interested in JS to "prevent screen flicker" (aka page reload in MBA speak). I think it's a major stretch to say JS wasn't taken seriously 10 years ago.
moron4hire 10y ago
I don't think JavaScript is the problem. It's not the best language, but by far it's also not the worst, and there are lots of alternative tools that keep you from having to touch it. Use Opal, or Coffees riot, or ClosureScript, or Elm, or whatever else is out there; there are dozens. What is much more concerning is the dogmatic, hyper reliance on all-encompassing frameworks, with a commensurate scrabbling for these frameworks to only be made by large corporations. It used to be that you could start a side project on your own, working at a small company, with a decent work-life balance, and grow it into a jQuery or Underscore or Prototype.js and people would even thank you for it. Now, you get people questioning whether or not you should even be allowed to exist if you aren't an official project from Mozilla, Google, or Facebook. Just because a large corporatiom makes a thing doesn't mean it's particularly good. We've all been complaining about how Google's brain-teaser style job interviews are only effective at keeping good programmers who aren't also autodidacts out of the company. Yet out of the other corner of our mouths, we assume anything they make is great just by virtue of them "only hiring the best". I'm sorry, Angular is a pile of garbage. And I mean the rewrite that was supposed to fix all the problems of the first version. Their official documentation's setup instructions are to clone an example repo and delete the parts you don't want. This isn't just unprofessional, it's infantilising. Or the alternative is to install yet another CLI tool for what should just be a front-end library. Every single place they use decorators--which are an experimental feature in TypeScript, so Google is building a core feature on unfinalized syntax--they could have been done with superclasses instead and just kept the whole project to one paradigm. But OOP isn't sexy anymore, and you can't get overqualified PhDs to work on business issues unless there is something to overcomplicate in there. They claim you can't get the live-reloading development server to work on Windows because of something Microsoft supposedly did to block it in January. That's funny. I have no problems with my build and dev tools, and I'm running on top of the same, exact Node ecosystem. But they don't actually explain anything or link to any issue, so there is no telling what they mean. Don't be afraid to "reinvent the wheel", and stop complaining when others do. This search for "the one, true wheel" is what is killing us. Quit trying to take jobs with companies that expect you to know React and Ember. You don't have to learn everything that is out there, and you can stay on one thing for a while. Or you can even make your own things. Your worth as a developer is not in the tools you know today, it's in your ability to learn and solve problems.
k__ 10y ago
probably. But it moved 'to' JS not long ago, so it will probably stay there for a while. I mean, remember the Swing and Qt days, when you needed to wrangle the C++ or Java? JS is a breeze compared to this.
iamgopal 10y ago
I'm sure it will be different. Technology don't usually move upwards gradually. They jump and improve for years and jump again. So I can sense the jump is coming. But it won't be just a additional language on browsers.
lightblade 10y ago
I don't believe we will ever move away from JavaScript. Remember GWT? It's Google's pseudo WebAssembly built at the height of Java's popularity. It compiles your Java code into JavaScript and optimize accordingly to each browser. A few companies bet heavily on this technology, Workday is one. No, it did not catch on.
lenkite 10y ago
Yes, front end development will move away from JS to statically typed languages in 5 years. The fact that JS doesn't have integers and had to invent monstrosities like Uint32Array objects just shows why you do need a sanely typed foundation. Calling JS elegant is like calling a gnarled, slime monster dressed in pink clothes elegant. Ooooooh I have shiny lambdas! Makes me soooo pretty - I can cover my warts and dazzle programmers!
- graphememes 10y ago
  I don't think this will happen, we went from statically typed, to non-statically typed, to statically typed, to non-statically typed. People just have different preferences and that's okay.
33a 10y ago
It'll happen, especially now that WebAssembly is getting rolled out, but not sure what is going to replace it. Things like C++ or Rust are still too cumbersome for a lot of front end development. Not sure what the replacement for JS will be, but something new is going to eventually take over.
ruipgil 10y ago
Quick answer: no. Unless there's a unified effort between major browsers to bring support for a new language we'll have to use js. And that seems highly unlikely (see dart for instance). However, you now have languages that compile to js, that start to satisfy most developer needs, as well as the sketchy evolution of js.
justinhj 10y ago
Consider how long php has been used on the backend, and it's only getting more popular, there's your answer.
jMyles 10y ago
By using the word "ever," you cast this question into historical or even religious proportions. 1000 years ago, the primary frontend toolchains were singleton and handmade: every instance of a piece of data needed to be individually crafted. 500 years ago, the printing press had made significant changes, but frontends were still largely coupled to the available presses and their character sets (let alone niceties like layout and graphics). 100 years ago, frontends still remained tied to their physical layers (ie, it wasn't possible to scrape data and create a new frontend without recreating the entire medium) - ie, books and magazines and newspapers. 20 years ago, javascript was barely known even in programming circles, much less a lingua franca for publishing worldwide. Today, javascript is the control structure by which the vast majority of data is accessed by human eyes and ears. In 20 years, something that has already been invented but is today not largely known might well be responsible for most knowledge exchange. It's completely plausible that technologies like AR, crypto-blockchains, and newly legalized psychedelic drugs will be as important as HTTPS is today for transmission purposes, let alone the particularities of the application layer. 100 years from now, it's highly unlikely that the screen-and-keyboard model of data ingestion will be regarded as anything but a historically important link in data evolution, cast away in favor of more tactile, neurochemical, and cybernetic interfaces. 500 years from now, most of the world's governments, media traditions, and spoken dialects of language will have folded and made way for a completely new condition of humanity. Who knows what the frontend will look like. In a 1000 years, our species might plausibly have no biological footprint (ie, no sensory organs to use for the purposes of distinguishing "frontend" from "backend") whatsoever, and live on as information and knowledge, present in the physical universe only in ways that we can't possible yet imagine. So yes, the species will someday move away from javascript.
- z3t4 10y ago
  When we look back, we recognize that things took a lot of time, but when looking forward we expect everything to go fast ...
- nickthemagicman 10y ago
  Unless as we shed these corporeal bodies and transition into more informational forms of being.. what if the language that creates our informational selves is JavaScript? In other words... What if we BECOME Javascript?
petra 10y ago
If you focus on business apps/sites, you might only need "low-code" tools like outbrain and mendix, which combine domain level focus, mostly visual tools, and maybe some code. Those tools are starting to become pretty successful, and it seems some of the big cloud guys also go in that direction. And who knows, maybe some of those companies will adapt their platform to fit consumers.
igl 10y ago
Do you think java is elegant or do you think ocaml is elegant? Google built Dart once as a alternative and it did not make it into the Browser. Are JS frameworks not simple? I really want to know how you feel about Spring or Magento.
gabrielcsapo 10y ago
Oh gosh, this thread is all purests...I hate es6, but it is kind of fun to watch people misuse the arrow syntax and then ask, so what does that do? Their response is almost 1000000% "oh this is how you write functions in JavaScript bro". That's when I laugh and write a named function and continue working smart instead of trendy winky face. Full disclosure I love JavaScript and will become a farmer rather than switch to another language!
iLemming 10y ago
That's why I like Clojure(script). It does not fight the language and the ecosystem. It's "hosted" - meaning that like a symbiotic organism it "latches" onto the host language and can fully reuse its features. It does not try to "reinvent" and fix what's not broken, yet at the same time liberates you from glaring awfulness. It enforces certain discipline to protect you from shooting yourself in the foot.
krystiangw 10y ago
So far browsers hasn't found nothing better than Javascript. Beside it is grownig not only in browsers now. It seems that Javascript is required in 30% of the job offers now: https://jobsquery.it/jobs;tags=Javascript https://jobsquery.it/jobs;tags=Javascript https://jobsquery.it/stats/language/group https://jobsquery.it/stats/language/group
gibbitz 10y ago
I fear a WebAssembly rise of Swift as the new Javascript running in iOS, WebAssembly and server environments. I tend to agree that ES6/7 is a more elegant option and more in the spirit of OSS these days, but the backing of Apple on Swift could lead our stacks that way (though not with anywhere near the permanence that JS has had). Pure conjecture, of course. Either way, I couldn't see webAssembly as a replacement for just page logic though. It would be replacing the whole front-end stack...

StavrosK 10y ago
Class methods don't accept a "self" argument, though. In those cases, you call it cls.
- scriptkiddy 10y ago
  I'm aware. The `self` vs `cls` thing is convention. You can call either argument whatever you want.
mschuetz 10y ago
It's not that it's confusing, rather it's unnecesarrely cumbersome because it's explicit and because you have to put it as an argument. Looking at the "most used words" [1] list of python, self is the #1 used word by far, occuring three times as often as the second most common word, "if". At this point, it's just a filler that bloats code and makes it less readable in many cases # so much text for such a little task def length(self): return math.sqrt(self.x*self.x + self.y*self.y + self.z*self.z) # better, but not quite there yet def length(self): return math.sqrt(self.x**2 + self.y**2 + self.z**2) # this would be perfect, but it's not allowed by python def length(): return math.sqrt(x*x + y*y + z*z) To be fair, javascript also forces you to explicitly specify "this" so there is no difference in that regard. What I find worse than that is that you have to specify self in the parameter list. Calling a function with 2 parameters but having to declare 3 doesn't make sense. The usuall reasoning is that "explit is always better than implicit" but I do not agree. We could take this philosophy all the way to explicitly defining all the global variables that may be used by the function in the parameter list, maybe even all the packages that this function is going to use. We don't do that for a good reason. [1] https://anvaka.github.io/common-words/#?lang=py https://anvaka.github.io/common-words/#?lang=py
- scriptkiddy 10y ago
  > It's not that it's confusing, rather it's unnecesarrely cumbersome because it's explicit and because you have to put it as an argument. I don't feel the same way. To each their own I guess. Regarding your example, I don't see anything wrong with the second version. Anyone who reads the code will easily be able to tell what it does and where the variables come from. In your third example, how is anyone supposed to know whether or not `x`, `y`, and `z` are class variables or global variables? Kind of defeats the purpose of namespacing, I think. > What I find worse than that is that you have to specify self in the parameter list. This is really one of Python's implementation details. Methods can be bound or unbound. Without going into to much detail, just know that a bound method can be used as a regular function. Here is some code to illustrate what I mean: >>> class A(): ... def a(self): ... print('hello') ... >>> A <class '__main__.A'> >>> A.a <function A.a at 0x7fc4009381e0> >>> A.a() Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: a() missing 1 required positional argument: 'self' >>> A().a() hello >>> b = A() >>> A.a(b) hello >>> class B(): ... pass ... >>> b = B() >>> A.a(b) hello >>> class B(): ... def a(self): ... print('goodbye') ... >>> b = B() >>> A.a(b) hello >>> c = A() >>> B.a(c) goodbye Self does not have to be the same class it's called on. It can be any class. However, if you try to access a class attribute that doesn't exist, you get an attribute error. >>> class C(): ... x = 10 ... def a(self): ... print(self.x) ... >>> C.a() Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: a() missing 1 required positional argument: 'self' >>> C().a() 10 >>> a = A() >>> a.a() hello >>> C.a(a) Traceback (most recent call last): File "<stdin>", line 1, in <module> File "<stdin>", line 4, in a AttributeError: 'A' object has no attribute 'x' Since bound methods need to behave like regular functions, it is improper to not pass the object instance to the function.
- pwdisswordfish 10y ago
  Saying it's unnecessary is incorrect, and I don't agree about it being cumbersome either. On the first point, how would you disambiguate between reading from an attribute and reading from a global (or non-local) variable? How would you disambiguate between assigning to a variable and assigning to an attribute? You'd have to explicitly declare all your variables (making other things cumbersome instead) or accept that the semantics of your program could change during run time, depending on the contents of outer scopes (which I doubt you'd find an acceptable option). This is the main reason the 'with' statement is deprecated in JS. C++ can get away with implicit 'this' because it has static dispatch and all variables are explicitly declared anyway. But truth be told, I'd remove it from C++ too if I could. I like the clarity of knowing at call site whether something is a function or a method call without having to look it up. Paying for it the price of having type a few more characters has never bothered me. And I somewhat like that I can name my 'self' argument whatever I like instead of having to resort to obtuse workarounds like 'var that = this;'. Not that I've ever had the need to take advantage of that possibility in Python, but it's comforting to know it's there.
- Sohcahtoa82 10y ago
  In a short function that makes a lot of references to self, yeah I agree in can be a bit cumbersome. But as the functions get longer, I much prefer the explicit use of self. It makes the code far more readable as you can tell at a glance where a variable comes from.
deleted 10y ago
[deleted]

BinaryIdiot 10y ago

> Yeah, like dealing with "this" keyword This can get a little confusing until you understand how context works. Then it makes sense but you know what? You don't always need to use this. In fact you can build entire applications in different ways without ever using this. And no writing without using this doesn't make your code ugly or unmanageable. There are just many ways to get the same or similar things done in JavaScript. > type coercion in JS Type coercion is ugly in any programming language. It's best to avoid it, even in JavaScript (which you can do, btw).

giomasce 10y ago
The problem with type coercion is when it happens without you noticing it. You cannot "avoid" it...
- BinaryIdiot 10y ago
  Sure but this problem is inherent to any dynamic language. I find other issues far worse than simple type coercion. What about calling a function? Most dynamic languages will let you pass in any number of parameters regardless of its definition and you may not even notice. You can avoid type coercion if you understand how the language works (aka strict equality in JavaScript) but this isn't something only in JavaScript land either.
  - dozzie 10y ago
    > Most dynamic languages will let you pass in any number of parameters regardless of its definition and you may not even notice. Python will throw an error. Ruby will throw an error. Tcl will throw an error. Erlang will throw an error. I believe most of the Lisps will throw an error. What was it about "most dynamic languages"?
    - BinaryIdiot 10y ago
      > What was it about "most dynamic languages"? I should have changed my text to not say "regardless of definition" because you can do that in Python, Ruby, PHP, JavaScript, etc. Python and Ruby support it through (star)args or default parameters JavaScript supports it regardless PHP supports it regardless We can argue semantics or the fact that some of those types of errors can be caught with some subset of dynamic languages but I don't think that's useful. My only point was when comparing a dynamic language with a static language I find variable function parameters to be one of the bigger issues over type coercion. But that's just, like, my opinion.
      - deleted 10y ago
        [deleted]
      - kbp 10y ago
        Those aren't particular to dynamic languages, though. You can add C, C++, Java, and C# to your list of languages that support it. Being able to explicitly make a parameter optional, or to have a 0-or-more rest argument is different from how function application works in Javascript or Perl because you have explicitly made that part of your function's signature, and the language still checks calls against that signature.
  - mazelife 10y ago
    There are two separate issues in play here. You're conflating the static/dynamic dimension of language classification with the strongly-/loosely-typed dimension of languages which is what the poster you are responding to was talking about [1]. These two dimensions are orthogonal: languages may be static, but weakly typed (like C), or dynamic but strongly typed (like Python). I'll allow that there's inevitably some degree of opinion involved here, but I tend to agree with the parent poster that implicit conversion in languages like Javascript, PHP, and Perl is just another vector for bugs, and outweighs any of the advantages you get from having your language coerce everything for you. But then again, i'm one of those people that likes my language to force me to be very explicit about what I mean, so YMMV. Regardless, the strict equality operator is not at all sufficient to avoid the dangers of JavaScript's implicit conversions. Pretty much _all_ the operators are going to coerce types for you, whether you meant for them to or not. For example, this function: function increment(i) { return i + 1; } Adds one to number right? But let’s say you’ve neglected to convert some user input in a form to a number as you should have done elsewhere in your code, and you end up calling increment("1"). This will return "11". So now you potentially have introduced a serious math error into your code you may not notice right away. Conversely, if you did this in Python, the function would have raised a TypeError immediately, because you can’t apply the arithmetic operator to two different types. You can’t just “avoid” type coercion in these loosely-typed languages by understanding the specifics of how it works, because you may not even know it’s happening until you start seeing unexpected results somewhere. [1] https://en.m.wikipedia.org/wiki/Strong_and_weak_typing https://en.m.wikipedia.org/wiki/Strong_and_weak_typing
  - lispm 10y ago
    Most Lisp compilers will warn about wrong number of parameters at compile-time. Lisp typically warns at runtime, too.

coldtea 10y ago

It's not just CSS that sucks, it's the whole, totally arbitrary, web UI stack. Unlike with desktop apps, everybody pretty much builds everything in the UI for themselves, with the exception of a handful of primitive items (button, radio-button, text-field, etc) that people still re-implement anyway. If there was a set of rich widgets to just take, configure and use in your JS app, like you can in Cocoa, Windows Forms, etc, it would be great. And no, React is not that.

graphememes 10y ago
Have you ever sat down and read the reasoning for why things are the way they are? Why the accessors can't / don't go traversing through it's parents and only goes down? It feels like many people who argue against these things are only the ones using them not the ones developing them or actively interacting with the repercussions of those developments. It's a completely different world when you're creating something and using something. One person might use that thing vastly different than how you would and the repercussions of their implementation can do a lot of damage to others. Something to keep in mind.
- coldtea 10y ago
  You say it as it is some huge mystery, but we've had good UI platforms for ages, that have been way better to work with than the web ui stack. The web implementations doesn't follow some inherent constraints of UIs, they are designed this (bad) way because they need to work with the pile-up of hacks upon hacks, and design by committee that is the web stack. JS, for example, is not bad because there were some great domain constraints -- it's bad because as it's creator says, he had a tight deadline to go create it, alone, in a couple of weeks -- and had a design spec to make it look like Java as much as possible too. CSS is not bad because layout is inherently difficult. It's bad because it started like a pure styling solution, and all kinds of hacks were piled to make it useful for layout (abusing the floating functionality, which was not meant as a layout solution). It took 20+ years to get to CSS Flex and Grid layout -- features that have been in desktop UI libs since forever... And if forms have seen any love from the beginning, we'd have things like inter-changable re-usable components 20+ years ago, without the BS that is Web Components and the extra hacks like Shadow Dom etc. But they didn't even bother to add a few standard widgets like calendar in all those decades.
  - graphememes 10y ago
    > You say it as it is some huge mystery, but we've had good UI platforms for ages, that have been way better to work with than the web ui stack. Not as broad reaching as JS/CSS/HTML. > The web implementations doesn't follow some inherent constraints of UIs, they are designed this (bad) way because they need to work with the pile-up of hacks upon hacks, and design by committee that is the web stack. They were made to fit the growing needs and have done remarkably so. > JS, for example, is not bad because there were some great domain constraints -- it's bad because as it's creator says, he had a tight deadline to go create it, alone, in a couple of weeks -- and had a design spec to make it look like Java as much as possible too. Doesn't make it bad. Made it lean, portable, ultimately an easy to use language. There have been many languages in the browser. > CSS is not bad because layout is inherently difficult. It's bad because it started like a pure styling solution, and all kinds of hacks were piled to make it useful for layout (abusing the floating functionality, which was not meant as a layout solution). It took 20+ years to get to CSS Flex and Grid layout -- features that have been in desktop UI libs since forever... Progressive enhancement is a large part of software engineering and doesn't make something bad. Users of software abusing the software doesn't make the software or implementation bad either, they simply are adopting to the situation they are in. Yep, and the result of those libraries and implementations gave us what we have now across not just a single platform but multiple platforms and distribution models. Modern achievements. > And if forms have seen any love from the beginning, we'd have things like inter-changable re-usable components 20+ years ago, without the BS that is Web Components and the extra hacks like Shadow Dom etc. But they didn't even bother to add a few standard widgets like calendar in all those decades. Except, you can do those things, and that does exist. Just check out bootstrap v4 it has html5 calendar support, just off the top of my head. Shadow dom was an experimental phase to improve performance, it worked out, taught a lot of engineers a lot about not just Javascript & DOM but the browser, it brought about a lot of beneficial tooling and lead to Native applications. We had interchangeable components for a very long time, riding on bleeding edge doesn't change that fact.

bruce_one 10y ago

There are many popular dynamically typed languages. Why is it suddenly a foregone conclusion that seasoned Javascript developers all want compiled statically typed languages?

golergka 10y ago
I know that it's a very old argument that I'm not going to win. But I would like to provoke you to it because I'm really trying to change my mindset, coming from a static language to Javascript - and I still just don't see, where are the wins. Please argue with me, because I _want_ to be convinced. I'm trying. It may be because of the habits I developed, writing compiled code. I always would first concentrate on my concepts, things that I want the code to do, data and flow structure - while keeping all errors (even syntax) silent. And only when I got everything I wanted implemented and consistent, I would turn to a compiler to quickly fix all mismatches in API, all wrong method names and other trivial blunders. Now I stumble, feeling that I'm a blind man going through a minefield. Every line I write, I have to think about the things that I want to express and the mechanics of language and API simultaneously - because nothing's got my back. (Yes, I know that I should write unit tests, but not all of us have the luxury of working on perfect projects, starting perfect projects from scratch, or having the resources of putting good practices into legacy code). Every time I discover that I mistyped the name of the function or variable, forgot to use "this" when referring to an object property (C# habit), forgot that external API function returns a custom type and not a string - I do it too late. Instead of quickly fixing the thing that I've only typed right now, I have to go back, and spend time reading and understanding relevant code again. All I'm trying to understand is, where are the trade-offs? Where are all the awesome dynamic things that make all that worth it?
- bruce_one 10y ago
  It's alright, I have no interest in an argument :-) I like Javascript, and that's enough for me - and I (in _most_ situations) find dynamic typing more of a benefit than hindrance; but I don't mean to purport that my perspective is everyone's perspective :-) IMO it's very plausible that dynamic typing will never be better for you; because we're all different and we don't all like the same thing. If you've come to learn that dynamic typing doesn't suit you, act accordingly, don't just try to change yourself because something else works for others. If you're interested in static typing, maybe try moving to Typescript? AFAIU it also integrates fairly well with normal Javascript, and hence maybe it's more to your taste? And if there are other people feeling the same way you are on your projects, it mightn't be too difficult to move new (or maybe a subset of new) development to something more your taste instead? (I've heard good things about Flow as well, and maybe it's simpler to "sneak in" to your projects, and offers big enough benefits for you?) In my experience, legacy projects (or projects where there's pressure to cut corners (eg unit tests)) are often the bigger issue than the language. (eg I've been "in pain" working with code in languages I otherwise like that was obviously done in a big hurry, or evolved obviously from clumsy requirements and hence has big inconsistencies. (As an actual example of a reason _that applies to me_, the last Javascript project I worked on ran the integration tests faster than the last compiled statically typed project compiled (and reloaded) - hence I ran the tests in a watching process, and felt more productive and less frustrated. And yeah, I haven't written `this` for a very long time :-p )
- chubot 10y ago
  I wrote on my blog about some of the annoyances that come with type checking: Type Checking vs. Metaprogramming: http://www.oilshell.org/blog/2016/12/05.html http://www.oilshell.org/blog/2016/12/05.html http://www.oilshell.org/blog/2017/01/21.html http://www.oilshell.org/blog/2017/01/21.html (at the end, pretty printing requires metaprogramming, or escaping into another language) Whenever you have a code generator like an ORM, or protobuf-like schema languages, you can use metaprogramming instead. Generally I think this helps the program so you don't have these impenetrable walls between layers, where one person understands one side and the other person understands the other. I find that a lot of programmers coming from statically typed languages are writing Java in Python, or Java in JavaScript. In Java you don't really think in terms of metaprogramming. If that's the case, then it is going to feel annoying. You're getting all the downsides without any of the upsides. I would look at Go for other examples of the downsides -- namely the lack of generics. Go is attracting a lot of Python and Ruby programmers. In Go, you can't write basic generic functions like max(), map(), filter(), and sort() -- in JavaScript and other dynamic languages this is not something you would think twice about. I guess between metaprogramming and generics, dynamic languages let you write more abstract and concise programs. Programming in statically typed languages feels repetitive to me, and the architecture is quite clunky unless you are doing textual code generation. Steve Yegge also has a bunch of good posts about dynamic languages. Thanks for the honest question. I think it's important to remember that there are tradeoffs. I fully admit that type checking is useful in many circumstances. I would like the best of both worlds. I'm a little disappointed that recent hybrid languages like Dart and to some extent Racket have had problems with optional typing and gradual typing. It is something I'm interested in but it seems like an unsolved problem.
  - golergka 10y ago
    I can see benefits of metaprogramming in quite a few very specific tasks - but most of developers who are using Javascript day in and out aren't writing compilers. We're writing business logic. And because this logic comes from human, fuzzy rules, to accurately represent all the corner cases and not drive the code into a globe of insane parameters and checks, one have to get into a mindset of _not_ trying to generalize things. Thanks for "When Polymorphism Fails" link, it was a wonderful read. I've actually run into such situations a couple of times - but in my experience, you want most of your methods to be statically checked, and only a minority of them to be added and checked dynamically in runtime. May be the solution is to have two different method tables, that look and behave in a different way?
- phyller 10y ago
  There are linting tools that you can and should add to your text editor of choice. Whenever I reference a variable in JS, if that variable is not assigned it highlights it as a possible error. If I define a variable or function and don't use it, that gets highlighted too. If my syntax is wrong, that gets highlighted. If my team had decided that we only want to use single quotes around strings, that gets highlighted. Even our build will complain and our tests will fail because we have incorporated linting into them. With ES6 there is no reason to have global variables anymore, so it is possible to confidently identify all these errors before the code is even run. The language is constantly being improved while maintaining backwards compatibility. Finally it's ability to handle whatever kind of data you throw at it until you choose to check the data is a strength in an environment (web pages) where nothing is certain. You aren't sure about the data you will get from an API, from the user, you don't even know what kind of environment your code will be run in! The same code might run on the latest version of Chrome, a headless test environment, or some old version of Internet Explorer. And that is totally possible. It's all up to how you code it. And you have to get used to coding in this type of language. You can and should test your code as you go along, no need to wait to compile, you can see the results right away. Build your code to handle errors, because even if the code is perfect, the data you are working with will not be. And have lots of tests. Not only do they identify current errors in the code, but they allow you to make large changes with confidence that everything else is still working like it should.
  - douche 10y ago
    You're bolting on an optional, incomplete compiler to make up for the shortcomings in the environment. I jist can't deal with the sloppy wild west way Javascript world works.
- to3m 10y ago
  The trade-offs are that the language implementer has an easier time of it (once), then every programmer has to expend extra effort writing the code (a lot of the time), the computer has to work harder running it (every time), and code browsing/refactoring/etc. tools are literally never, not even in theory, going to work 100% perfectly. Now, if you're writing a programming language, this probably seems pretty awesome...
- z3t4 10y ago
  i rarely think of types when writing JS. where something is not obvious, like i forgot if it returned a string or object i write an error that will throw if my expectations are wrong. i call them sanity checks. also where something is not obvious you want to rename it so it becomes obvious. so you kinda replace type annotations with better easier to understand names.
  - to3m 10y ago
    Dude.

pjmlp 10y ago

We hate JavaScript, because writing the code below is a perfect valid way of calling alert(1). [][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]][([][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]])[+!+[]+[+[]]]+([][[]]+[])[+!+[]]+(![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[+!+[]]+([][[]]+[])[+[]]+([][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]])[+!+[]+[+[]]]+(!![]+[])[+!+[]]]((![]+[])[+!+[]]+(![]+[])[!+[]+!+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]+(!![]+[])[+[]]+(![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]])[!+[]+!+[]+[+[]]]+[+!+[]]+(!![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+ [])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]])[!+[]+!+[]+[+[]]])()

jaredsohn 10y ago
That's a feature if most of the keys on your keyboard are broken. :) Seriously, it is not a good reason. Just don't write code like this nor allow other people in your team to write code like this. Fortunately, this kind of code is unlikely to be written by mistake so it is easily avoidable.
- pjmlp 10y ago
  That was just one example, there are lots of other WATs. As for team, in enterprise consulting, the concept of team is very shallow.
  - scriptproof 10y ago
    I initially believed it was a sarcasm!
smonff 10y ago
Why would you ever write such a thing?
- krapp 10y ago
  It's an effective way of obfuscating malware, for one thing.
  - kwhitefoot 10y ago
    Surely not. It would be easy to spot.
    - chc 10y ago
      Obfuscation doesn't necessarily need to be hard to spot, just hard to understand. Like, could you spot this in a chunk of minified code? Probably. Would you be able to figure out what was going on? Probably not without some difficulty.
      - kwhitefoot 10y ago
        If it's hard to understand like that then I would be automatically suspicious of it.
- CognitiveLens 10y ago
  You wouldn't. The argument is so straw-man that it verges on trolling.
  - coldtea 10y ago
    Actually you don't have to write such a thing to get the same BS behavior, and it's not a strawman at all. It's just a side-product of JS god-broken coercion rules and types, and those affect every statement one writes, down to the suggestion to use === instead of == for the most fundamental thing any language does: equality comparison. The example is just meant to showcase how far the brokeness can be taken...
    - kls 10y ago
      Actually I like the ability to == all known ducks. There are a lot of cases that we run into like a DB that we have no control over where they use null, '' or 0 as some form of indicator of no value, it's nice to be able to ignore all of those cases when one does not have control over the quality of data coming in the pipe. I tend to favor the mantra of be a liberal when consuming data and a conservative when exporting data and I find the == vs === does that very well. Sure it's a gotcha but no big surprise to most people that have been doing JS for any amount of time. I personally think it is a brilliant feature that save a lot of boilerplate when one understands the difference.
chrisfosterelli 10y ago
These same obfuscations exist in many, many other languages.
- steego 10y ago
  I imagine they hate those other languages too. You do know there are many, many languages where that sort of obfuscation lay between difficult to impossible, right?
lazerwalker 10y ago
Are you familiar with Gary Bernhardt's talk "Wat"? (https://www.destroyallsoftware.com/talks/wat https://www.destroyallsoftware.com/talks/wat) I don't think it's that productive to judge a language on the worst features and edge cases that most teams will be able to easily reach consensus on avoiding, as every language will have its bullshit.
- coldtea 10y ago
  >I don't think it's that productive to judge a language on the worst features and edge cases that most teams will be able to easily reach consensus on avoiding Only those edge cases merely expose functionality that can burn programmers on an everyday basis, like coercion rules. It's not something that you have to get out of your way to get.

fvargas 10y ago

I think ES6+ has done wonders for JavaScript and has made it a highly expressive language. It's true there are quirks and poorly designed aspects which can be confusing at first glance. But like with any language, once you understand how it works, you learn to work with it. Moreover, as the language continues to improve, many of those quirks become irrelevant. It's important to understand that, by virtue of having been bestowed with a monopoly over the web, JavaScript holds a great deal of leverage as a language. If you want to develop for the web, you pretty much have to adopt JavaScript into your stack. It's no surprise, then, that Node became so popular. Being able to use that language you're forced to use for the client on the server and to run the same code has major benefits. The Node and npm developers got many things right to be sure. But Node and its ecosystem, by virtue of offering JavaScript, benefitted immensely from developers' desire to unify a previously disjoint part of their stack. I find myself asking instead, how far will JavaScript's reach continue to stretch? Electron and React Native have become extremely popular. It's not just speculation, there is undeniable momentum.

erikpukinskis 10y ago
I think ES6 is the worst thing that ever happened to JavaScript because it killed it's best feature: being a small language that runs everywhere. Now when I want to use a JS library, I have to think: what is this author's philosophy about language extension? Are they going to start using some new feature that some other library I depend on is incompatible with? You used to be able to run JavaScript anywhere on any device. Think about how powerful that is. We sacrificed that for supposed gains in "ergonomics". People hate callbacks. People hate "this". But if you ask people who really learned how to use those things, they're not problems at all. They're only problems if you're coming from Ruby. It's like someone took an Apple and said "this is gross, it's not juicy and tangy like an orange!" And then they soaked it in vinegar and wrapped in orange skins. Now it scores well on orange-ness but is that a virtue?
- ng12 10y ago
  Who's writing native ES6 code? Support for IE8 is just now starting to slip in the community (due too old, mundane things like Object.defineProperty). Almost every package on NPM targets ES3. Also, IE never ran everywhere. Targeting IE8 is hard, targeting IE6 was a nightmare.
  - geuis 10y ago
    I can't speak for you, but I've worked at a few companies and done some contracts overs the last 5 years and supporting ie8 easily stopped around 2012.
    - ng12 10y ago
      Microsoft ended support for IE8 early 2016. Until then most open-source libraries supported it. I wrote an IE8-compatible application this year and only had to downgrade a few random libraries.
- StavrosK 10y ago
  I see this misconception a lot in this thread. "Yes, people say the language has problems, but there are people can work around the problems, so they aren't really problems!" The very fact that you need to learn to work with X means that it's a problem. Otherwise, all languages are just fine.
  - z3t4 10y ago
    everything is stupid if you dont understand it. JS is pretty good at not getting in your way.
    - coldtea 10y ago
      >everything is stupid if you dont understand it. Some things are stupid even after you understand them, and JS has plenty of those, as its creator and its greater evangelizer both admitted.
    - StavrosK 10y ago
      There is no "stupid" and "clever". There's only "consistent" and "inconsistent". JS isn't very consistent.
- frogstomp19 10y ago
  I really don't agree, as a developer writing predominantly js. It's still pretty standard to compile es6 down to at least es2015 using babel or typescript, meaning js still runs everywhere. I've also literally never met anyone who thinks that callback-structured code is "not a problem". And you can work around issues of "this" and lexical scoping to the point where it isn't as irritating, but it's completely unintuitive to a new js developer, and IMO at least never stops feeling "wrong". There are also a ton of features aside from arrow functions and promises that completely change the way code is written for the better- off the top of my head I use ` string formatting, classes, let/const declarations, and module loading every day.
  - erikpukinskis 10y ago
    > It's still pretty standard to compile es6 down to at least es2015 Yea, but that means if I want to use your library, I need a build chain. It used to be I could just do require("you") or <script src="you"> and be done with it. That's what we lost. Actually I need n buildchains, one for each npm module I use. And they better all be compatible and target at least one common runtime. And that better be a runtime I am comfortable deploying for my app. > I've also literally never met anyone who thinks that callback-structured code is "not a problem" Well here I am. Pleased to meet you. Might I also point you at: http://callbackhell.com http://callbackhell.com There are many of us. I think what this really shows is how much professional ES6 programmers live in a filter bubble. This also explains why you think "just transpile" is a reasonable substitute for a simple, run-anywhere language. Professional ES6 programmers think everyone has 40 hours a week of paid time to spend maintaining a build chain. Javascript+Node used to be one of few languages that you could use without a build system. That's no longer the case. Maybe the loss was worth it to you. Fine. Makes sense. I wish more people would just acknowledge something has been lost, and that amateurs are struggling now at the expense of pros.
    - djmashko2 10y ago
      I think you missed that the parent meant that libraries are compiled _before_ publishing. So even if the library is written with ES6 you can simply require it with no build setup.
- deleted 10y ago
  [deleted]
- woah 10y ago
  What are you talking about? ES6 transpiles down to ES5, and this is what people publish libraries as. The language version compatibility story is way better than it is for most languages.
- tracker1 10y ago
  Well, jQuery is the single most popular JavaScript library ever, with over a decade under its' belt, and going to be around for likely another. Its' style was not predefined by the JS language... It has a monadic style in nature... Likewise, JS didn't prevent coffee-script or transpilers... That said, I still feel that not sending the event registration context (not just the target) in with the event is a mistake... escalated by the use of fat-arrow functions today. You never know where things will go. As to callbacks, I think it provides a great base... allows for easy extension and progression. I do now prefer Promises where async/await is available or via babel. Java 8 isn't the same as Java 3... it's changed... languages evolve, and JS has done so rather rapidly the past 6+ years... It looks to be settling in a bit now. Next will be the module support, and that shift will be more painful than everything that came before. I don't mind the context class sugar... there are places where it makes sense, and far cleaner than the prototype syntax. I tend to only use it for UI components, and even then sparingly. Just the same, other parts of ES6+ have been incredibly great.

devwastaken 10y ago

>I think instead the real issue is that we're too bad at educating people in how to properly use the language. I don't think this is true at all. I think over time it becomes very easy to apologize for the environment we're forced to use, because there is no comparison, we only have JS for the web. In any decent project, you're going to have hundreds of 3rd party dependencies installed from tons of sources, some of which could freely introduce exploits into popular programs at any time. If any of these break, you're going on a long hunt to track it down, ultimately to be met with authors that aren't responsive or some bug caused by god knows what incompatability. We're stuck between the ever flowing battle of new language constructs and languages ontop of JS that try to make it 'easier'. JS lacks very important things that devs have found to be necessary, like typings, and even trying to add typings is a huge battle in itself, that again, is ever changing. Just try and google for where you should put your .d.ts files, and you'l get 4 different answers, all from different stages of versions and recommendations. You can't teach JS. You can only say that things never stay the same, so build things fast and break them quicker. What you consider 'properly' today, is tomorrows bad practice.

woah 10y ago
You can put //@flow at the top of your files and install a plugin for your editor and have typing in about 30 seconds.
- devwastaken 10y ago
  See, thats the thing though. There's so many ways to do something, with multiple competing standards on how to do it, along with plenty of quirks and ways of working with it you only understand by experience. This is good, when you already know exactly what you need and what that provides, but its impossible to keep up unless you're spending a lot of time testing and researching, and even still, at the end of the day you've gotta make the application. One of those 'it takes a village' to make a good JS app.
  - gabrielcsapo 10y ago
    a village?! Come on healthcare.gov ...