It also is the exact opposite of what's in the article. If people do this, there will be more JavaScript not less. This is nothing more than a thinly veiled advertisement.
"The web is the greatest application delivery platform on Earth, and frankly it’s a stain on our profession that you need to know five different programming languages and three different frameworks if you want to make it do anything. Really, all you should need is to be able to code - ideally, in a friendly, readable language that’s easy to learn and isn’t full of unpleasant surprises."
As someone who does fullstack dev in JavaScript I find the comment totally without basis.
What are these 5 programming languages? I assume that includes HTML, CSS, JavaScript and maybe some backend language. Still, that's only 4. Also even in desktop and mobile application development there is a separate markup language for putting together the UI. For example XAML for Windows devs and XML for Android.
Well you could still need some JS for the frontend but once we're adding a database too is it really any different from whichever Desktop GUI framework? The only difference is I guess that CSS and HTML are separate whereas this isn't as common for Desktop applications.
> "The web is the greatest application delivery platform on Earth, and frankly it’s a stain on our profession that you need to know five different programming languages (...) Really, all you should need is to be able to code."
The guy who wrote this is sadly one in a new breed of so-called "coders" that don't really love the art of programming.
Technically with the advent of Nodejs, you can just use one language and only use 1 or 2 frameworks for a full responsive web app. You just have to use Javascript for all of it
It's a means to an end. You can choose - if you think the thicket of Javascript frameworks is strangling accessibility of the Web platform, can either whinge about it on the Internet all day or try to build something better.
Headline here is misleading, I first thought it was about less client-side scripting on websites. However, this is a talk actually about using Python (compiled to JavaScript) for client-side scripting.
And then, the page shows, as a supposed example of the reason for not using javascript:
> And here’s how you’d do it in Javascript. I count three separate callbacks here. I’m not exaggerating - this is an example straight from the documentation of the postgres library!
Yet this JS code is done on a mediocre way (for today, 2017). This code would be far shorter and easier if done in JS using async/await, which is what everybody should be using now.
So, besides that, there is the premise that using the same language in the browser AND in the server is a good thing; but how true is tat premise when the "alternate" language is pretty much similar in features? I mean, there's not such a huge benefit of going from JS to Python; perhaps i can concede that Python is mostly strongly typed (a good thing), but it's not like there were huge advantages.
And then, how hard is to go from Python to JS to C# to Java when these four languages are very similar in syntax, as well? Hard stuff, for a programmer, would be to jump from JS to Forth or to Prolog; radically different languages.
maybe it's easier to jump between wildly dissimilar languages because you wouldn't be prone to mapping the wrong mental model on to what you're doing or mixing up the behavior of similar syntax as often?
Yes, but jumping between Python and Javascript is really easy. I do it myself, even in the same day, without problems.
In the same way as people who can talk English, Spanish, French, and Italian, can easily jump between those languages in the very same meeting/social event.
I do agree with your point, for example it is easy for me to mix words as belonging to Portuguese versus Italian; but that's because i don't really speak those languages.
The bottom line is -- once you learn them, there is hardly any trouble.
Love Python, but gosh, the lack of type checking. It might not seem like a problem with small applications, but it makes navigation and refactoring of large codebases much harder than it needs to be.
Yes there are type annotations, but they are just that at the moment, annotations. There isn't, as far as I know, a good type checker, or IDE that makes good use of them.
Ironically, an extended version of this transpiler could potentially be used to convert annotated python to Typescript. And poof! Proper type-checking in Python.
I've tried to use Dart and it's supposed Interop with JS (to leverage the existing JS ecosystem) and it was a bit painful at times (looking at you Dart-React). And this is with a Behemoth (Google) putting resources in this language.
I can only imagine the pain of using Skulpt (JS interop + Debugging). I might be wrong in my assumptions, any feedback from Skulp devs here?
I love the idea of writing web apps in Python. I don't love the idea of obfuscating the async nature of the web.
When I was learning JS (coming from Python) I hated async programming, but it was mainly due to the syntax of callback hell. I couldn't tell what would run after what because it was no longer in order in my source code.
As other have noted async/await syntax fixes that problem. Since 3.5 that's available in standard Python (and the concepts have been in use in packages like Tornado for ages).
So ultimately I think we will see an explosion of languages that run in browsers, I don't think hiding core concepts is helpful to that endeavor.
I loved the example off "amount off code needed in js...".
These statements make me laugh by default. Amount off code needed in these contexts is so relative.
U can write 3 functions, chain them as promise/callbacks, then make it an exportable module, and it becomes:
"var x = require('x');"
Wow 1 line off code, to reference all that code off the functions, and 1 or 2 more for the options/arguments.
There's an inherit complexity and amount of code needed due to the nature off "variation" and odd cases. Creating an app that does a 100 different things will likely need more code than when it does one thing.
That said, nothing stops you from decoupling it, and create a higher leveled file to create a virtual "hub", where u do nothing more than chain the modules and give args. Basically like Node.
26 comments
[ 4.6 ms ] story [ 66.4 ms ] threadWhen it's framed as "Remove JS from the world to make it better", that invites a lot of drama.
Obnoxious biased introduction:
"The web is the greatest application delivery platform on Earth, and frankly it’s a stain on our profession that you need to know five different programming languages and three different frameworks if you want to make it do anything. Really, all you should need is to be able to code - ideally, in a friendly, readable language that’s easy to learn and isn’t full of unpleasant surprises."
As someone who does fullstack dev in JavaScript I find the comment totally without basis.
Much better. Oh wait...
(not criticizing your own comment of course)
The guy who wrote this is sadly one in a new breed of so-called "coders" that don't really love the art of programming.
> And here’s how you’d do it in Javascript. I count three separate callbacks here. I’m not exaggerating - this is an example straight from the documentation of the postgres library!
Yet this JS code is done on a mediocre way (for today, 2017). This code would be far shorter and easier if done in JS using async/await, which is what everybody should be using now.
So, besides that, there is the premise that using the same language in the browser AND in the server is a good thing; but how true is tat premise when the "alternate" language is pretty much similar in features? I mean, there's not such a huge benefit of going from JS to Python; perhaps i can concede that Python is mostly strongly typed (a good thing), but it's not like there were huge advantages.
And then, how hard is to go from Python to JS to C# to Java when these four languages are very similar in syntax, as well? Hard stuff, for a programmer, would be to jump from JS to Forth or to Prolog; radically different languages.
In the same way as people who can talk English, Spanish, French, and Italian, can easily jump between those languages in the very same meeting/social event.
I do agree with your point, for example it is easy for me to mix words as belonging to Portuguese versus Italian; but that's because i don't really speak those languages.
The bottom line is -- once you learn them, there is hardly any trouble.
Yes there are type annotations, but they are just that at the moment, annotations. There isn't, as far as I know, a good type checker, or IDE that makes good use of them.
Ironically, an extended version of this transpiler could potentially be used to convert annotated python to Typescript. And poof! Proper type-checking in Python.
Mypy is a good type checker.
I can only imagine the pain of using Skulpt (JS interop + Debugging). I might be wrong in my assumptions, any feedback from Skulp devs here?
When I was learning JS (coming from Python) I hated async programming, but it was mainly due to the syntax of callback hell. I couldn't tell what would run after what because it was no longer in order in my source code.
As other have noted async/await syntax fixes that problem. Since 3.5 that's available in standard Python (and the concepts have been in use in packages like Tornado for ages).
So ultimately I think we will see an explosion of languages that run in browsers, I don't think hiding core concepts is helpful to that endeavor.
I loved the example off "amount off code needed in js...".
These statements make me laugh by default. Amount off code needed in these contexts is so relative.
U can write 3 functions, chain them as promise/callbacks, then make it an exportable module, and it becomes:
"var x = require('x');"
Wow 1 line off code, to reference all that code off the functions, and 1 or 2 more for the options/arguments.
There's an inherit complexity and amount of code needed due to the nature off "variation" and odd cases. Creating an app that does a 100 different things will likely need more code than when it does one thing.
That said, nothing stops you from decoupling it, and create a higher leveled file to create a virtual "hub", where u do nothing more than chain the modules and give args. Basically like Node.