10 ms·

Programming languages are tools, what matters is if they do their job. And the current popularity of javascript means it works for most people. But boy, how ugl

• gentleman11 5y ago
  If people didn’t like JavaScript for front end work, it’s not like they could just switch to python
  • globular-toast 5y ago
    I use both JS and Python for work and not a day goes by where I don't wish history had taken a different course and Python had ended up embedded in web browsers.
    • paozac 5y ago
      Or Lua
      • fit2rule 5y ago
        This, a thousand times.
    • qbasic_forever 5y ago
      There was a strange time in the dark days of IE6 dominance 20 years ago that you actually could write page scripts in non-javascript languages. VBScript was a big option that some people used, and IIRC there was a way to get python support in IE (and Windows) script host too. When I was first learning Javascript in ~1998 I remember all the docs showed how to do stuff in both JS and VB script tags: https://stackoverflow.com/questions/17483782/vbscript-support-in-internet-explorer-11 https://stackoverflow.com/questions/17483782/vbscript-suppor...
  • garyrob 5y ago
    This brand-new book on using Python (via Transcrypt) in the browser to build a React app may be helpful in that regard: https://pyreact.com https://pyreact.com. Just started reading it. Seems very good so far.
    • gentleman11 5y ago
      Is the result ie 11 compatible and performant? Honestly curious
      • Master_Odin 5y ago
        MS products are going to stop working with IE 11 come August, seems like it's time as an industry to force its retirement on any holdout managers.
  • bobthepanda 5y ago
    WASM is supposed to unlock non-Javascript for the browser, no? Also there have been attempts before but nothing really stuck. How many non-Googlers use Dart?
    • irrational 5y ago
      No? WASM doesn't replace JavaScript. Think of it as a high-performance library that JavaScript can make use of.
    • echelon 5y ago
      You can write Rust for the frontend right now. It's pretty neat. Yew [1] is one of the early Rust frameworks for client side work. It allows for multi-threaded (!) execution and javascript interop. Not many other languages make sense as you have to pack in the whole runtime, GC, etc. Rust is pretty well positioned for WASM, and it's going to take off soon. [1] https://github.com/yewstack/yew https://github.com/yewstack/yew
  • aphextron 5y ago
    >If people didn’t like JavaScript for front end work, it’s not like they could just switch to python Sure you could. You can develop for the web in practically any language you like these days. People use JavaScript because it has native support for the DOM that nothing else can match. Until we get away from the DOM for application development, it will always be king.
    • roofwellhams 5y ago
      Try to debug that nightmare. Usually you'll need to debug compiled code.
      • gentleman11 5y ago
        Do sourcemaps not help? I’m not experienced with python to js, but they help with minified js
        • roofwellhams 5y ago
          Can, but they won't match and you can't break point exactly the same as in just js or ts
    • magila 5y ago
      That has nothing to do with Javascript's merits as a language though. It's simply the only language browsers expose the DOM to natively.
      • aphextron 5y ago
        >That has nothing to do with Javascript's merits as a language though. Sure it does. DOM support is built into the very core of JS as a language, and that has shaped the entire history of its' development and subsequent API choices. It's not just a library that it happens to support, the way it would be with any other language.
  • tshaddox 5y ago
    Can’t easily write Django code in JavaScript either. In general it’s not like working programmers get to choose any programming language whatsoever for the hardware and platform they’re writing software for.
    • pessimizer 5y ago
      You don't have to use Django (you can choose one of the billion alternative CMSes), but everyone has to use a browser. Hell, Django itself has to write javascript.
      • sirsinsalot 5y ago
        Django is not a CMS
  • ironmagma 5y ago
    There are a wealth of alternatives though... ClojureScript, Elm, ReasonML, and Purescript just to name a few.
  • dragonwriter 5y ago
    > If people didn’t like JavaScript for front end work, it’s not like they could just switch to python Sure, they can, both via compile-to-JS solutions like Transcrypt [0], and via generate-the-frontend-with-backend-Python solutions like idom [1], Plotly Dash [2], and others. [0] https://www.transcrypt.org/ https://www.transcrypt.org/ [1] https://idom-docs.herokuapp.com/docs/index.html https://idom-docs.herokuapp.com/docs/index.html [2] https://dash.plotly.com/ https://dash.plotly.com/
    • ad404b8a372f2b9 5y ago
      That's not a solution if you end up with Javascript in the end. (Also Dash is absolutely terrible, horrible documentation, horrible code.)
      • vbsteven 5y ago
        Why is that not a solution? The concept of compiling/transpiling a language into the target language for the runtime is everywhere. Even native languages like C/C++/Rust compile their language into binary format that the platform can run. It just so happens that the web runtime format is JS instead of binary machine instructions.
        • HideousKojima 5y ago
          Because debugging your transpiled JavaScript becomes a nightmare in a language you already hate
          • dragonwriter 5y ago
            > Because debugging your transpiled JavaScript becomes a nightmare in a language you already hate That’s what sourcemaps are for; you don’t have to debug compiled instead of source format on the web just like you don't on other platforms.
      • dragonwriter 5y ago
        > That's not a solution if you end up with Javascript in the end. ( It is, just as using compile-to-(or interpreted-by-a-runtime-in-)-native-code languages is a solution to “I don’t like raw x86_64 machine code for desktop applications”, even if you end up running machine code in the end. > Also Dash is absolutely terrible, horrible documentation, horrible code. “X is not a choice people can make” is a different claim than “One example of X is not something I personally would recommend”.
• nsonha 5y ago
  Example of inconsistencies? comparing to what? If you're gonna cherry pick some outdated es5 to make that point, dont bother.
  • makapuf 5y ago
    Iterating over an object keys, an array or a map?
    • kingdomcome50 5y ago
      I would expect, given you have described an operation on 3 different data structures using different words, that it would also demand 3 different kinds of syntax/denotation no? Your own language requires as much. Why not JS?
      • makapuf 5y ago
        Well in python by example you use for x in myobject to iterate and that's it, no Object.entries(myobj) vs. mymap.entries , lua is even more consistent, ..
        • stevula 5y ago
          It’s not uncommon in Python to iterate through dict.items() (or dict.keys()) which is basically the same thing.
        • nsonha 5y ago
          Hey what about map and comprehension? This is a language that claims to value "one way to do things"
    • deleted 5y ago
      [deleted]
    • frankenst1 5y ago
      let obj = {a:1}, arr = [1], map = new Map().set("a",1); // Iterating over an object keys for (let x of Object.keys(obj)) {...} // an array for (let x of arr) {...} // or a map? for (let x of map) {...}
• Waterluvian 5y ago
  I started just despising JS. But with discipline and a well-configured linter, formatter, and ideally using Typescript, I've found it to become my favourite language. Doesn't mean I'm saying JS is inherently beautiful. But if you ignore the bad features and do a little setup, it has the potential to be wonderful.
  • Cyberdog 5y ago
    So many people are bringing up TypeScript here as an example of how JavaScript isn't so bad. I kinda feel like that's cheating. Like saying eggs are absolutely delicious when baked into a cake - you're praising something after it has been turned into an entirely different product. Maybe TypeScript is great, but I just don't like the idea of depending on transpilers to not suck when creating the final code, and also having to debug that transpiled code, and then the whole transpilation step in between the standard command-S-command-tab-command-R workflow (this is also why I never use SASS/LESS if I don't have to). Once JS itself has strict typing and real classes, and enough time has passed that I can be assured 95% of people using five-year-old browsers will be able to use it, then we can talk about the wonders of JavaScript. Until then I don't get why anyone would use it (or anything that transpiles to it) when there are so many better alternatives for server-side development. Let's not even get started with Electron.
    • osmarks 5y ago
      Why is the transpilation step an issue? You can set it up to happen whenever the file is changed with most things.
      • cesarb 5y ago
        Because it's no longer the same language. You're not programming in JavaScript, you're programming in TypeScript, which happens to be compiled to something JavaScript engines accept. All the praise towards TypeScript does not necessarily apply to JavaScript. It would be like praising Assembly while you're actually programming in C.
• AegirLeet 5y ago
  I write PHP for a living and every time I look at the JS world, I feel like they're exactly where PHP was 15 years ago, except with 20 times the amount of incomprehensible tooling.
  • agumonkey 5y ago
    Can you give more details ?
    • AegirLeet 5y ago
      15 years ago, PHP didn't really support any programming paradigm very well, it was a huge untyped mess, the standard library was missing a lot of stuff, reusing code meant including individual files based on filesystem paths. Today, PHP offers a solid OOP experience, good gradual typing, a larger and saner standard library and code loading based on namespaced components. Now compare today's JS to PHP back in the day. It has the exact same kinds of problems. Except with modern JS, you'll end up adding TypeScript, webpack, Babel and a dozen other tools as well as several hundred megabytes of libraries to paper over all of those problems. But by doing that, you make the build process and the code that ultimately runs in a browser completely incomprehensible and undebuggable for the average developer. And then you start adding even more tooling (source maps that barely work) to try and solve that problem...
      • agumonkey 5y ago
        I had the impression that beside gradual typing, ES6 solved most of the mess (cleaner apis, modules) which was happening at the same time PHP (and python) accelerated their growth. I find it really unfair to compare es6 to php 15 years ago, es6 is really cute (the babel/transpiling part is peculiar, I admit it)
  • steve_adams_86 5y ago
    I’ve worked with PHP and JS extensively and while I could almost agree from some narrow perspectives, I think JS is nowhere near where PHP was 15 years ago in any sense. I was writing PHP 15 years ago. It wasn’t a great dev experience and the tooling was awful. JavaScript today has stellar tooling in comparison, and arguably less warts in its standard library than PHP still has today. I really disliked JavaScript until I read some books that helped me understand what it’s doing under the hood. These days I just don’t have issues with it. Yeah, the ecosystem thrashes a lot and the tooling experience can be bad in regards to that, but otherwise it’s impressive lately. Even without TypeScript, intellisense on regular JS enables extremely streamlined navigation of references and implementations, refactoring, project navigation, tooling integration, etc. Not to mention modern profiling and debugging tools for JS are incredibly easy to use and benefit from. PHP wasn’t at this stage even 10 years ago. The debugging story was still xdebug and tooling was improving but not great. Composer was painfully slow and buggy - nowhere near as nice as yarn and npm are now. Yeah JS has problems, but I don’t believe it’s nearly as bad as old PHP.
• neya 5y ago
  I maintain systems written in Ruby, Elixir and PHP over the years. Every server side code written by me even as old as 5 years ago, works with very little modification required for today. But the Javascript part is the one that always causes me hours-days worth of work into Rabbit holes. And by JS, I don't necessarily refer to the language alone. It's the entire ecosystem. Oh, `npm install`? You just found out you got like 1000+ vulnerabilities. Alright, good thing it told me actually, let me update. BOOM! Babel doesn't support this specification in this file anymore because it's nonsensical so you have to do something else now. Ok, BOOM! Babel deprecated that now, you have to try this workaround. Oh, wait. Actually, there is no workaround. You gotta downgrade your node version. Ok, let me downgrade. Oops, that package isn't supported anymore on this node version. Oh, you need to replace this because it's no longer maintained. I literally never had to go though this pain with any of my Elixir backend projects. Fuck Javascript
  • midrus 5y ago
    So npm gives you warnings about vulnerabilities and that's a bad thing? You notice you have thousands of outdated dependencies and that's a bad thing? I used to work a lot with python years ago, and the only reasons we didn't have this problems was because the packages management was so terrible that you didn't even notice you had to update dependencies or that they had vulnerabilities.
    • Draiken 5y ago
      Most languages I've used don't *need* to have 1000 dependencies like JS does. They also don't have thousands of projects depending on ridiculous packages like left pad because they actually have a standard library. The surface of vulnerabilities and the brittleness of the entire ecosystem is the bad thing, not the warnings.
    • lanstin 5y ago
      Diff being you usually have like five python deeps for every hundred npm deps a d you can do the old school thing and subscribe to the security alerts for those deps. The difference in number of deps means you have the cognitive space to understand them. Npm needed to automate because the numbers are too high. One of python’s old selling points was “Batteries included”. And the idea is fewer large library rather than a bunch of tiny libraries. With a small number of deps where you skim the development DL, you know if there is a security issue or a cool new feature you want. Also it has more of the Unix C philosophy of don’t break stable APIs in new releases. So upgrading mostly just worked. (Stuff like deliberately breaking old SSL protocols aside). (Until python 3 of course.)
• austincheney 5y ago
  Yes, the language is sloppy. Like all things sloppy it’s more about knowing what not to do only after which the elegance is exposed. That said, unfortunately, the language is much better expressing personal projects than picking up the trash in an untrained corporate environment like an over paid janitor.