Eloquent JavaScript 3rd Edition (2018)
eloquentjavascript.net
eloquentjavascript.net
For those interested--Besides this book, my current learning plan includes: Javascript 30 by WesBos Exploring ES6 [http://exploringjs.com/es6/] Learning React-2nd Edition on O'Reilly Learning The Beginners Guide to React on Egghead Data Structures and Algorithms in JavaScript on Egghead.
I also used Kent C. Dodds' excellent "JavaScript to Know for React" article as an outline.
I've been working through the following resources with a decent amount of success I think:
1. Fullstack React: The Complete Guide [0] - a wonderful book with a bunch of practical applications to build
2. Learn CSS Layout [1] - A nice write up for understanding what CSS actually is doing
3. Mozilla HTML Reference [2] - Can't get any better than this documentation
4. Eloquent Javascript 3rd Edition - Book being discussed, really enjoying working through it.
Obviously, the React and Redux documentation have been great as well. I don't think that just those really give you the full picture that you need though if you actually want to build professional web applications.
Just another side of the coin, I suppose.
[0] https://www.newline.co/fullstack-react/
[2] https://developer.mozilla.org/en-US/docs/Web/HTML/Reference
Does it have a good documentation?
Yes? Cool. I dive in head first.
No? Hard pass.
I'm the same, I can read 1,000 technical pages no problem and make you a great talk, but I'll remember nothing past a month (or 12...) if I don't actually use it.
https://kentcdodds.com/blog/usememo-and-usecallback
Granted that's probably because on a good day my reading comprehension is not great and learning within a narrative works way better for me.
Basics concepts - https://reactjs.org/tutorial/tutorial.html
My measure of success is being able to understand development at a lower-level. Learning new languages, frameworks and building side projects helps me through the low periods and enables me to work more fluently with developers.
I have experience with Javascript and VueJS from a couple of years ago, so my goal is to catch up with modern JS (ES6+), brush up my JS core knowledge (not just frameworks) and learn ReactJS. It's very likely that I won't finish everything on my list this month, due to other obligations, but that's ok. I'm not competing with the experts out there, I just want to learn new skills and build things that I couldn't before. I also have a bit more time now that I'm stuck at home on evenings and weekends.
Then I learnt that prototypal inheritance is a superset of ''class''ical inheritance [1] as well as this [2]. Hmm.
With Reflect, Proxy etc. you have great metaprogramming capabilities that make this language much powerful.
Still, there are some (many?) edge/corner cases and unfixable bugs (aka features) that the language is stuck with for the sake of backwards compatibility and developers have to learn these. (The most famous of these might be typeof null === "object")
When I look at the amount of features added to the language specification, sometimes it seems like it is going to become another incarnation of the C++ specification.
I still like its expressiveness and power, but if it becomes another C++ in future, I have to look somewhere else. (TypeScript maybe.)
[1]: https://aaditmshah.github.io/why-prototypal-inheritance-matt... [2]: https://wiki.c2.com/?ClosuresAndObjectsAreEquivalent and https://www.crockford.com/javascript/private.html
Those requirements are chosen because they lead to ease of implementation: prototype objects are the quickest and dirtiest way to enhance an interpreter such that programs can be written in it that are discernibly OOP-ish.
They don't represent a set of requirements that amount to a good OOP system.
Author finally opened his eyes.
In JavaScript you have precise control over inheritance, you can specify your own algorithm for how class A inherits from classes B and C. It's a totally different beast to classical inheritance in Java that has such a bad reputation because it's such a straightjacket
> In JavaScript you have precise control over inheritance, you can specify your own algorithm for how class A inherits from classes B and C.
Yeah maybe, but please don't do that.
Language flexibility doesn't obscure the readability of code. It enhances it. In a flexible language, unclear code is always programmer error, and programmer error is fixable. In an inflexible language, a lack of clarity can sometimes be unavoidable (e.g. java programmers forced to shoehorn everything into classes)
I don't find it shocking, I think it's a sign of immaturity. Been there, done that.
> Language flexibility doesn't obscure the readability of code. It enhances it.
Given a language without any sorts of constraints, any program can and will be written in any conceivable style.
In design - not just programming language design - constraints are generally a good thing.
> In a flexible language, unclear code is always programmer error, and programmer error is fixable.
Virtually all errors are fixable in principle. In practice, there's a budget. Your clever and elegant but utterly idiosyncratic abstractions are costing me money in terms of getting people onboarded.
> In an inflexible language, a lack of clarity can sometimes be unavoidable (e.g. java programmers forced to shoehorn everything into classes)
This is not a bad trade-off at all.
A flexible language invites architecture astronauts to re-invent the concept of classes or modules over and over in slightly different ways. That's Javascript until ES6 and we're still suffering from it.
The best example of that in programming language design I have seen is the V programming language. (https://vlang.io)
No global variables, no null/undefined/nil/None/... V is the only language I know in which variable shadowing is an error. (Do you know any other language with this feature/constraint?)
And then I remember the handling of ''var''s in js and hoisting etc. ... sigh!
gcc -Werror=shadow
$ gcc -Werror=shadow -x c -
void foo(int x) { { int x; } }
[Ctrl-D][Enter]
<stdin>: In function ‘foo’:
<stdin>:1:25: error: declaration of ‘x’ shadows a parameter [-Werror=shadow]
<stdin>:1:14: note: shadowed declaration is here
cc1: some warnings being treated as errorsI did not dare to open the gcc man page, now I think I will look at it.
For that constraint, one have to pass an option. I want to know if any language (other than V) which has this as default.
The next level of enlightenment is figuring out that applied FP isn't that great either and to use whatever makes sense, wherever it makes sense.
Sometimes opinions are great to get everyone on the same table even if for some usage, some things might not be appropriate.
I think opinions generally achieve the opposite of that. That said, if you're sitting at the table where everybody believes in FP, you should wholeheartedly apply FP principles - or find another table. That's part of "do what makes sense, where it makes sense".
The really good thing about OOP though is that nobody really believes in it anymore. That opens up the opportunity to take some good ideas and insights and apply them undogmatically.
FP has good ideas and insights as well, but it's more difficult to separate those from the cargo cult surrounding it.
Looks rather like eyes closing to me.
Java has single inheritance, which sucks; but it has multiple inheritance of interfaces at least, and good luck doing any serious work in Java without that being involved. (That is also designed that way in order to pander to implementation ease and certain run-time efficiencies; but has been turned into fallacious arguments like "multiple inheritance is bad ... unless it's interface inheritance").
Oh, and one problem with this prototype business is that in fact it is single inheritance (in the typical incarnations, at least; am I invoking a strawman)? It seems inescapable that supporting multiple inheritance under the prototype paradigm requires that we make a single new object out of two or more existing objects. But if objects are effectively just bags of properties (a.k.a. hash tables) it does seem easily doable. Make new empty object, stuff with properties of all argument objects, season to taste, return.
Yes, to hack up, so what? Non-prototype object systems can also be written simply and in a small footprint, and have a reasonably small description.
A prototype object system is barely one step above pretending that a hash table is an object.
2. It's powerful.
It's not expressive of OOP concepts and creates spaghetti code. All OOP is monkey patching: make this object like that one, but patch this.
3. It leads to smaller, less redundant code.
Because you're not properly specifying classes, which serve as an important guide to the structure of your program, and provide a locus of control.
We can achieve smaller and less redundant code by identifying every function that is only called once and manually inlining it, so there is no name that is redundantly mentioned two places in the program. That doesn't mean it's a good idea.
4. It's dynamic and hence it's better for dynamic languages.
This point is subtly fallacious. Dynamic languages also have non-prototype based object systems, which are also dynamic and good for those languages. There is good dynamic and there is bad dynamic.
Under prototype object, it's hard to do certain important dynamic things like redefine the method of a class such that all objects of that class (existing instances) use the new method.
Non-prototype objects systems in dynamic languages can easily support prototype-like mechanisms without those being the main mechanism of organization of OOP programs.
Failing that, in any dynamic language that gives you hash tables, you can ignore the fine OOP system and do prototypes with hashes.
Objects have function-valued properties called methods. So Objects can't do without functions.
Functions can return either a) atomic values like strings and numbers OR b) Objects. Note that in JavaScript Functions are Objects too.
So I hope no-one is seriously suggesting that FP can do without Objects, by saying that functions should only return atomic values.
Note that you can have methods which do not depend on mutable state. In ES6 you can FREEZE objects, which you could do in the constructor. Freeze the object after having set its "instance variables". Now all methods of that object are "pure functions". So you can choose. Choose to create pure functions or impure.
Creating a new immutable instance really is equivalent to creating a set of immutable ('pure' if you like) functions.
A couple key realizations made this much less of a "choice" for me (warning, my opinion):
1. Classes et al, are just a high level pattern which happens to be builtin... functions are far far more rudimentary.
2. If you use a high level pattern "just because you can" without considering the subjective cost vs benefit, it will be a poor fit on average.
What does this mean?
#1 Functions are not the opposites of classes, they are simpler, lower level abstractions which are more generalized - It should be thought of as the default.
#2 Like any pattern, OOP has a cognitive cost - When they don't fit a problem well, they merely obscure relationships between state and function; when they do fit a problem, they will minimize that cost and provide benefits that simplify other code.
If you don't immediately know that classes or prototypes fit the piece of code you are writing... just stick to functions, if later on you find that a collection of functions emerge with a common signature and persistent state being passed back and forth - you might have something that would benefit from a class, but you can simply change them into a class when it emerges. However if you do it preemptively you will probably be wrong and also make poor decisions about what the internal encapsulated state should be (which you want to minimize since you are obscuring it). It's ok to discover that something should be a class, attempting to make the choice up front is usually going to go wrong unless it's very obvious.
I think it's unfortunately a pretty natural path to start out not having an opinion of OOP and then potentially developing a distaste for it later on - not because it's inherently bad (it's probably the most generalized pattern and very useful); but because of it's integration into so many languages... I see it get abused by people all the time who just make a class by default for no apparent reason, which inevitably ends up as a bag of loosely associated state and arbitrary functions mutating one or more of those states. In such cases the class is of no benefit, and worse, it's obscuring all of the unrelated state mutations making it difficult to read and reason about.
It's not very clear what you are asking, neither what's your background. In your situation I wouldn't spend more time learning stuff about JavaScript, I would just improve my skills in software engineering (design patterns, code quality, refactoring, etc) and diversify my knowledge (learn other languages (python, go, or some FP language to learn something really different); databases and SQL; web servers and REST; etc).
(you can buy a hard copy of it if you want but it's open source)
https://github.com/getify/You-Dont-Know-JS/blob/1st-ed/READM...
You're going to have to look for talks and really technical posts. Consider whitepapers and source code for JavaScript engines at this point. You'll probably want to start reading up on the things attached to JavaScript, rather than the language itself. Browser rendering, event loop, V8 things, garbage collection, etc.
I'm sure you've seen it, but things like this: https://www.youtube.com/watch?v=8aGhZQkoFbQ, and this: https://www.youtube.com/watch?v=SmE4OwHztCc
It might be time for you to start writing what you know about JavaScript.
Also Typescript is well worth learning.
There's knowledge about how to express certain patterns in a given language, more like an application design expertise. There's knowledge and familiarity with the APIs. And then there's the deep language knowledge, the one that pretty much only someone implementing a language VM, parser, compiler and other tools may acquire with time. Also, there are a lot of specifics about every particular JS implementation.
Also, Dunning–Kruger :-)
On the internals of VMs, https://mrale.ph/ has a lot of blog posts on internals/optimizations on V8. https://www.wingolog.org/tags/javascript also has deep JS articles very freqently.
If you really want to go all out, you could write a simple JS interpreter. Probably don't want to go full spec compliant but you could implement a decent subset. Especially if you skip the parsing step with Acorn https://github.com/acornjs/acorn
Also the You Don't Know JS series. And Elliot's Programming Javascript Applications.
I don't know you, so I don't know if this applies or not, but be careful not to fall into the "expert beginner" trap (i.e. Dunning Kruger). Your first sentence starts to feel that way, but the fact you're asking for more resources and aware there are things you don't know are good signs. Always keep learning, the rabbit hole goes ever deeper.
Reading into specs (ECMAScript[0], W3C[1]), some more approachable explanations[2] of them and some implementations[3, 4] of embedded engines seem to be my approach.
[0]: https://tc39.es/ecma262/2020/ [1]: https://github.com/w3c [2]: http://dmitrysoshnikov.com/ecmascript/javascript-the-core-2n... [3]: https://bellard.org/quickjs/ [4]: https://v8.dev/docs/embed
Knowing the internals of the engine really informs you on performance and resource utilization characteristics of various ways of writing code.
on edit: one reason the specs are not enough is generally specs will tell you what needs to be implemented but a good book, like these ones, will tell you how it has been implemented or what the spec implies for implementation and what all that will mean for you as a user of the language.
when you're done, you'd have learnt enough on the way and know what you don't know
Little things like this I am nit-picky about, but overall, great book.
[0] https://eloquentjavascript.net/05_higher_order.html#h_fx3e34...
I now program JS for a living so i guess the book also really worked. Thank you for the third edition!
> This much anticipated and thoroughly revised third edition of Eloquent JavaScript dives deep into the JavaScript language to show you how to write beautiful, effective code. It has been updated to reflect the current state of Java¬Script and web browsers and includes brand-new material on features like class notation, arrow functions, iterators, async functions, template strings, and block scope. A host of new exercises have also been added to test your skills and keep you on track.
For example, a book that could go into details of code practices at companies like Airbnb, Facebook, or Google.
However, for those looking for a great way to learn Typescript from a beginner's perspective I can fully recommend Execute Program[1].
I would be particularly interested in this. The OP has a chapter on "Program Structure" but it seems like more a toolbox of language constructs.
It would be nice to see a book that went through a few archetypes of common JavaScript programs (command-line script, daemon, enhanced webpage, single-page app) and gave a basic blueprint for what parts are needed and how they interact.
Domain modeling can feel close to "type driven modeling" here. A good book in that regard is "Domain Modeling Made Functional"[0]. I see types and a functional paradigm closely related, but keep in mind that this is just one approach in your toolbox... there might be the case where a GoF OOP pattern works good as well[1]. I think it's also important not to try to trick the TS compiler into something, but rather to work with it. Keep in mind that the TS dev team is giving you a lot of freedom by not striving for a provable correct type system[2].
To really take advantage of TypeScript I think it's good to know where a type system is coming from, what it is that it's trying to solve and how it is doing that. I think it's helpful to have a look into other languages with a "strong" type system (Haskell[3], OCaml, rust) and see how they are doing it. Then you may get to see how Haskells phantom types will conflict with TypeScripts type inference, and OCamls type inference seems to work in fascinating ways compared to TypeScript. After working through the advanced types[4] in TypeScript it's good to understand what a "good abstraction" in case of a type system is and what isn't... this is when you discover the similarities to other languages through the common language of abstract mathematics (and abstract data types). In every program you'll encounter effects and monads are quite helpful to work with them, this is were a sound type system can really shine.
I feel with every JS/TS project you will build a lot of the projects toolchain yourself and you kind of need to discover what fits best. It's good to be able to catch possible bugs early with the TS compiler, quicktype[5] can help you in building some typed contracts to other projects.
A separation into packages with lerna[6] should encourage a good separation into packages and is seen in a lot of open source projects. Speaking of, reading into good open source packages will be a mandatory way to go in order to learn more.
[0] https://fsharpforfunandprofit.com/books/ [1] http://loredanacirstea.github.io/es6-design-patterns/ [2] https://github.com/Microsoft/TypeScript/wiki/TypeScript-Desi... [3] http://learnyouahaskell.com/ (a bit dated though) [4] https://www.typescriptlang.org/docs/handbook/advanced-types.... [5] https://quicktype.io/ [6] https://lerna.js.org/
I highly encourage you to not solely stick around JS/TS for patterns. For me, JS/TS is the "most" multi-paradigm language in usage to date, thus is not one of those languages that needs to be written in a certain way. Other languages can give you patterns more clearly and those are for the most parts adaptable to JS/TS. Haskell made it click for me on how to model with types, Elixir has the interesting concurrency/resilience pattern with supervisors etc... There are also good JS libraries whose usage still feels like programming and less "using a framework"-like - RxJS has an interesting approach for events/subscriptions and I feel like redux-saga showed me a very good use case for generators.
He was writing a book about it too, which seems to be done: https://solidbook.io/
Not affiliated.
How would this work for say, an XMLHttpRequest? Since you have to next into callbacks there I don’t think yield travels the function boundary...so you abuse next instead?
This would look something like:
function fetchUrl(url,done){
var xhr = new XMLHttpRequest();
xhr.onreadystatechange = function() {
if (xhr.readyState == XMLHttpRequest.DONE) {
if (xhr.status === 0 || (xhr.status >= 200 && xhr.status < 400)) {
done(null,xhr.responseText);
}else{
done(new Error("something went wrong"))
}
}
}
xhr.open('GET', url, true);
xhr.send(null);
}
let response=yield fetchUrl('http://example.com',next);
var someFunction =casync(function*(url,next){
var xhr = new XMLHttpRequest();
xhr.onreadystatechange = function() {
if (xhr.readyState == XMLHttpRequest.DONE) {
if (xhr.status === 0 || (xhr.status >= 200 && xhr.status < 400)) {
next(null,xhr.responseText);
}else{
next(new Error("something went wrong"))
}
}
}
xhr.open('GET', url, true);
var response = yield xhr.send(null);
...
});I found generators useful for implementing my home-brew parsers. Parsers must try out all possible combinations of possible syntactic elements before they can say that parse failed. Generators are a good tool for that
Insteresting ! Would you mind sharing how you did ?
I see there’s Angular (not AngularJS that I worked with), React, and some other frameworks. I see there are all kinds of bundlers and plug ins for these things.
When I was doing AngularJS, I’d just link to a few dependencies manually from a CDN. Looks like now there’s a bunch more complexity and package management for front end dependencies.
It feels like FAR more complexity, but I’m not sure what has been gained. I also don’t know that much, so would love to learn perspectives here from people actively developing in this space.
One of the main strengths (and according to some, weakness) of Angular is that it has everything you might need to create a full featured SPA out of the box, and it's all tightly orchestrated by the Angular CLI. Creating a component or a service is a simple command, and many third party packages leverage the CLI (Angular Schematics) to install and configure themselves in your codebase. Core packages--such as such as forms, router, angular material--are all high quality (by Google), updated together, and work cohesively with each other. That means updating even major versions of Angular is an easy `ng update` command. For me, the minimal configuration overhead is a BFD, as I plain hate that stuff.
The fact that Typescript has been a first class citizen of Angular from its outset makes development pretty enjoyable. I'm so used to exploring APIs using intellisense, leveraging types to figure out what data types can be passed in functions, relying heavily on auto-complete/auto-import to pick up my pieces and finish typing a word for me and importing the corresponding library while I keep going.
Granted, there is a significant learning curve. But once you get over the initial learning curve, you become incredibly productive. Arguably, the learning curve in other frameworks is worse, given that you have to research what libraries to use (e.g., which forms library, with its own set of conventions), configure it, and make sure it plays nice with the other patchwork of libraries.
If you're interested in a fresh, lighter, framework-free approach, have a look at svelte: https://svelte.dev/ I'm using it on a current project and loving it so far.
Essentially so you could do HTML/CSS/some-other-language (using asm.js, emscripten, or some similar technology) instead of HTML/CSS/JS.
https://watchandcode.com/p/practical-javascript
Eloquent Javascript is a good book now that I know more about Javascript, but please NEVER EVER recommend it as the first book for an absolute beginner.
With 20/20 hindsight, what I wish I had done is read through or watch one or two courses without any pressure, just get familiar with the topic, and don’t worry if I don’t understand things.
things start clicking into place after you’re exposed to this stuff a few times. My mistake was that I wanted to understand everything and didn’t want to skip ahead if I didn’t.
I mean, that's totally correct, but that's paragraph 7. It's way too abstract for a beginner to understand - and usually, if a beginner is getting lost in the first few pages, they're unlikely to make progress in the book (even though they probably could in this case, by skipping ahead a bit).
I am now about a year and a half of being deeper into the language, and I have finally picked the book back up again.
I agree with the other commenters that the early chapters would probably move a little slow for an experience programmer, though it is beautifully written and the interactive snippets are great, so you might still enjoy it if you don't mind skimming. Or if you know some languages but only have a few years of experience I would say beginner intros to new languages are still good. Eloquent JavaScript is a really nice overview of clean programming style in JS as well as the language itself.
I'll definitely give it a re-read and update.
I'm surprised they attempted timeouts in promises with so little text, that's actually pretty dangerous pattern because it glosses over the complexity in actually stopping an in-flight promise. It is VERY easy to end up with hundreds of thousands of unresolved promises with their pattern. Dangerous!
There is a great repo on this issue.... aand I can't for the life of me find it. Basically there's a github project that uses generators and passes an atom down through the call stack to ensure everything below the race promise is aware that it is being halted. And even that doesn't handle all the nuances of this pattern.
And if anyone knows what github repo I'm talking about, I'll give you ... 50 DKP?
What are those nuances in JavaScript which aren’t handled by it?
Let's take a great of example of where promises are used most often: AJAX. If the endpoint isn't RESTful and there is state on the other end, cancelling a promise requires updating the entire module of the new state. There can be multiple reasons for cancelling, and the code needs to be aware of what is happening beyond a simple timeout.
Same thing goes for USB devices (via libusb+ffi) and serial-ports (via serialport). In flight requests can disturb state if cancelled, and it makes the programming very complex to just time-out.
One could argue AJAX and hardware programming are outside the domain of JavaScript, but I wouldn't.
I guess it is more than a "nuance", it is the observance that cancelling an asynchronous operation in general can have unintended consequences if not handled correctly ... beyond memory leaks from unresolved promises.
One thing that is tricky with async is that nobody tells you if the async function never does what it should. I wish they would add some more built-in support for that in the next JS version.
Promises hold promise (pun intended) but they are a bit too complicated for my brain.
>One thing that is tricky with async is that nobody tells you if the async function never does what it should
Could you clarify this?
But when you call an async-function that is supposed to do something like say write to a file or database maybe there is an error which makes it never do its job, and never call the callback you gave it. But the rest of your program just hums along happily. There is no error. The error does not "happen" but the error is that "something did NOT happen". And when something does not happen you don't get an error or notification saying that something did not happen.
You run your program but expected results do not show up in database. But you don't know why, because the problem is that some of your async functions did NOT call something they should have called.
It's hard to detect that something does not happen.
Some kind of built-in support for callback-timeouts might alleviate this problem.
>maybe there is an error which makes it never do its job
You can throw an error regardless of the reason why it failed to do its job. If the write to the db does not success, you can throw an error.
So your async function never calls fs.write() even though it was your intention that it should. Is that an error? Definitely, the file was never written to, it now has wrong content. But the problem is, as you run your program you do not get any error thrown at you, therefore you don't even know there is a problem. Later on you may, or may not, realize that the content of the file is wrong. And then it's hard to say what caused that error.
What "caused something not to happen" is a difficult question to answer because you can't pinpoint the exact location in time and code where it did not happen. Why? Because it did not happen anywhere, ever :-)
If there is an error when reading a file or accessing a database, unless the file or database API is horrendously designed, it will reject the promise or throw.
I would say it stops unless there is something keeping it running.
Think about your single-page-web-app. When you click on some widget on it a click-handler triggers and executes that code. But then it stops. When the user doesn't interact with your web-app no JavaScript is typically executing, unless you have set up a repeating polling loop with setInterval().
I don't think using explicit callbacks helps, though, which has the same potential issue (worse really, since you're probably handling callbacks directly more often, depending on the patterns you use).
It helped to detect some flaws in my program.
A similar thing could no doubt be done with promises. But I think the best solution would be if there was a built-in facility to detect callbacks that were not called within a required or default time interval.
Eventually I stopped using the timeout wrapper, it didn't help very much, but made the code more complex. More but easier to understand code is often my preferred choice.
Whereas if language itself offers built-in facilities then fine since they are more likely to be bugfree than my own code.
But I assume in a thread-based language like Java all asynchronicity happens due to threads. Then from the programmers' point of view method-calls always either return a result or throw an error. They don't just silently stop executing
I've been toying with the idea of a promise free async/await implementation lately. I'm interested in feedback anyone would have.
Perhaps if you create and publish a simple comparison solving a given problem with Promises vs. CaSync it would show that CaSync takes much less code?
That could convince more people to take the time to try it out.
I'm thinking of trying (if I have time) to build a babel transpiler plug-in so you could use it with keywords like async/await instead of explicitly wrapping generator functions. I think the syntax would end up very simple.
I see no reason to use callbacks, unless the NodeJS module dev didn't implement promises. And even then I write a wrapper. I'm glad to see later versions of Node include promisified versions of things like File IO.
I agree. They are easier to use. But they require more effort to write. Promises are easier to use than create. Maybe they are the direction in which public APIs will go but I do find they take extra effort to write, compared to callbacks
I find javascript really hard and annoying, even if I have enough experience with JS that lets me build a basic react framework, I still find it hard to use.
On top of that, getting javascript jobs is harder compared to other programming languages. IE: you need 7 years of experience for a company at the same level where they only need 1 year of IOS/Android experience.
You always have to be keep up to date. The popular libraries that you can use changes so fast, and sometimes they don't even work.
Javascript gets a lot of disrespect from beginner engineers. Something about doing frontend work, isn't hard and it isn't software engineering in their perspective
There are so too many ways to do the same thing, unlike something like lets say golang
You always have to learn more than javascript to compete with other javascript developers. IE: dev ops, backend, database, sre, ux design
The half life of all these frameworks and libraries that come into fashion is pretty annoying. The principles don't change much though.
I don't like that it caters to both the object-oriented and fp world and becomes a mishmash of both.
JS is indeed hard, learning vuejs for the sake of 'it's simpler than react' right now.
For example, I'd say JS/React is vastly easier than learning Cocoa/UIKit. Writing GUI code that runs on N user devices is harder than writing headless code running on a single server.
Btw, if they're getting downvoted, it's because "oh, Javascript is in the title? time for me to complain about it like people do in every JS-related HN thread!" is a tired HN comment.
On the note of the HN's perceived hatred of JS, I think its because Javascript has tried to do too many things. Despite its quirks I like Javascript in the context of the web browser, but what I dislike it that it exists in applications and on the server side. The Atom editor should not take up 200 MB and take forever to boot. But it does because instead of taking the time (like sublime text) to write a rockstar system code, they instead used electron. The feeling I get sometimes is that JS developers want to program the same way they do in the browser, everywhere.
or just bundle a html/css/js with a single go-http-server-executable that use browser as the GUI interface.
I think Electron was the webdev community's response to this, and we really haven't gotten one on the app/systems developer side besides QT.
Or to rephrase, using Electron to "emulate" a web browser is cross-platform from the perspective of the electron user, while most other gui-ing solutions in C/C++, are not necessarily cross-platform, and therefore this leads to different set of challenges.
Are we reading the same HN? Because I would say being too critical and negative are HN's two biggest flaws.
Job requirements for iOS & Android might say one thing, but you'll still be competing with people who have way more experience than that, unless the company behind the listing refuses to budge on compensation and is up-front about it.
One thing that iOS really has going for it is that (IMO) it suffers from ageism far less than other SWE verticals do. I'm having trouble with putting the reasons for why I think this is the case into succinct words, but I would say that the primary reason is that iOS knowledge & experience gained while working is, in most cases, additive. The only exceptions are when things are deprecated, but from what I've seen, this usually just involves API signature changes. The core framework has stayed the same, and SwiftUI is going to be the first significant change. You're also forced to constantly learn new things every year, because you're forced to update, and forced to accommodate new screen dimensions with designs.
The downside of this is that it can be extremely difficult to break in as a beginner without doing an internship at a company that can afford interns. You are competing with people who have anywhere from 3-12 years of experience. Or you're competing with people who did the aforementioned internships and did not receive an offer.
(I definitely agree with you about the disrespect JS gets from those who don't grok frontend work. And the fundamental annoyances baked in JS from the start)
I think most everyone agrees JS is an outlier when it comes to the speed of breaking changes and obsolescence, but IMHO that is nearly inextricable from JS being the most widely-adopted language, compatible with the widest variety of end-user devices and applications, reaching by far the most humans across the world. To put it another way, you could easily learn and become proficient in COBOL. There's currently a bigger demand than ever for young blood, and there's presumably great career rewards (if not in salary, in benefits, timeoff, and pension funds), and the language and end-user application is extremely stable.
And of course there are plenty of disadvantages (higher chance of landing somewhere that is not SF or NY, if those cities happen to be your home). Do the benefits of COBOL, especially the ones that line up with Javascript's weakness, hypothetically meet your ideal of a developer job?
The most ideal languages at a certain time is based on what is most in demand, relative to the supply company needs
Right now mobile developer demand > supply, for top tech companies at least relative to JS developers
edit
Posting like this breaks the site guidelines. If you wouldn't mind reviewing https://news.ycombinator.com/newsguidelines.html and sticking to the rules when posting here, we'd be grateful.
left side of my name has a number
far right side of my name has a number
left side of my name is the points of my comment
right side of my name is the comments beneath my comment
I never realized that
also thanks for pointing out the rules of the forum, sometimes people forget
and thanks for modding hn
the bug that i find surprising is when i type a text, i need to make two breaklines to show one breakline
Do you mean the number like [+11] that shows up after you've collapsed a subthread? If you click it, do the comments beneath your comment reappear and the number goes away?
Edit: I'm pretty sure that is the confusion, because it's the second time in a few weeks that this has come up. I've changed the "collapsed" indicator to say "[5 more]" instead of "[+5]". Hopefully that will solve the problem. The strange thing is that it took almost 4 years to hear about this.
Wow, great job of getting that shipped real fast, It's really obvious now
Maybe other people already experienced this issue in the past but didn't really know who to report it to, or wasn't big enough of an issue
I love it when you can take years to fix something and someone will still say that anyway :)
(The same thing happens in the HN inbox. "Wow, thanks for the fast reply"...if they only knew.)
even if its just the fronend?
wouldn't it help if your community of hackers decided to contribute? it seems like a good majority of people are willing to work on it
im assuming that since a lot of people are playing with the hn api