Professionally, I do embedded and robotics, but once a year I find an excuse to create a simple web application (to stay updated). Every time, I get impressed by power and simplicity of the web technologies in general. In JavaScript those are things mentioned in the article + WebComponents. For CSS those are flexboxes, grids, and animations. In my opinion, React made a revolution with hooks and contexts. I love the direction in which the web world has been going!
Try writing a GUI with other toolkits. Hours of tweaking random XML to try and figure out why some constraint solving thing just isn't working...
Despite all the mess, I have an easier time getting buttons on a screen and doing things sanely (once all the fuss is set up) compared to trying to get the ball rolling in Qt/GTK/etc (especially if you're not using Java or C++)
Seriously. I’ve been doing web development professionally since 1998. I’d love to have OP write a blog post to teach the rest of us about this simplicity.
Web development, even single page apps, and progressive web apps, can be simple if you skip the web frameworks which solve non-problems and complicate things. The most difficult problem in web development is to make the user interface (UX) work on everything from smart-watches to 40 inch 4k monitors. CSS solves this problem, but it's not an easy problem by itself. The second most difficult thing in web development is automated testing across the stack, testing both back-end and front-end, with different user devices. It's complicated and time consuming to write the code that test every function automatically. Third most difficult thing in web development is optimizations, the browser dev tools doesn't say much about what is going on internally in the JavaScript engine.
I was able to create an original OS like GUI, including file system interaction, using vanilla JS (TypeScript) in about two weeks. I am still using it. The actual GUI is just a couple files each comprising about a dozen functions, nothing really complicated.
The nice part is that you can make web dev as simple or complex as you want. You can write your entire application in a single index.html file with no compilation or build step. You can also use various preprocessors, scaffolds, libraries and frameworks to achieve the same result. The choice is yours.
One thing I hate about the modern web is pages that load with lots of missing content / empty components and then download and render that content afterward.
Is this a React thing?
Waiting for the extra request(s) adds lag time, makes back/forward navigation clunky, interrupts what I was doing if I already began interacting with the page (eg. infamous relayout / unwanted scroll) and sometimes breaks snapshotting tools like archive.is.
I don't mind pages with javascripted controls, but their initial content should be included in the payload with the initial page load. Don't the frameworks have tools to help you do that?
It's not specifically a React thing, but JavaScript enables it. Lazy-loading content is a good idea if you're building dynamic web _applications_, as common components (buttons, modals, etc.) don't need to be reloaded over and over. However, with mostly static content like a blog, it's generally not a great idea.
You can probably thank Google for that as to get a higher page ranking, a site must do the initial load fast. And showing only empty placeholders is fast.
> their initial content should be included in the payload with the initial page load
The problem with that is that it pretty much requires you be running node on the back end too. If your back end is built with say PHP or Ruby, you’d need to call out to a node process, which is potentially a lot of additional complexity, time, and expertise.
>In my opinion, React made a revolution with hooks and contexts
I agree with your overall point 100%, but to be honest nothing in React was / is innovative except for the virtual DOM diffing, but even that is becoming increasingly irrelevant as apps are moving towards more and more reactive architecture. React made a huge impact on web dev and deservingly so, but all of the other ideas have been implemented and used on the web before.
Of course it's great that React is bringing some of these good ideas to mainstream, but they've been there way before they have been distributed along with a VDOM algo.
> nothing in React was / is innovative except for the virtual DOM diffing
Maybe there wasn't much academically innovative in React, but it certainly brought declarative, functional UI programming to the masses. Its innovation was in making that as easy and accessible as possible with a tiny API.
I feel saying React wasn't innovative is so dismissive and ignores the massive paradigm shift that's happened in web development because of it.
Well, isn't there something a little "revolutionary" about mainstream adoption of cutting-edge techniques?
After all, like you suggest, things like functional programming and monads have existed for quite some time. The thing that makes React special is how rabidly people adopted it, and continue to adopt their major updates.
> but all of the other ideas have been implemented and used on the web before.
Is this true? I've worked in web dev for like 6 yrs now and React has provided a significant number of concepts and technologies I'd never seen before and still dont see elsewhere.
For example, JSX. Yes, it originated in php but React was its first time being implemented in the frontend.
Also the concept of hooks and functional components. The fact that you explicitly define side-effects in the render of a function, with memoization or execution dependent on arbitrary state, is a new invention as far as I'm concerned.
My only issue with CSS is the absence of container queries [1]. Now I need to rely on size listeners of the container element to make my components truly responsive. Media Queries do not work for components. CSS Grid & Flexbox are nice but not enough to achieve radical layout changes for certain breakpoints.
I do embedded also, and FPGAs. Do you have any suggestions for how to start learning web stuff? Every time I try, I get overwhelmed by all the frameworks, libraries, package managers, build pipelines, etc. There doesn't seem to be a set of best practices for what to do, or even what is needed and what isn't. What is the best way to get started?
This is a good resource that will walk you through the cutting edge web development technologies, starting from the very basics and progressing to the more complex matters in the end. Highly recommended.
Do you start learning FPGA programming by studying frameworks? I doubt. Like all other things you start learning the basics and then once you know them you can abstract complexities with frameworks. There is nothing overwhelming about web development. It is trivial.
May you kindly point me where to start learning robotics, and recommendation for a starter robot arm? Maybe ~$300 if something worthwhile exists at that price range. Take care.
For $35 you get a little motor, a motor control board, and an ARM micro-controller board. ST includes some software for motor control. If you want to do precision motor control, out of the box it is missing an encoder (a device that tells you the position of the motor). The STM32 chips usually have some inputs you can use with a quadrature encoder, so you could add one if you needed to. It does include a current sensor and the software uses the for field-oriented control (FOC), so you can efficiently and smoothly control the speed of the motor. To learn more about motor commutation and FOC, check out this document:
Lego Mindstorms could be worth considering as a general-purpose hobby robotics platform: EV3 (the older version) can be flashed with a custom Linux distro, and Robot Inventor (the newer one) can run Python scripts. In either case all you need to add more structural parts is to pick up a bulk case of used Technic parts, so it's eminently reusable for multiple unrelated projects.
On React, people talk about it especially for it being a UI tool.
But the most significant feat React achieved IMO is how easy to write asynchronous hiearchical actors (from actor model) with it (kind of like erlang vm).
Context enables dependency injection and ownership management. Effect and state enables object ownership and lifetime management. Js timers, (i.e. setTimeout, setInterval, queueMicrotask, promise/async), help making an object living asynchronously as if it has its own private thread.
Yes, those are similar concept of lifetime and ownership Rust have, but instead of functions/blocks the object (value in memory) is owned by/shared with components. And of course these are not enforceable by compilers/transpilers/linters due to them not being a javascript-primitive, but at least React helps organizing those things in a lot more explicit and clear manner.
Web hooks are nothing new in other languages, they're just built-in functions that do things that were previously cumbersome to code yourself. That's only revolutionary to React. PHP is a great example of built-in functions, yet I've heard React fanboys complain that PHP has too many built-in functions (which is a really odd thing to complain about).
JavaScript is a great browser scripting language because it's the only browser scripting language. That's a whole realm of good times, and people can and should go nuts with it there.
The problem started a decade or so ago with Node. Too many people only learn JavaScript, become psychologically dependent on it, and they all collectively took it too far outside of a browser.
ECMAScript is a general purpose standard, but it was invented retroactively. Node is not ECMAScript in a server-side ECMAScript engine, it's JavaScript in a browser JavaScript engine. That's just too much of a force fit, and has wasted too much potential for me to say anything positive about it.
Couldn't disagree more. I was a Java programmer for my entire career until about 2015 or so when I switched to Node, and shortly thereafter to TypeScript.
I've commented this many times before, but having a system where everything is on the same tech stack (i.e. front end in TypeScript with React, back end with TypeScript on Node) has resulted in gargantuan productivity gains, especially for a small team where it's trivial for people to cross front end to back end seamlessly. For contrast, I know many teams with a backend in Python and a frontent in React/JS, and I've worked on some teams with that setup. In my opinion it's virtually all downside compared to a backend in TS, as Python and TS are quite similar from a web programming perspective (I'm not referring to Python's advantage in data science tooling), so all it basically is is a barrier to your front end folks being able to make small enhancements on the backend quickly.
Furthermore, TypeScript is a great language and I find myself being so much more productive in it than I was in Java, especially when it comes to refactoring.
JavaScript most definitely has its warts and head scratchers after being around for 25 years, but I feel like most of these oddities (truthy/falsey, typeof null === 'object', undefined vs. null, etc.) can be learned in an hour and written on a half page.
If you’ve mainly worked in TS then it explains the blind spot, because JavaScript is chock full of awful missteps built up over the years. There’s a reason my copy of “JavaScript: The Good Parts” is extremely slim next to its sibling, “JavaScript: The Definitive Guide”.
So you’ve come to it at a time when the syntax and capabilities have a popular subset that actually starts to fulfil the early promise. And yet, despite the article above, one may still be enormously critical of the anemic and inconsistent standard library, and don’t even get me started on the horrifying dependency shitshow of the node ecosystem that cripples maintainability of anything over 18 months old.
Just because we’re all holed up in the throne room, doesn’t mean there aren’t monsters still roaming the sewers, just a few levels down.
As for isomorphic code, I strongly encourage my competitors to write backend code in the same fashion and the same breath as the front-end, because the resulting tight coupling and special-case-driven technical debt makes them easy to outmanoeuvre when markets shift. And if they’re reading this then please also consider microservices, graphql,
and nosql data stores whilst you’re at it, for the same great reasons.
I didn't do much web dev but is having the same language for the front and back end a real time saver? For a skilled programmer, switching language is not a big deal. I'd say that for a front end developer to touch the back end, learning the required bits of Python or whatever is used is not the biggest problem.
Front and back do different things, have different requirements. You control the architecture on the back end for instance, not on the front. The back end deals with data modeling and processing, the front with layout, very different task, very different skills, and the language is just a small part of it.
There is some overlap, for exemple I remember having to code a clock twice, once on the back end of to show it correctly the first time, and once on the front to have it refreshed in real time, the code could have been shared, but these occurrences where code can just be copy-pasted are not that common.
And BTW, most of my web dev was JS/PHP/SQL, and I actually liked all three languages for what they did. JS, I had no choice, but it did event handling well. PHP was good at generating HTML from a database and SQL, despite its age is still king for querying databases. I wouldn't want to use these languages for anything else.
In a backend where you need a heavy-duty, multithreaded process to handle long-lived computations, node is probably not the way to go unless you want to pay for all the extra instances you'd need for the same amount of load. In my experience, for example, a java-based graphQL server (that spawned multiple connections to various services) needed much much less in the way of resources than the node equivalent serving the same amount of traffic - AND the latencies were generally much better with the java server, depending on the size of the JSON payloads that it was handling.
All that being said, you can certainly architect your way out of that problem and I imagine a relatively small percentages of web applications even HAVE that problem.
The first post also misses something fundamental about modern software: servers programming is becoming more browser-like.
> Node is not ECMAScript in a server-side ECMAScript engine, it's JavaScript in a browser JavaScript engine. That's just too much of a force fit
And what makes V8 a "browser JS engine"? A focus on:
- rapid startup. Code starts running immediately, JITs quickly. The VM is designed for latency, not just for throughput.
- excellent sandboxing. The VM is designed to run untrusted code.
- no blocking code. Designed for callbacks and promises. No threading, no thread.sleep(), no mutex, etc. Makes is much easier for non-expert developers to write fast & reasonably correct code.
Now look at things like Cloudflare Edge workers, Lambda etc. Modern server environments share all of those same design goals.
Server-side JS/TS not only has the advantage of a single codebase. It also brings the design and engineering advantages of a browser VM to the server.
> Furthermore, TypeScript is a great language and I find myself being so much more productive in it than I was in Java, especially when it comes to refactoring.
I don't really see how. TS doesn't seem to solve any annoying problems I previously had in Java. As a concrete example, it would be nice to have the concept of a DTO as a first-class language feature, but alas, I find myself constantly casting and re-casting, plucking, or writing endless wrappers to make sure properties trickle down (or up). Hell, sometimes I just give up and use `any`. I mean, this is a web-first language that has no concept of sending objects over the wire.. okay then.
TypeScript's generics system is cute, but I think it's mostly academic. And did you look at the toolchain? To get TS working, you need babel or ts-node or webpack, and like 3 different .json config files. Importing a package without TS support? You need to write some stubs yourself in types.d.ts. In fact, the best parts of TypeScript are actually JS (await/async, arrow notation, spread operator, etc.).
It would be amazing if there were other languages available for front-end development in the browser, no? Even if you think that JS is so wonderful, then having competition would still be good, or no? Currently JavaScript has a monopoly in the browser and monopolies are always bad. Bad for innovation and everything else.
It would be better if there were no oddities in a language. One of the reasons why everyone hates PHP is that it is full of inconsistencies, odd design choices, weird naming and unexpected behaviour. JS has at least some of these.
If there was a second of third language available in the browser, then that too could be used to develop back-end applications and would have the benefits you describe - that you can use the same language for both stacks etc. For example - if you could front-end stuff in Python, would it be amazing or bad? Or would the current JS devs just fear for their jobs because of it?
> For contrast, I know many teams with a backend in Python and a frontent in React/JS, and I've worked on some teams with that setup. In my opinion it's virtually all downside compared to a backend in TS
Is there any Typescript backend framework as mature as Django?
> Python and TS are quite similar from a web programming perspective (I'm not referring to Python's advantage in data science tooling), so all it basically is is a barrier to your front end folks being able to make small enhancements on the backend quickly.
So on the on hand, the languages are "quite similar", yet it cannot possibly be expected that frontend people learn more than a single language? Something doesn't add up here.
I have a lot of experience in both python, typescript and react. I would still opt for python on the backend, simply because it's a nicer language to work with. Debugging is a joy, and it feels like the library ecosystem is more comprehensive and stable.
This is of course subjective, and maybe I'm biased due to having a lot more experience with python than JavaScript.
> having a system where everything is on the same tech stack (i.e. front end in TypeScript with React, back end with TypeScript on Node) has resulted in gargantuan productivity gains
How so? Is it just about being able to use a single set of tools, libraries, habits, etc? Or are there particular things which are easier when the language is common? Are you sharing code between front-end and back-end.
I do very lightweight front-end coding these days. It's usually some variation on populating and updating a table from a websocket, maybe with some simple filtering and toggling in response to user interaction. There, i can't think of any particular advantage to having both ends in the same language, but then mine is quite an unusual use case.
> For contrast, I know many teams with a backend in Python and a frontent in React/JS, and I've worked on some teams with that setup. In my opinion it's virtually all downside compared to a backend in TS, as Python and TS are quite similar from a web programming perspective (I'm not referring to Python's advantage in data science tooling), so all it basically is is a barrier to your front end folks being able to make small enhancements on the backend quickly.
How big of a problem is this?
At the end of the day all that really matters is that the external representations that get handed off are the same and that everyone makes the same assumptions. Given the same set of fields manipulating a POJO with Java streams is not all that different from using modern Javascript on a blob.
If there are productivity gains to be had please share it with the hoards of nodeJS 'full stack' devs at my company who suck up all wages, dont produce anything, and make people hate digital
Typescript makes refactoring easier in what way? Can you do renames without error prone string search and replace? Can you get good autocompletions with ts? If so, that would be really nice
At my last company I created a few tools that became key to my org, which was front end/JS oriented. Being able to write them in JS meant anyone could contribute fixes and features trivially, with zero ramp up time. That is a really nice benefit of Node. Imagine if Rails developers couldn't use Ruby for their tooling. Node really filled a nice gap here.
> everything is on the same tech stack ... has resulted in gargantuan productivity gains
i highly doubt that - i don't disagree you got productivity gains, but it's not from being the same stack, but it's from experience gained doing it.
If what you say is true, why doesn't people use GWT (google web toolkit) and java on the backend to get this productivity gain? It has existed even earlier than typescript, and is compiled to be quite fast. It's even more integrated as a stack, and anyone knowing java is able to use it fairly easily.
> switched to Node, and shortly thereafter to TypeScript
Undergoing a similar path. My problem is that the moment I switch to TypeScript and start writing my code becomes very similar to Spring. And at that point I have to ask a question of why would I not just write Java. Node on the other hand feels like node.
Either way you try to argue this, it's hard to make the case that Java/Javascript is better at any of those things than another language. Productivity be damned, your dinky jar file will get smoked on almost every quantifiable level if you pit it against against a C++ or Rust rewrite. What GP is saying is that the only reason people praise Javascript is because it's a unique language, and I think it's a fair appraisal. Javascript is in a class of it's own, for better or worse, and since it has no real competitors, it's easy to dismiss detractors.
Whenever I encounter Node, issues almost always follow. Whether it's NPM's delightfully useless error messages or a stream of neverending warnings filling up stdout, it quite literally never fails to cause a problem. Maybe Node should focus on saving it's reputation, because I for one run in the other direction of it. Hell, especially in the case of Node, I hope that Deno comes to replace most of it's core functionality. Putting up with half-assed software on a half-functional runtime only leaves me with a quarter of the patience I started with.
> * Lexical scope natively without syntax or conventions
I assume you mean over the alternative, dynamic scoping like in e-Lisp. But you realize that JavaScript's scoping rules are entirely wonky, e.g. that "var" declarations are lifted to the function level?
>> Node is not ECMAScript in a server-side ECMAScript engine, it's JavaScript in a browser JavaScript engine.
>What does that even mean? The APIs are completely unrelated and Node does different things that don’t make sense in the browser.
I have taken the privilege of rewriting the quoted part of the parent comment,
Node runs javascript on the server side in an engine built for the browser. It does not run ECMAScript with an engine specially made for server side apps.
This comment is so weird. JavaScript got scoping completely wrong, and none of those were particularly novel when it was designed and they are almost universal now so I don't know why they would keep you hooked on JavaScript!
And those things are outweighed by things JavaScript got so incredibly wrong... like === vs == and some of the weirdness when you GASP use == as any other language would do.
JS is like PHP... only a popular language because it's been around a long time and it's easy to get started. Otherwise, there are SOOO many better programming language out that the ONLY reason JS still has traction is it became the "default" web language.
10 years ago I would have agreed with you, but in recent years Javascript (and moreso Typescript) are just exceedingly pleasant to use. I'm using Typescript in backend services despite knowing Python and C# well just because I like it.
I can imagine that the original argument does not apply to the languages which compile to JS. But IMO the fact that there is so many derived languages covering the mess which JS is only supports the argument against it.
Couldn't agree more. I started in this field as a javascript programmer. I've since expanded my toolkit to include typescript, elixir, plpgsql and now gaining proficiency in rust.
I'm continually frustrated by my colleagues refusal to step outside the javascript ecosystem. Don't get me wrong, JS certainly has its place but its not ALWAYS the best tool for the job. I see a lot of people reach for node as their go to backend tech choice simply because its the ONLY tool in their toolbox.
Unless you're building a small focused microservice where the functionality involves calling out to a library with working tested code that does what you want, I think node is honestly a poor choice. To qualify my statement, I spent the first 7 years of my professional career building software with nodejs.
The sweet spot is much smaller than the scope of projects people throw at it.
* quick MVP? rails has more libraries that are drop in.
* Performance? go and elixir have node beat for multicore perf
* websockets? compared to phoenix channels, everything in node for serving websocket apis are a toy.
Lambda functions though? yea nodejs kicks but there!
TypeScript is a pretty good language for writing web servers, as long as you don’t need to do computationally heavy parallel computing. And you can still do that, but it’s very awkward.
I’ve done plenty of backend work in all of TS, Scala, Go, Python and PHP. Scala is my personal favourite, but it’s not as practical for teams as TS or Go, which are both very productive languages, with good enough type safety and performance, that new devs can learn quickly. And I’d easily choose TS over PHP or Python for a large system.
Plus, it IS pretty nice being able to use a single language everywhere. My current company is TS RESTful services with TS/React on the web, and TS/React Native on mobile, pretty hard to beat how easy it is to do full stack dev work for most ppl in this setup.
JS has no parallel computing support, so it is not an option. And when I say parallel computing, I don't mean distributed computing, I mean utilizing hundreds (thousands) of cores on a single die, like NVIDIA architectures. (It's a black art, even addition algorithms can confuse the newcomer.)
The best course is to do what every other language does when it comes to simple-parallel operations, like Gauss-Jordan elimination: use a dedicated, optimized library, like NumPY.
I really hope some day there will be a numpy for JS. NumJS is dead, and Google's TensorFlowJS is excellent for utilizing GPUs, but a dog when trying to do simple operations (the load/store async nature doesn't quite fit with most use cases.) I suspect WebAsm will facilitate the parallel nature of tensor operations without having to move
From my perspective (mostly a Python user), Javascript is a fine language for general-purpose scripting and server dev, and Node is more than fast enough to handle typical workflows.
Why do you think it's not a good language for this?
Also, I see a lot of value in using a one single language that can truly do everything: frontend, server, and scripting.
I guess you could use Python or Ruby like that with Wasm, but I haven't seen evidence of people doing that.
Like JavaScript, one can argue that the only thing wrong with node is the ecosystem/developer community. Things like npm as just not curated enough given the large number of JavaScript developers and the attendant variability in quality of output. Node itself is an almost perfect call-back driven even loop for Unix network io, which till go and go routines/channels was the conceptually simplest way to use the CPUs you are paying for, saturate the network, and have subtle threading issues. (Python gevent was also good at that, but had more implicit magic which is bad for reasoning about code).
But I am hopeful that when I finish reading the article I will not have to reuse my jquery / d3 based framework for doing quick data viz things (which I only started doing with great reluctance because people don’t go wow over tabular data even if the data is wow-ing. The first request to make it pretty, i switched to mono space fonts. But jquery is showing its age.
I don't know what's wrong with me. I hate JavaScript. I tried learning react and redux and just gave up. All this to put a button and a field on a page. React was basically invented by John carmack to do doom 3 and copied to render web pages. Is this really required!? It's not a 3d games engine. I've worked on web apps that require a lot of page updates per minute and I still hate react. I stay the hell away from front end web Dev as it just feels like hell. Sorry drunken rant.
Edit: I also worked on a node app that should have been written in a staticall typed language. Bugs that could have been caught at compile time literally caused me utter misery in on call overtime. All because some guy in our team demanded we wrote it in node. This was way before type script. I actually feel physical pain thinking about.
You should really try learning react first without redux. Redux is for managing global state. It's rarely needed but has become the defacto solution for react state for some reason.
React on its own is much simpler, once you grok the react compositional model. I don't know how you can do that while using redux too.
Perhaps give it another try, but with TypeScript. Im a front end dev and yes, I feel the JS pain. I look back at how I used to do things and think "wtf". TS completely changed this and brought it back to sanity.
at least part of the problem is that Javascript and webdev have really low barriers to entry, which is positive in the sense that anyone can do it, but the problem is that anyone can reach that unhappy valley of knowledgeable enough to do a lot of damage without realizing it.
If you put bad developers on other languages they usually end up running into some wall first but Javascript is pretty forgiving.
"React was basically invented by John carmack to do doom 3 and copied to render web pages. "
Does anyone have any reading material on this? I've never heard it and a quick Google turned up nothing, but I'd love to read about it. Unless it's a joke that went over my head...?
> Too many people only learn JavaScript, become psychologically dependent on it, and they all collectively took it too far outside of a browser.
Do you have any evidence for this? Because there's plenty of reasons why you'd share the same code in the browser and the server. Being able to do SSR and sharing validation logic are two huge and obvious reasons. Ever try to exactly duplicate validation rules between the browser and PHP? What about when they use weird regexp rules?
I have a site builder codebase that renders previews instantly as you make changes, then uses the same code on the server to render the HTML and CSS for visitors. That would be otherwise be outright impossible to do without writing the same code again in another language.
> Being able to do SSR and sharing validation logic are two huge and obvious reasons. Ever try to exactly duplicate validation rules between the browser and PHP? What about when they use weird regexp rules?
PHP is adding support for FFI to any C ABI-compatible language, and you can run the exact same code in the browser via emscripten or a WASM polyfill. As a bonus, emscripten/WASM compiled code will also be more efficient in the browser than plain JavaScript or Typescript.
NodeJS is important for more reasons than "it's just JavaScript". It is asynchronous from the bottom-up, and it is literally a challenge to force asynchronous patterns into a synchronous ones, which is almost always a hack because async requires a lot of thought. This is a boon to IIoT control, where the pejorative "web server" is literally the endpoint for 10's of thousands of IoT edge nodes. NodeJS fits in with this architecture perfectly compared to the shoehorning required to make it work with PHP, (C/C++), Python or Java. (N.B.: I am not a java programmer, but we did review using Java, too, but it was voted down for other reasons.)
If there is another asynchronous language that is as well defined as NodeJS and has as much library support, I would very much like to study it.
This. I grew up with Lisp and Smalltalk, yeah I am that old, but today I love Node to build web apps.
It’s a fantastic environment for asynchronous programming. It also has a built-in REPL for a management interface via TCP or Unix sockets. It doesn’t really need any additional packages (I hate the dependency hell that npm saddles you with, and people don’t seem to know that Node already has http, https, and websocket upgrades built in, so you often don’t need any “frameworks” or libraries).
Give me Node, and I can build an entire web app from scratch. Most of the time you don’t even need to use JS in the browser. Just html and CSS are enough. Web apps the way God intended.
I don’t use Typescript either. Its type checking isn’t worth the hassle of poor tooling and inscrutable stack traces.
> The problem started a decade or so ago with Node.
What problem, specifically? People enjoy writing Javascript. It has a ton of fantastic resources online, it is easy to debug and deploy, it's quick to pick up and forgiving of mistakes.
> Too many people only learn JavaScript, become psychologically dependent on it
You sound like Immortan Joe warning people not to become dependent on water in Mad Max. Let people enjoy the language they enjoy developing in.
> they all collectively took it too far outside of a browser.
What does this even mean? What's "too far" even mean? People want to write code, let them?
Unbelievable that this is voted to the top on Hacker News. The comment literally gives not one concrete example or reason by JavaScript is "bad". I'd expect more from you all here.
This happens every time a Javascript topic comes up - hundreds of comments just regurgitating the same "Javascript is bad" memes. It's bad enough that's there's no real point in reading the comments on JS submissions since there's rarely discussion about the article.
I am professional who used python, Java in my Career, and TypeScript is simply the best.
“Too many people only learn JavaScript, become psychological dependent o it “ is simply a false narrative from people who are stuck with obsolete web dev tech stack and refuse to learn better tools
What makes matters worse is that javascript is being pushed as the golden standard language and replacing pseudocode. In recent years I've stumbled across multiple articles on serious topics and concepts such as complex algorithms for compression or image processing and two scrolls down and I see an implementation in javascript.
ActionScript is also an ECMAScript language, and it's kinda ridiculous to see that JS still hasn't quite caught up. Out of things that modern JS lacks, AS had Java-like interfaces and you could specify types on variables.
As someone who first learned to code with AS2/3, I agree it was quite disorienting when I first tried to make a few games with HTML5/JS.
I do think you're not giving TypeScript enough credit -- I felt right at home the first time I used TS, and the type system is much more sophisticated than anything ActionScript ever had. As long as you're of the "favor composition over inheritance" mindset, which I'd argue is better, even for games, TypeScript is a fantastic spiritual successor to ActionScript!
Unfortunately there's no TypeScript-based game engine that makes it so easy to combine code with animations / sound. Nothing has really filled the void that Flash left behind.
JavaScript does not have a monopoly in web browsers. Microsoft supported vbScript and Google made a better and faster JavaScript (Dart) which also ran natively in the browser. But neither didn't take off. You can still "compile" for the browser though, the funny thing is that a lot if not most of the code running on the most popular web sites has gone through at least one compile step. So people don't actually program in JavaScript, it has become more of a compilation target.
TypeScript and JSX are the most popular languages that compile to JavaScript as far as I know. They're very close to JavaScript because people learned straying too far created problems.
Don't do much JS, but this is actually what makes me the most sad. My formative programming years were during an era where there were many competing technologies on most given platforms.
Now days, if I do mobile iOS, I have to do Swift, Kotlin for Android, and as you say JS for browsers. I wish we lived in a world where the platform didn't design the stack so much.
The only reason I'm using node.js is because I can do this:
let num = 0;
route('/url').post(data => num++);
What other languages can I do this in that are better? I simply want to have a variable I can access and mutate from inside closures and let it live in memory without the need for databases or file systems.
> Node is not ECMAScript in a server-side ECMAScript engine, it's JavaScript in a browser JavaScript engine.
Why would your custom ECMAScript server be any faster or more stable than any of the existing browser engines? If you look at the resources behind those engines, I don't know who would match that effort doing the same on the server.
My guess is the browser JS engines are optimized for quick compilation and execution. While a backend engine could optimize for longer, persist runtime.
10 years ago JavaScript was an ugly language, with its clunky prototypal inheritance and so on. Modern JavaScript is a beautiful language, however, especially when enhanced with static typing as in TypeScript. So much so, that Stanford has replaced Java with JavaScript for its introductory programming course [1].
Python is much more limited as an introductory language than JavaScript. JavaScript is very versatile. Need to write server-side logic? Use JavaScript and Node. Need to write a native iOS app? Use JavaScript and React Native. Need to write a command-line utility? Use JavaScript and Node again. Need to make your web page interactive? Use JavaScript in the browser. Python is versatile as well, but not to the extent of JavaScript. JavaScript, when type-checked using TypeScript also scales better to larger projects and development teams. The one area where Python shines is in machine learning, where Python is a de-facto standard. But here too, Python is facing stiff competition from Julia.
I think that it was beautiful 10 years ago, too, if you mainly used a subset of it, relying heavily on closures and avoiding constructors and "this" as much as possible. I think that prototypal inheritance is elegant but in any case, there was never much reason to use any inheritance syntax to begin with other than perhaps in rare cases where one wanted to really maximize performance. As for static typing, while it has its uses, the idea that it makes things more beautiful is subjective.
Arrow functions really are a great bit of syntactic sugar. I know that they are more than that, but since I avoid "this" anyway, for me they may as well just be syntactic sugar. As for the "class" keyword, I find it to be utterly pointless but of course, tastes vary.
Picking a language to teach programming and concepts in computer science presents an interesting conundrum. Do you pick a commercially relevant language (which most students want) or go with one that might be better for academic purposes? I probably lean mostly towards the former because time spent learning something like Eiffel feels somewhat wasted.
No one should have a computer science degree and not know multiple languages and multiple programming paradigms. Prolog, lisp or scheme, C, JavaScript, Haskell. The long term task of the professional software developer is to learn new stuff. Helps if your awareness of the cool things you could learn is already broad. I cannot explain how wrong it is to graduate with Java only and think that is sufficient. To be honest, I would also want people to understand the halting problem and Godel’s incompleteness theorem’s proof, as understanding the equivalence of apparent different systems that can handle the integers is very fundamental. And these days some knowledge of distributed theory is also good, the Lamport time clocks paper and so on. Unless the student is ambitious and doesn’t really like programming and just wants to program for a few years and then get into management or something like that (product? bizdev? I’d that a thing?) they will go thru many iterations of interesting new technologies. The brain that enjoys learning mind-bending shit will have a broader conceptual base and a better chance to see how lisp macro type things can help with k8s configs.
Or while lazy argument evaluation might not be in your language, having it in your tool box for message processing design or you know evaluation of user preference rule sets against an event might be helpful.
No! Eiffel should be the default OOP language for any kind of course. Being forced to think about pre- and postcoditions and invariants by the language is a really good thing for beginner programmers. While the syntax is somewhat verbose (mainly because of using keywords instead of most punctuation) Not teaching about Design by Contract is yet another billion dollar mistake in computer science. There are DbC libraries or frameworks for just about any language, but only very few programmers know about its existence, which leads to criminal underutilisation of the technique in the industry.
I can't be sure, but I think there's a lot of thought, at least, behind selecting a particular language for an introductory course on programming. I don't know which language I would choose, but I'd like something that would broaden the horizons of student as much as possible. It could be Mozart/Oz or something similar.
On the other hand, there are concepts (closures, objects, pointers) that come more naturally with some languages, and you absolutely need to learn the concepts even if you don't end up using the language.
To me, the dilemma is between a language that's easy to learn and one that is useful once you learn the language. Most languages have too many warts and footguns to be easy to learn, but learning a toy language isn't good, either, because it's not useful.
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 ugly and inconsistent it is. I wish I could like it.
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.
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.
JavaScript is backwards compatible. What you wrote in JavaScript 10 years ago will still work today in all JavaScript engines.
Because you mentioned Babel I suspect you actually didn't use JavaScript - but a language that compiled to JavaScript. And this complicate things a lot and is probably the root cause of your wasted hours. The time you save upfront by using some framework you pay back later in maintenance once new versions are released and things get deprecated. In JavaScript itself nothing will ever get deprecated.
1: Trying to fix every vulnerability in any nested dependency is probably not what you want to do. In my experience only a tiny fraction has an attack surface and most are duplicates.
2: Webpack is a monster and updating webpack will always result in a lot of work. If possible use a well supported framework that incorporates Webpack, like Next.js or Nuxt.js. Updating will be a breeze.
3: Don't wait years before scanning for issues, update on a set schedule so it won't become a huge task once a critical issue is found.
Do elixir libraries just never deprecate stuff? Or just that their package managers never alert you about vulnerabilities so you can pretend like they don't exist and so never upgrade?
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.
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.
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.
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.
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. Just started reading it. Seems very good so far.
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.
> 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.
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.
>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.
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.
Yes, indeed. It is really pleasant compared to how it was 10 years ago, and still -- code written 10 years ago, even code written 25 years ago still runs in modern browsers. It's amazing and wonderful.
JavaScript has quite effectively managed to avoid anything the Perl 6 fiasco which greatly contributed to Perl's demise, or the Python 2 => 3 timult, which turns out will not be a kiss of death, but made for some rough years. JavaScript did almost have its own trouble of the same sort with ES4, but it was very wisely abandoned when it turned out to be too ambitious/contentious...
> Yes, indeed. It is really pleasant compared to how it was 10 years ago, and still -- code written 10 years ago, even code written 25 years ago still runs in modern browsers. It's amazing and wonderful.
sadly that is not true. some stuff broke over the years. most often it was not javascript itself but changes in the dom api.
I don't actively use it but I followed it. It is actually a more modern language than pretty much anything else and it seems to have great community that is not a bunch of zealots. Also, it is far from dead.
At the same time Perl5 is also still alive and from the start, it was clear that the two will be maintained in parallel. Perl6 was not intended to replace it, they changed the name to Raku to clarify the situation.
So while it may be a fiasco if you consider the market share, it clearly isn't for the language. Perl5 doesn't really need change, and if you want to change it anyways, it would be for a whole new language, and that's exactly what happened.
I'd like to say it's a testament to the original design; but I can't overlook the hundreds of millions of dollars, perhaps more, that has been spent to improve the language.
It's nothing short of incredible that it is as fast as it is and as useful as it is. It shows that many hands do make light work; and money can buy that effort.
I don't have any numbers to back this up, but I'm pretty sure that between Google, Mozilla, MicroSoft, etc. more resources (both people and money) have been put towards improving JavaScript (language and performance) than any other language in the history of programming. Now I hope someone will provide numbers to show why I'm wrong.
Huge amounts of inspiration came from coffeescript. The biggest advantage of JS has often been going last and executing what is already proven to be a great idea.
I don't know if this is part of the standards but there was a backwards incompatible change in the way regex worked around firefox 73 and a bunch of sites crash in older firefox now.
Backwards compatibility is one thing. But forwards compatibility is something javascript devs have a terrible time with. The standards change fast and new features are added constantly. And unlike, say, Bash devs, javascript devs want the latest and greatest and don't care if it doesn't run on $software from 2 years ago.
Yes they do, that's the entire reason to use Babel. If there's any part of the stack where you have to go to great pains to be compatible with a wide range of completely different environments, it's the frontend. It's the dev environment that churns a lot, partly for that reason.
The Winchester House was continuously added onto by a huge construction crew for many years after the death of Mrs. Winchester’s husband. She believed her psychic who told her she had to continuously add onto the house to repent for the people killed by her family’s rifles during the civil war.
The result is a sprawling, very crazy looking house that no one would have sat down and designed upfront. I think of JavaScript as the programming language equivalent of this house.
Most programing languages old enough have that problem: C#, php, C++.
And modern js does not look crazy, it's the es5 and bellow that was a bit wacky. Typescript is much cleaner than the 3 languages I mentioned, my opinion.
I haven't done much at the level of optimization I think is going on there, and this is Evan's third iteration so I'm guessing there is a lot of insights baked into it, but dang if it's not hard to wrap your head around. Even if you check it out and use VSCode to try to figure it out.
Individual sections of code make sense. But it's like a deconstructed hamburger and you've never seen a hamburger in your life.
ES5 syntax itself has nothing particularly strange. It’s bog standard C/Java syntax. If there’s any complaints to be had, they would be the semantics of using the syntax (though maybe that’s actually what you mean). The worst feature (type coercion) was an intentional addition because many developers asked for it and Eich (to his later regret) went along.
The only other truly weird features came from twisting prototypal inheritance into something vaguely Java-ish. These actually became more convoluted with a whole extra layer of weirdness while once again trying to force traditional classes on top. Unfortunately, devs from other languages think they’re the same and they mostly work as expected right up into things fall apart (usually when the hole they’ve dug is massive).
In truth, the biggest mistake was not going with scheme. If they had, the rest would be easy from language extension to adding lower level abstractions to compiling various languages to it would all be easier.
To pick up on your tangent with a tangent, I think Tim Powers's take of the Winchester House mythology, in his book Earthquake Weather, is my favourite re-interpretation of the story.
As to Javascript - I like the language because it a language that fits best with my way of thinking about code. I'm not sure if that's a good thing to admit.
The very fact that your example uses a house shows this is not limited to JavaScript, or even software for that matter. A relatively famous paper "Big Ball of Mud" by Brian Foote and Joseph Yoder discusses the effect.
Seeing a lot of distain for JavaScript in here, but not enough examples of what's actually wrong with it. It's fine to criticize the language, there certainly are issues with it, but I'd like to see some actual constructive comments and examples from other languages where it's done better.
besides being really insane typing wise, javascript also both really lenient and unpredictable in what it accepts as expressions. Try to guess the result of the following expressions:
> [] + []
>
> {} + []
>
> [] + {}
>
> {} + {}
It means that if you feed it nonsense it does not stop you but happily carries on and explodes a few milliseconds later somewhere else. Another can of worms is the difference between null, 0,undefined, '', ....
Ok, you got me worked up. I need to go for a run to blow off steam.
If your statement begins with a curly brace, that brace is a code block, NOT an object literal.
Coercion rules are terrible, but they were only added to the language due to developer demands.
If you worry about zero or empty string, you’ll have problems in tons of other languages. Null vs undefined is less understandable along with the old ability to redefine undefined as it was a variable . In any case, I agree that one of the two shouldn’t exist.
Most of the complaints aren't really about the language syntax or capabilities. Aside missing proper support for integers, modern Javascript is pretty nice. The complaints mostly come from developers being forced to use either Javascript (only way in the browser), or being forced to change code because of breaking changes in libraries.
Library changes aren’t what they used to be. It was once frameworks of the month. At this point, React has been undisputed king for over half a decade. Major libraries like react, moment, lodash, express, etc all have had stable APIs for years now and aren’t any worse that any other language I’ve used.
Complaints like integers come from not studying the language and not keeping up to date.
Asm.js type directives have offered 31-bit integers for years now on all major JITs. That is slowly not working again as wasm takes over, but BigInt has been included for quite a few browser versions now.
Comparing Javascript to other dynamic languages its comparable and indeed has some nice features - e.g. self style prototypes. If you compare it to more type safe languages like Java, C, Swift, Kotlin etc then it has major flaws. The dynamic languages are great for making little scripts or small-medium size one man projects, they fall down when you need to build something larger with lots of people and lots of code. If you include the problems of javascript with running it into the limited environment of the browser then there is much room for complaint.
I think a lot of the arguments are due to the clash of these two opposing mindsets, people who start in javascript and build things in a browser think it's great, people who build enterprise applications with typed languages disagree, often strongly.
The tooling and ecosystem are the main problems from my perspective. If you set yourself up with Kotlin + Gradle + IntelliJ you now already have all the tools you need.
Want to create/maintain a modern JS/TS stack? Well, you are going to need npm, webpack, probably babel, linters, need to understand how to setup source maps and get those working for debugging server side. etc.
It's a nightmare and it's all very fragile and that isn't even touching on the poor quality of the libraries outside of React/big ones.
Deno is definitely trying to fix that. Single executable, no node_modules, no package.json no Webpack no Babel, built in linter, formatter, bundler, Typescript compiler...
It's definitely not there yet but they have the right idea.
JavaScript is such a polarising topic and I wonder why. Browsers are not dropping support anytime soon and the ecosystem is healthier than ever. Just use it for what it is good at. And if you are wondering what that is, it is a great high level programming language that is good at glueing things together. It is obviously not universal. You won’t write operating systems with JavaScript as much as you won’t write web applications with assembler. In both cases you can try if you are mad enough.
Great programmers and hackers don’t complain about the language as it is irrelevant. They just use whatever is available to get the job done and get it done well. The more programming languages you know well the more you understand that each has advantages and disadvantages. Part of being a pro is to know what to use under what circumstances. What’s the point of comparing apples to oranges?
Finally, you will always need a scripting language with a loose type system even when you start at the low levels. Don’t be so obsessed about type safety, etc. It only shows lack of skills to keep the program model in your head. Gaming engines are scriptable for a reason. It provides different ergonomics that are useful. There are plenty of Rust, Go and Java applications that that replace scripting with ill-conceived configuration templates that resemble scripts except that they are inferior. If you are writing a complex system in Rust, v8 is a modern, expressive scripting runtime that will help you rapidly prototype. That is not say it is better than Lua or Python. It really depends what you want to achieve. But choosing the right scripting language can also drive adoption. So choose wisely!
> JavaScript is such a polarising topic and I wonder why.
If you ask me, the reasons are quite uncomfortable; and has parallels to how a lot of prejudice is seen in society when upward mobility happens. JS now encroaches server-side jobs, while earlier it was relegated to the browser. JS can do scripting. JS can now do native phone apps quite well. It can be used in desktop apps. It also pays well.
> JavaScript is such a polarising topic and I wonder why
Probably because it's a gatekeeper language - in order to run code in a browser, you have to use this language[1]. That means a lot of developers that dislike it enough that they would switch to another language if they could, are stuck with it because they need to target the browser. This "captive audience" is effectively forced to engage with the things they dislike on a daily basis - at that point you either develop Stockholm syndrome, or the resentment grows into hatred. Thus the "warts" that JavaScript has (by nature of having been thrown together in a couple weeks originally, and being iteratively turned into a "real" language over the following decades) have a chance to cause much stronger negative feelings than they would if people could just switch to something they liked more.
[1] I know, I know, WebAssembly may change this, and there are already niche alternatives like Scala.js, ClojureScript, Blazor and Reason - but for the most part, you still can't effectively run things in a browser without knowing JavaScript, even if just for debugging
All good things start small and evolve. The C programming language was created over the weekend if I am not mistaken and look how much it stuck for better or worse. JavaScript was also accidental. There was a time you could program web sites in VisualBasic, ActiveX, Java, Silverlight and Flash. They are now all gone. There is no denying that the JavaScript language is resilient. It stuck for better or worse.
Developers can choose to program in whichever language they want but only JavaScript is officially supported on the browser. Any other language will require a transpiler or compiler (when it comes to WASM). Similarly you can program iOS and Android apps in whichever language you like but only Objective-C/Swift and Java are officially supported. All other languages you need to support yourself. The official spoken language in UK is English whether you like it or not. You are free to speak any other language you want but social frameworks and civil services evolve around a single language.
If developers are so smart how come we cannot understand these basic principles?
My argument on why it's polarizing is largely historical. Javascript was a hot mess for decades. I stepped away from web design for a while simply because accomplishing anything meaningful in js always felt like a hacky mess to me. At some point, getting anything done required learning new frameworks getting obsoleted within a year or so (jquery?).
It's a reputation that's hard to shed.
Last year I finally started to dabble in Node. Though I fully understand the criticisms of Node, learning it really did open my eyes on just how far js has advanced. I'm really loving the present state of js callbacks/anonymous functions, leading to elegant solutions that I now miss when going back to Python.
I'm sure there are many other factors that play into this (just look at Gary Bernhardt's "WAT" talk), but essentially, I agree that this has to be a big part of the problem. If you've been developing backend systems and asked to hold up robustness and stability guarantees for multiple years and then run into Javascript, you will likely run into situations where you have to make up for its deficiencies in that regard.
That doesn't make it a bad language per se -- that's the case with any language in some aspects -- but since JS will be a new language to you, you're much less likely to accept that situation as a given.
"Gaming engines are scriptable for a reason" - I'm sure I've heard the opposite opinion from respectable sources at least 2 times. Here's Jonathan Blow
https://www.youtube.com/watch?v=y2Wmz15aXk0
I agree with the rest wholeheartedly.
Readit News
Are we looking at the same web technologies here or are you from an alternative universe?
Despite all the mess, I have an easier time getting buttons on a screen and doing things sanely (once all the fuss is set up) compared to trying to get the ball rolling in Qt/GTK/etc (especially if you're not using Java or C++)
Edit: The React repo is 3 million+ lines of code, written in its own niche language...
Deleted Comment
Is this a React thing?
Waiting for the extra request(s) adds lag time, makes back/forward navigation clunky, interrupts what I was doing if I already began interacting with the page (eg. infamous relayout / unwanted scroll) and sometimes breaks snapshotting tools like archive.is.
I don't mind pages with javascripted controls, but their initial content should be included in the payload with the initial page load. Don't the frameworks have tools to help you do that?
The problem with that is that it pretty much requires you be running node on the back end too. If your back end is built with say PHP or Ruby, you’d need to call out to a node process, which is potentially a lot of additional complexity, time, and expertise.
I agree with your overall point 100%, but to be honest nothing in React was / is innovative except for the virtual DOM diffing, but even that is becoming increasingly irrelevant as apps are moving towards more and more reactive architecture. React made a huge impact on web dev and deservingly so, but all of the other ideas have been implemented and used on the web before.
Of course it's great that React is bringing some of these good ideas to mainstream, but they've been there way before they have been distributed along with a VDOM algo.
Maybe there wasn't much academically innovative in React, but it certainly brought declarative, functional UI programming to the masses. Its innovation was in making that as easy and accessible as possible with a tiny API.
I feel saying React wasn't innovative is so dismissive and ignores the massive paradigm shift that's happened in web development because of it.
After all, like you suggest, things like functional programming and monads have existed for quite some time. The thing that makes React special is how rabidly people adopted it, and continue to adopt their major updates.
Is this true? I've worked in web dev for like 6 yrs now and React has provided a significant number of concepts and technologies I'd never seen before and still dont see elsewhere.
For example, JSX. Yes, it originated in php but React was its first time being implemented in the frontend.
Also the concept of hooks and functional components. The fact that you explicitly define side-effects in the render of a function, with memoization or execution dependent on arbitrary state, is a new invention as far as I'm concerned.
Could you expand on this? What was it that necessitated DOM diffing before, and which architectural changes are making it irrelevant?
[1] - https://css-tricks.com/say-hello-to-css-container-queries/
I’ve had pretty decent success using this library.
This is a good resource that will walk you through the cutting edge web development technologies, starting from the very basics and progressing to the more complex matters in the end. Highly recommended.
https://www.st.com/en/evaluation-tools/p-nucleo-ihm001.html
For $35 you get a little motor, a motor control board, and an ARM micro-controller board. ST includes some software for motor control. If you want to do precision motor control, out of the box it is missing an encoder (a device that tells you the position of the motor). The STM32 chips usually have some inputs you can use with a quadrature encoder, so you could add one if you needed to. It does include a current sensor and the software uses the for field-oriented control (FOC), so you can efficiently and smoothly control the speed of the motor. To learn more about motor commutation and FOC, check out this document:
https://www.actronic-solutions.de/files/actronic/FTPROOT/Fie...
For an example of stuff people have built with them, here's a Robot Inventor-based Rubik's cube solver: https://www.youtube.com/watch?v=_cl2Wur8waY
But the most significant feat React achieved IMO is how easy to write asynchronous hiearchical actors (from actor model) with it (kind of like erlang vm).
Context enables dependency injection and ownership management. Effect and state enables object ownership and lifetime management. Js timers, (i.e. setTimeout, setInterval, queueMicrotask, promise/async), help making an object living asynchronously as if it has its own private thread.
Yes, those are similar concept of lifetime and ownership Rust have, but instead of functions/blocks the object (value in memory) is owned by/shared with components. And of course these are not enforceable by compilers/transpilers/linters due to them not being a javascript-primitive, but at least React helps organizing those things in a lot more explicit and clear manner.
Dead Comment
The problem started a decade or so ago with Node. Too many people only learn JavaScript, become psychologically dependent on it, and they all collectively took it too far outside of a browser.
ECMAScript is a general purpose standard, but it was invented retroactively. Node is not ECMAScript in a server-side ECMAScript engine, it's JavaScript in a browser JavaScript engine. That's just too much of a force fit, and has wasted too much potential for me to say anything positive about it.
I've commented this many times before, but having a system where everything is on the same tech stack (i.e. front end in TypeScript with React, back end with TypeScript on Node) has resulted in gargantuan productivity gains, especially for a small team where it's trivial for people to cross front end to back end seamlessly. For contrast, I know many teams with a backend in Python and a frontent in React/JS, and I've worked on some teams with that setup. In my opinion it's virtually all downside compared to a backend in TS, as Python and TS are quite similar from a web programming perspective (I'm not referring to Python's advantage in data science tooling), so all it basically is is a barrier to your front end folks being able to make small enhancements on the backend quickly.
Furthermore, TypeScript is a great language and I find myself being so much more productive in it than I was in Java, especially when it comes to refactoring.
JavaScript most definitely has its warts and head scratchers after being around for 25 years, but I feel like most of these oddities (truthy/falsey, typeof null === 'object', undefined vs. null, etc.) can be learned in an hour and written on a half page.
So you’ve come to it at a time when the syntax and capabilities have a popular subset that actually starts to fulfil the early promise. And yet, despite the article above, one may still be enormously critical of the anemic and inconsistent standard library, and don’t even get me started on the horrifying dependency shitshow of the node ecosystem that cripples maintainability of anything over 18 months old.
Just because we’re all holed up in the throne room, doesn’t mean there aren’t monsters still roaming the sewers, just a few levels down.
As for isomorphic code, I strongly encourage my competitors to write backend code in the same fashion and the same breath as the front-end, because the resulting tight coupling and special-case-driven technical debt makes them easy to outmanoeuvre when markets shift. And if they’re reading this then please also consider microservices, graphql, and nosql data stores whilst you’re at it, for the same great reasons.
Front and back do different things, have different requirements. You control the architecture on the back end for instance, not on the front. The back end deals with data modeling and processing, the front with layout, very different task, very different skills, and the language is just a small part of it.
There is some overlap, for exemple I remember having to code a clock twice, once on the back end of to show it correctly the first time, and once on the front to have it refreshed in real time, the code could have been shared, but these occurrences where code can just be copy-pasted are not that common.
And BTW, most of my web dev was JS/PHP/SQL, and I actually liked all three languages for what they did. JS, I had no choice, but it did event handling well. PHP was good at generating HTML from a database and SQL, despite its age is still king for querying databases. I wouldn't want to use these languages for anything else.
In a backend where you need a heavy-duty, multithreaded process to handle long-lived computations, node is probably not the way to go unless you want to pay for all the extra instances you'd need for the same amount of load. In my experience, for example, a java-based graphQL server (that spawned multiple connections to various services) needed much much less in the way of resources than the node equivalent serving the same amount of traffic - AND the latencies were generally much better with the java server, depending on the size of the JSON payloads that it was handling.
All that being said, you can certainly architect your way out of that problem and I imagine a relatively small percentages of web applications even HAVE that problem.
> Node is not ECMAScript in a server-side ECMAScript engine, it's JavaScript in a browser JavaScript engine. That's just too much of a force fit
And what makes V8 a "browser JS engine"? A focus on:
- rapid startup. Code starts running immediately, JITs quickly. The VM is designed for latency, not just for throughput.
- excellent sandboxing. The VM is designed to run untrusted code.
- no blocking code. Designed for callbacks and promises. No threading, no thread.sleep(), no mutex, etc. Makes is much easier for non-expert developers to write fast & reasonably correct code.
Now look at things like Cloudflare Edge workers, Lambda etc. Modern server environments share all of those same design goals.
Server-side JS/TS not only has the advantage of a single codebase. It also brings the design and engineering advantages of a browser VM to the server.
I don't really see how. TS doesn't seem to solve any annoying problems I previously had in Java. As a concrete example, it would be nice to have the concept of a DTO as a first-class language feature, but alas, I find myself constantly casting and re-casting, plucking, or writing endless wrappers to make sure properties trickle down (or up). Hell, sometimes I just give up and use `any`. I mean, this is a web-first language that has no concept of sending objects over the wire.. okay then.
TypeScript's generics system is cute, but I think it's mostly academic. And did you look at the toolchain? To get TS working, you need babel or ts-node or webpack, and like 3 different .json config files. Importing a package without TS support? You need to write some stubs yourself in types.d.ts. In fact, the best parts of TypeScript are actually JS (await/async, arrow notation, spread operator, etc.).
It would be better if there were no oddities in a language. One of the reasons why everyone hates PHP is that it is full of inconsistencies, odd design choices, weird naming and unexpected behaviour. JS has at least some of these.
If there was a second of third language available in the browser, then that too could be used to develop back-end applications and would have the benefits you describe - that you can use the same language for both stacks etc. For example - if you could front-end stuff in Python, would it be amazing or bad? Or would the current JS devs just fear for their jobs because of it?
Is there any Typescript backend framework as mature as Django?
> Python and TS are quite similar from a web programming perspective (I'm not referring to Python's advantage in data science tooling), so all it basically is is a barrier to your front end folks being able to make small enhancements on the backend quickly.
So on the on hand, the languages are "quite similar", yet it cannot possibly be expected that frontend people learn more than a single language? Something doesn't add up here.
This is of course subjective, and maybe I'm biased due to having a lot more experience with python than JavaScript.
How so? Is it just about being able to use a single set of tools, libraries, habits, etc? Or are there particular things which are easier when the language is common? Are you sharing code between front-end and back-end.
I do very lightweight front-end coding these days. It's usually some variation on populating and updating a table from a websocket, maybe with some simple filtering and toggling in response to user interaction. There, i can't think of any particular advantage to having both ends in the same language, but then mine is quite an unusual use case.
How big of a problem is this?
At the end of the day all that really matters is that the external representations that get handed off are the same and that everyone makes the same assumptions. Given the same set of fields manipulating a POJO with Java streams is not all that different from using modern Javascript on a blob.
i highly doubt that - i don't disagree you got productivity gains, but it's not from being the same stack, but it's from experience gained doing it.
If what you say is true, why doesn't people use GWT (google web toolkit) and java on the backend to get this productivity gain? It has existed even earlier than typescript, and is compiled to be quite fast. It's even more integrated as a stack, and anyone knowing java is able to use it fairly easily.
Undergoing a similar path. My problem is that the moment I switch to TypeScript and start writing my code becomes very similar to Spring. And at that point I have to ask a question of why would I not just write Java. Node on the other hand feels like node.
Deleted Comment
Whenever I encounter Node, issues almost always follow. Whether it's NPM's delightfully useless error messages or a stream of neverending warnings filling up stdout, it quite literally never fails to cause a problem. Maybe Node should focus on saving it's reputation, because I for one run in the other direction of it. Hell, especially in the case of Node, I hope that Deno comes to replace most of it's core functionality. Putting up with half-assed software on a half-functional runtime only leaves me with a quarter of the patience I started with.
* Lexical scope natively without syntax or conventions
* Functions as first class citizens
* Inheritance, classes, OOP are not forced on you and can be ignored/omitted entirely from your code
Those few things are what has kept me hooked on the language.
> Node is not ECMAScript in a server-side ECMAScript engine, it's JavaScript in a browser JavaScript engine.
What does that even mean? The APIs are completely unrelated and Node does different things that don’t make sense in the browser.
I assume you mean over the alternative, dynamic scoping like in e-Lisp. But you realize that JavaScript's scoping rules are entirely wonky, e.g. that "var" declarations are lifted to the function level?
What language of the last 28 years doesn't "natively" lexically scope its variables?
- `const fooFunc = () => {}` is treated differently than `function fooFunc() {}` in declaration and subsequent access.
- A function's invocation context changes depending on how it was declared (fat arrow vs. function declaration)
Don't get me wrong: I love JS, but this is not one of the things I felt made it intuitive.
>What does that even mean? The APIs are completely unrelated and Node does different things that don’t make sense in the browser.
I have taken the privilege of rewriting the quoted part of the parent comment,
Node runs javascript on the server side in an engine built for the browser. It does not run ECMAScript with an engine specially made for server side apps.
Maybe try some other languages...
JS is like PHP... only a popular language because it's been around a long time and it's easy to get started. Otherwise, there are SOOO many better programming language out that the ONLY reason JS still has traction is it became the "default" web language.
I'm continually frustrated by my colleagues refusal to step outside the javascript ecosystem. Don't get me wrong, JS certainly has its place but its not ALWAYS the best tool for the job. I see a lot of people reach for node as their go to backend tech choice simply because its the ONLY tool in their toolbox.
Unless you're building a small focused microservice where the functionality involves calling out to a library with working tested code that does what you want, I think node is honestly a poor choice. To qualify my statement, I spent the first 7 years of my professional career building software with nodejs.
The sweet spot is much smaller than the scope of projects people throw at it.
* quick MVP? rails has more libraries that are drop in.
* Performance? go and elixir have node beat for multicore perf
* websockets? compared to phoenix channels, everything in node for serving websocket apis are a toy.
Lambda functions though? yea nodejs kicks but there!
I’ve done plenty of backend work in all of TS, Scala, Go, Python and PHP. Scala is my personal favourite, but it’s not as practical for teams as TS or Go, which are both very productive languages, with good enough type safety and performance, that new devs can learn quickly. And I’d easily choose TS over PHP or Python for a large system.
Plus, it IS pretty nice being able to use a single language everywhere. My current company is TS RESTful services with TS/React on the web, and TS/React Native on mobile, pretty hard to beat how easy it is to do full stack dev work for most ppl in this setup.
JS has no parallel computing support, so it is not an option. And when I say parallel computing, I don't mean distributed computing, I mean utilizing hundreds (thousands) of cores on a single die, like NVIDIA architectures. (It's a black art, even addition algorithms can confuse the newcomer.)
The best course is to do what every other language does when it comes to simple-parallel operations, like Gauss-Jordan elimination: use a dedicated, optimized library, like NumPY.
I really hope some day there will be a numpy for JS. NumJS is dead, and Google's TensorFlowJS is excellent for utilizing GPUs, but a dog when trying to do simple operations (the load/store async nature doesn't quite fit with most use cases.) I suspect WebAsm will facilitate the parallel nature of tensor operations without having to move
Why do you think it's not a good language for this?
Also, I see a lot of value in using a one single language that can truly do everything: frontend, server, and scripting.
I guess you could use Python or Ruby like that with Wasm, but I haven't seen evidence of people doing that.
But I am hopeful that when I finish reading the article I will not have to reuse my jquery / d3 based framework for doing quick data viz things (which I only started doing with great reluctance because people don’t go wow over tabular data even if the data is wow-ing. The first request to make it pretty, i switched to mono space fonts. But jquery is showing its age.
Edit: I also worked on a node app that should have been written in a staticall typed language. Bugs that could have been caught at compile time literally caused me utter misery in on call overtime. All because some guy in our team demanded we wrote it in node. This was way before type script. I actually feel physical pain thinking about.
React on its own is much simpler, once you grok the react compositional model. I don't know how you can do that while using redux too.
If you put bad developers on other languages they usually end up running into some wall first but Javascript is pretty forgiving.
Does anyone have any reading material on this? I've never heard it and a quick Google turned up nothing, but I'd love to read about it. Unless it's a joke that went over my head...?
Do you have any evidence for this? Because there's plenty of reasons why you'd share the same code in the browser and the server. Being able to do SSR and sharing validation logic are two huge and obvious reasons. Ever try to exactly duplicate validation rules between the browser and PHP? What about when they use weird regexp rules?
I have a site builder codebase that renders previews instantly as you make changes, then uses the same code on the server to render the HTML and CSS for visitors. That would be otherwise be outright impossible to do without writing the same code again in another language.
PHP is adding support for FFI to any C ABI-compatible language, and you can run the exact same code in the browser via emscripten or a WASM polyfill. As a bonus, emscripten/WASM compiled code will also be more efficient in the browser than plain JavaScript or Typescript.
Let me give you one example:
Lets say you want to validate if a string is a valid URL. What is a good way to do this in JS?
Just for reference in Ruby for example I can do:
No gems or any other engines needed.If there is another asynchronous language that is as well defined as NodeJS and has as much library support, I would very much like to study it.
It’s a fantastic environment for asynchronous programming. It also has a built-in REPL for a management interface via TCP or Unix sockets. It doesn’t really need any additional packages (I hate the dependency hell that npm saddles you with, and people don’t seem to know that Node already has http, https, and websocket upgrades built in, so you often don’t need any “frameworks” or libraries).
Give me Node, and I can build an entire web app from scratch. Most of the time you don’t even need to use JS in the browser. Just html and CSS are enough. Web apps the way God intended.
I don’t use Typescript either. Its type checking isn’t worth the hassle of poor tooling and inscrutable stack traces.
What problem, specifically? People enjoy writing Javascript. It has a ton of fantastic resources online, it is easy to debug and deploy, it's quick to pick up and forgiving of mistakes.
> Too many people only learn JavaScript, become psychologically dependent on it
You sound like Immortan Joe warning people not to become dependent on water in Mad Max. Let people enjoy the language they enjoy developing in.
> they all collectively took it too far outside of a browser.
What does this even mean? What's "too far" even mean? People want to write code, let them?
“Too many people only learn JavaScript, become psychological dependent o it “ is simply a false narrative from people who are stuck with obsolete web dev tech stack and refuse to learn better tools
insert ragequit gif here
It's accessible, popular, easy enough to use, and ubiquitous. All the ingredients for success.
Does it belong on mission-critical spaceships? Whether you like it or not, the answer is yes, of course it does. https://os-system.com/blog/javascript-in-space-spacex-devs-h...
Because the language wasn’t planned to support all of this from the start, we just shouldn’t use it.
There’s lots of great reasons to use a full JS / TS stack. There’s lots of reasons not to.
Doesn’t mean it’s inherently bad. This is the same logic used against PHP every day yet it’s used all over.
IE did support VBScript, and only finally "killed" it in 2019
https://blogs.windows.com/msedgedev/2019/08/02/update-disabl...
(Yes, I know about TypeScript.)
I do think you're not giving TypeScript enough credit -- I felt right at home the first time I used TS, and the type system is much more sophisticated than anything ActionScript ever had. As long as you're of the "favor composition over inheritance" mindset, which I'd argue is better, even for games, TypeScript is a fantastic spiritual successor to ActionScript!
Unfortunately there's no TypeScript-based game engine that makes it so easy to combine code with animations / sound. Nothing has really filled the void that Flash left behind.
TypeScript and JSX are the most popular languages that compile to JavaScript as far as I know. They're very close to JavaScript because people learned straying too far created problems.
Now days, if I do mobile iOS, I have to do Swift, Kotlin for Android, and as you say JS for browsers. I wish we lived in a world where the platform didn't design the stack so much.
Why would your custom ECMAScript server be any faster or more stable than any of the existing browser engines? If you look at the resources behind those engines, I don't know who would match that effort doing the same on the server.
Dead Comment
[1] https://web.stanford.edu/class/cs106j/handouts/01-GeneralInf...
Arrow functions really are a great bit of syntactic sugar. I know that they are more than that, but since I avoid "this" anyway, for me they may as well just be syntactic sugar. As for the "class" keyword, I find it to be utterly pointless but of course, tastes vary.
Or while lazy argument evaluation might not be in your language, having it in your tool box for message processing design or you know evaluation of user preference rule sets against an event might be helpful.
I can't be sure, but I think there's a lot of thought, at least, behind selecting a particular language for an introductory course on programming. I don't know which language I would choose, but I'd like something that would broaden the horizons of student as much as possible. It could be Mozart/Oz or something similar.
Don't pick one, pick a healthy mix.
Protoypal inheritance and class-based inheritance where classes are themselves first-class objects aren’t really all that different, anyhow.
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
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.
Because you mentioned Babel I suspect you actually didn't use JavaScript - but a language that compiled to JavaScript. And this complicate things a lot and is probably the root cause of your wasted hours. The time you save upfront by using some framework you pay back later in maintenance once new versions are released and things get deprecated. In JavaScript itself nothing will ever get deprecated.
Deleted Comment
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.
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.
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.
Also there have been attempts before but nothing really stuck. How many non-Googlers use Dart?
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/
[1] https://idom-docs.herokuapp.com/docs/index.html
[2] https://dash.plotly.com/
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.
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.
JavaScript has quite effectively managed to avoid anything the Perl 6 fiasco which greatly contributed to Perl's demise, or the Python 2 => 3 timult, which turns out will not be a kiss of death, but made for some rough years. JavaScript did almost have its own trouble of the same sort with ES4, but it was very wisely abandoned when it turned out to be too ambitious/contentious...
sadly that is not true. some stuff broke over the years. most often it was not javascript itself but changes in the dom api.
I don't actively use it but I followed it. It is actually a more modern language than pretty much anything else and it seems to have great community that is not a bunch of zealots. Also, it is far from dead.
At the same time Perl5 is also still alive and from the start, it was clear that the two will be maintained in parallel. Perl6 was not intended to replace it, they changed the name to Raku to clarify the situation.
So while it may be a fiasco if you consider the market share, it clearly isn't for the language. Perl5 doesn't really need change, and if you want to change it anyways, it would be for a whole new language, and that's exactly what happened.
It's nothing short of incredible that it is as fast as it is and as useful as it is. It shows that many hands do make light work; and money can buy that effort.
The result is a sprawling, very crazy looking house that no one would have sat down and designed upfront. I think of JavaScript as the programming language equivalent of this house.
And modern js does not look crazy, it's the es5 and bellow that was a bit wacky. Typescript is much cleaner than the 3 languages I mentioned, my opinion.
Heh, read the VueJS 3 code base.
I haven't done much at the level of optimization I think is going on there, and this is Evan's third iteration so I'm guessing there is a lot of insights baked into it, but dang if it's not hard to wrap your head around. Even if you check it out and use VSCode to try to figure it out.
Individual sections of code make sense. But it's like a deconstructed hamburger and you've never seen a hamburger in your life.
The only other truly weird features came from twisting prototypal inheritance into something vaguely Java-ish. These actually became more convoluted with a whole extra layer of weirdness while once again trying to force traditional classes on top. Unfortunately, devs from other languages think they’re the same and they mostly work as expected right up into things fall apart (usually when the hole they’ve dug is massive).
In truth, the biggest mistake was not going with scheme. If they had, the rest would be easy from language extension to adding lower level abstractions to compiling various languages to it would all be easier.
As to Javascript - I like the language because it a language that fits best with my way of thinking about code. I'm not sure if that's a good thing to admit.
Ok, you got me worked up. I need to go for a run to blow off steam.
Coercion rules are terrible, but they were only added to the language due to developer demands.
If you worry about zero or empty string, you’ll have problems in tons of other languages. Null vs undefined is less understandable along with the old ability to redefine undefined as it was a variable . In any case, I agree that one of the two shouldn’t exist.
Complaints like integers come from not studying the language and not keeping up to date.
Asm.js type directives have offered 31-bit integers for years now on all major JITs. That is slowly not working again as wasm takes over, but BigInt has been included for quite a few browser versions now.
I think a lot of the arguments are due to the clash of these two opposing mindsets, people who start in javascript and build things in a browser think it's great, people who build enterprise applications with typed languages disagree, often strongly.
Want to create/maintain a modern JS/TS stack? Well, you are going to need npm, webpack, probably babel, linters, need to understand how to setup source maps and get those working for debugging server side. etc.
It's a nightmare and it's all very fragile and that isn't even touching on the poor quality of the libraries outside of React/big ones.
It's definitely not there yet but they have the right idea.
Deleted Comment
Deleted Comment
Great programmers and hackers don’t complain about the language as it is irrelevant. They just use whatever is available to get the job done and get it done well. The more programming languages you know well the more you understand that each has advantages and disadvantages. Part of being a pro is to know what to use under what circumstances. What’s the point of comparing apples to oranges?
Finally, you will always need a scripting language with a loose type system even when you start at the low levels. Don’t be so obsessed about type safety, etc. It only shows lack of skills to keep the program model in your head. Gaming engines are scriptable for a reason. It provides different ergonomics that are useful. There are plenty of Rust, Go and Java applications that that replace scripting with ill-conceived configuration templates that resemble scripts except that they are inferior. If you are writing a complex system in Rust, v8 is a modern, expressive scripting runtime that will help you rapidly prototype. That is not say it is better than Lua or Python. It really depends what you want to achieve. But choosing the right scripting language can also drive adoption. So choose wisely!
If you ask me, the reasons are quite uncomfortable; and has parallels to how a lot of prejudice is seen in society when upward mobility happens. JS now encroaches server-side jobs, while earlier it was relegated to the browser. JS can do scripting. JS can now do native phone apps quite well. It can be used in desktop apps. It also pays well.
Probably because it's a gatekeeper language - in order to run code in a browser, you have to use this language[1]. That means a lot of developers that dislike it enough that they would switch to another language if they could, are stuck with it because they need to target the browser. This "captive audience" is effectively forced to engage with the things they dislike on a daily basis - at that point you either develop Stockholm syndrome, or the resentment grows into hatred. Thus the "warts" that JavaScript has (by nature of having been thrown together in a couple weeks originally, and being iteratively turned into a "real" language over the following decades) have a chance to cause much stronger negative feelings than they would if people could just switch to something they liked more.
[1] I know, I know, WebAssembly may change this, and there are already niche alternatives like Scala.js, ClojureScript, Blazor and Reason - but for the most part, you still can't effectively run things in a browser without knowing JavaScript, even if just for debugging
Developers can choose to program in whichever language they want but only JavaScript is officially supported on the browser. Any other language will require a transpiler or compiler (when it comes to WASM). Similarly you can program iOS and Android apps in whichever language you like but only Objective-C/Swift and Java are officially supported. All other languages you need to support yourself. The official spoken language in UK is English whether you like it or not. You are free to speak any other language you want but social frameworks and civil services evolve around a single language.
If developers are so smart how come we cannot understand these basic principles?
Last year I finally started to dabble in Node. Though I fully understand the criticisms of Node, learning it really did open my eyes on just how far js has advanced. I'm really loving the present state of js callbacks/anonymous functions, leading to elegant solutions that I now miss when going back to Python.
I'm sure there are many other factors that play into this (just look at Gary Bernhardt's "WAT" talk), but essentially, I agree that this has to be a big part of the problem. If you've been developing backend systems and asked to hold up robustness and stability guarantees for multiple years and then run into Javascript, you will likely run into situations where you have to make up for its deficiencies in that regard.
That doesn't make it a bad language per se -- that's the case with any language in some aspects -- but since JS will be a new language to you, you're much less likely to accept that situation as a given.