I think that whole point is to not resemble Javascript. I kinda like it, in my experience current state of JS is layers and layers of tools stitched together over language that was designed for much simpler times. Compared to other stacks I worked with it's often unstable, slow and poorly documented. I tend to avoid doing fronted if I can.
Fresh and different look at this topic is something I would very much like to see. Of course for people working with front end today may have different perspective.
Sure, but using some other language than js could become attractive to people who avoid frontend because of it. Not that that makes it a good idea, per se.
In most cases I'd agree, but essentially JS has gotten to the point that it's only usable if you write an entirely new language on top of it, like React/Vue/Angular have. All of them are basically to avoid the confusion that arises from the weird quirks of JS, like it's classes implementation. These languages then also try to integrate the few positives of JS into their paradigms, and IMO they are decently successful to the point of usability for a frontend.
Interestingly, even as a one time front-end specialist, I'm leaning the something same direction this author did: the complexity introduced along with front-end frameworks/tooling treads near (and in some cases beyond) a border past which I stop feeling like working with JS itself is a win. The more the development process treats the browser as a runtime target for generated code, the less point I see in sticking with JS -- or even augmented versions of it -- as a source language. And I like JavaScript.
Of course, I don't much like Java, so that's not where I'm likely to go, but I am struck with what the author demonstrated here regarding that as an option. Like the author, I'm very curious about something like Elm; if I'm going somewhere with a type system, I'd like to go further along the spectrum of benefits types can provide.
And I'm also not sure we've reached the apex of possibilities of working more directly with HTML/CSS/JS, but that's highly domain/application dependent and another topic.
I would love to see a nicer language replace JavaScript as much as the next guy, but it seems rather unlikely especially given the changes that ECMA has approved in the past.
I am really hoping that some day, we will be able to do front-end devwork that isn't just an abstraction of JS/HTML/CSS.
I totally get the idea of bringing JS into new environments because it is so ubiquitous. On the other hand, I hate the language and wish we could replace it in the browser, the opposite direction. I'd be much happier with ClojureScript or PureScript or something being the standard with the ecosystem to go with it.
Meanwhile I think JS is one of the best dynamically programming languages and your post just feels like it's belaboring the same old Python vs Ruby or tabs vs spaces debates.
Frankly I don't find any of the other client application platforms any more compelling than what we have with the web.
I love where JS is heading, but perhaps its worth pointing out its a lot easier to rapidly advance a language that historically has been missing huge features.
As much as I dislike Javascript, I can't agree with this article. There's tremendous value in using the same language in both the front and back ends. I personally might argue that with the prevalence of compile-to-js languages (Haskell being my personal favorite) there's no reason to use Javascript any more. But that doesn't mean that everyone else's calculus is the same. And if you use JS on the front end, there's a compelling reason to also use it on the backend.
On the one hand, I think he has a point that said features of JS.next are cutting against the grain of present-day JS. There are quite a lot of people programming in JS, many of whom may or may not deserve to be called good programmers but who nonetheless can produce functioning web pages, that would have to switch to a very different coding model to work with JS using these new features.
On the other hand, it's difficult to program your code when you know than any of your invariants can be accidentally stomped on by any other code that happens to run on the same page. It's also difficult to write libraries when everything's guts are exposed, even with red tape. Raymond Chen over at MSFT has an entire blog that could be titled "How Implementation Details Become De Facto Interfaces Due to Insufficient Encapsulation."
I think my final thought on the matter, is that when you think about it, it's really quite silly that we only have one language for front-end web development. It is, in fact, unacceptably silly. Like, seriously guys, what the hell? This is totally crazy. If you want to do server work, or non-web client applications, or embedded, or whatever else, you have a full array of programming languages. These run the gamut from ball-gag-and-leather-straitjacket static languages to walk-into-anyone's-house-and-drink-their-milk dynamic languages, from concise expressive languages to low-level bit-fiddly-ones, from parens to curly braces to significant whitespace to perl.
On the web we have JavaScript. Not that it's a bad language, it has its warts (what doesn't?) but it's actually a cute little language. But I don't have the option of using a language with static guarantees. Or deterministic memory management. Or asynchrony. Or macros. None of these are strictly better, they're all just personal preferences, but the point is, you don't have the choice.
That lack of choice is probably what's driving these against-the-grain additions to JS.next. They're adding more features to JavaScript so that it can cover some of the bases that it currently doesn't, and all the different directions it's being pulled in are understandably causing some stress. I think it's the wrong solution, but it's also the one with the easiest transition path. The ideal solution, is that we could use different languages from different paradigms, but how the hell do you crowbar them into existing browsers?
So uh... do I have conclusion? I dunno, language evolution is hard, let's go shopping.
Exactly. So if JS has been able to do something for a long time, why would someone create new tools in different languages that do similar things? Because they don't want to write JS...
I'm not going from backend to frontend or desktop apps. I'm going backend to backend.
I guess part of my point is I'm made uncomfortable by the encroachment of Javascript into areas where it's not particularly well suited, and the historical baggage it must carry into those areas. It's the when you have Javascript as a hammer, everything looks like a nail issue. I don't think my organization is unique in its embrace of Javascript-everything, either.
I agree with you in concept, but the Web is actually not strictly tied to javascript. In the short term (say, next decade), JS is probably not going anywhere, but in the longer term I hope someone creates a more well-thought-out replacement. (And for the record, I kind of like javascript, just a few things I would change with it.)
To be fair, the language is in better shape today than it has ever been. The ecosystem, that is another matter.
Personally I'd love to completely ditch JavaScript. I'm eagerly following the progress of WebAssembly. I'm certain in 5 to 10 years the majority of front end dev will not be done in JavaScript.
oh please no JavaScript- it is awful enough in the frontend, but that train seems to have left the station, but in the backend we have much more powerful languages and ecosystems.
Fresh and different look at this topic is something I would very much like to see. Of course for people working with front end today may have different perspective.
reply