A good way to not be completely overwhelmed by all the new tooling and frameworks is to have a strong grasp of the fundamentals, here are three foundational resources:
I also want to add the great Eloquent JavaScript[0] to this list. While its targeted at learning programming as a whole, its still a wonderful resource, even for seasoned programmers, to learn some ins and outs of the language if you haven't had a lot of experience with it.
I also want to give mention to JavaScript: The Good Parts by Douglas Crockford[1], and his new book, How JavaScript Workers[2]
I would like to take this opportunity to point out that the author of "Eloquent JavaScript", Marijn Haverbeke, also created both CodeMirror and ProseMirror [1], which are both extremely well-regarded open source code/text editing tools. I can especially recommend ProseMirror after spending a lot of time with it recently. It's an actually sane wrapper around contenteditable.
I've been wondering lately, as I'm moving (back) into a JavaScript-heavy stack (it's been... 4-5 years for me), is this book still relevant in the face of 12 years of JavaScript language development?
I personally never really liked that book even when it was new. It's good if you wanna get up and running with JS fast while coming from another language, and are forced to use JS in places but it's not the main language of your project.
But it doesn't really give a strong foundation on understanding the language. It's more like "I know mainstream C-inspired languages, and JS often burns me with its weird quirks like how the this keyword works, I just want to avoid getting burned". But it doesn't really embrace JS itself, just sort of acknowledges that you will be forced to use it in the web so you may as well at least learn the "good" parts.
It's still decent at that purpose, but for really strong competency in JS I can also vouch for the Eloquent JS book and the You Don't Know JS series (I've only read the first edition, a new edition is partially complete and available online).
> it doesn't really embrace JS itself, just sort of acknowledges that you will be forced to use it in the web so you may as well at least learn the "good" parts.
I'm sure you know this, so I'm just pointing it out for completeness sake: that was indeed the only sensible approach to JavaScript back when that book was written.
The code in it will still run and work but there are much better patterns and features now that help you write more succinct and less error-prone code.
ES6 and ES7 are widely supported now and are much better languages IMO.
Thanks, that's kind of what I thought. I recently, finally, took it off of my book shelf and stuffed it into a box in the garage, but it's been in the back of my mind a few times as I've been going through other resources. It's good for the historical understanding but I couldn't see it being terribly relevant today.
As a noobie, Eloquent Javascript was much better for me than The Good Parts. The Good Parts was a book of how not to program, followed by the right way of doing it. Eloquent was a guided path to understanding the language without being shown all the dead ends.
Knowing the dead ends and the history behind them is nice, but I spent a lot of brain power on the dead ends that Eloquent put towards better use.
We're also talking a small book vs a tome of knowledge, but the philosophy is different regardless of size.
Unless the book has had an updated edition it's missing all the ES6 good stuff. It was good to avoid the pitfalls of JavaScript in the past, but nowadays you should be using ES6, strict mode and, if that strikes your fancy, TypeScript.
I would not give it to a beginner, but definitely to an intermediate-plus developer from a non-JS background. The best parts are the reasonable but strong opinions and the admittance of very bad parts. The code is less valuable today but as mentioned above, still runs fine.
Today this book makes a good companion but not a great single source reference.
Agreed. I think a lot of folks suffer from not understanding how web 1.0 worked and really groking REST/HATEOAS (which has since been hijacked for JSON APIs, which is complete nonsense.)
Sometimes I jokingly call htmx "web 1.1 tech", but increasingly I wonder if I'm really joking.
In 1996-1998 as a teen I "made some websites" for local businesses. The one I made for my parents even had a search function (in PHP) in a CSV with their products (which were like 100). The CSV was generated by taking whatever Lotus Approach (their desktop DB) generated and transforming it with some custom Haskell code (I was a teen, what did I know). They clicked an icon to pull the data and another to run a FTP batch file.
Fast forward, I understand nothing of the website being developed in React for my startup. The othe technical cofounder does grok it, but I could not lend a hand and can barely even supervise the outside help we brought. I like to think of myself as well-versed in a generalist manner. I can hack a custom sparse matrix (with a very particular structure I was able to prove an iteration for) inversion algorithm, but I understand nothing about painting the background the correct shade of blue!
Same for me. I even got into CSS and Javascript. Just, you know, right as Ajax was becoming a thing, before SPAs, before Rails even, etc. It was very straightforward.
Now...I'm lost. Every time I poke at the frontend, I get lost again. >10 years as a backend developer of various stripes, three of those in Node even...still lost.
Yow. I have an application growing out of control in Streamlit (https://streamlit.io), which is a rshiny-type interactive dashboard gizmo. I'm now able to consider rewriting it with a proper front-end.
It's like a whole world I had been sealed off from has reopened.
It's over a month old now, with multiple people reporting the same bug and iterating on the problem with no apparent narrowing towards a reason for why this happens, let alone a solution.
Thanks for clarifying. Since HN isn't the right place for a detailed discussion, I would invite you to comment on that issue and try to help us work through it.
As one of our engineers mentions in the linked issue, this bug is hard to trigger (as is the nature of many bugs), and she is working on a solution[1]. This issue has also been reported here[2], with the solution of adding time.sleep(1) inside the loop usually resolving that problem.
Yeah. What I should have added here, but didn't want to sound brash and rude, is that Streamlit should focus on having a reliable working product before spreading out as an org with a Dev Relations department.
I know this is a complicated problem domain (because it's the web, Mathematica did this well with complex graphs in the mid-90s), but as it stands now my project has an input on which the graphic depends and a default value; the image breaks before the input control is touched. And it's not a slider, it's a dropdown that makes the app query a db first... I mean, I think I can do this in plain Ajax if I get my story right about sending images. But it's a hobby project meant to explore mathematical ideas...
If you can't do sliders reliably, they should be moved to a beta branch. Streamlit overpromises and underdelivers. But it's a great project, I don't want to be too negative about it.
I see you've both commented here and on GitHub, so I'll make my last comment here and then we can address the specifics on your ticket (I didn't realize I referred you to your own GitHub issue).
As I mentioned, there is a pull request already created for this issue; our head of engineering/founder says its being held up by a lack of tests before merging. This problem isn't a slider issue, but a race condition in our session state manager.
Regardless, one month is a pretty trivial amount of time as far as open-source projects go, as well as in the history of Streamlit (project became public Oct 2019). Like all projects, we try and address things in the order of severity, and as far as this issue goes, it's a pretty isolated one, not an indication that the library is unreliable or somehow reflects that our engineers can't design at an early-90s level of engineering.
Well it depends, because maybe you're using Styled Components or some other library that ties you into the React/JSX ecosystem.
Or maybe your app passes a 'theme' through various contexts and you have to find the right theme and find the thing you need to tweak the background colour for, which might be in a CSS file pulled in through Webpack if you're lucky.
If you're not lucky, maybe there's some funky SASS/LESS setup where all of the colours are stored in variables describing their purpose, in one of a dozen specially categorised files for storing globals. Now there are six or seven values all with '#xxxxxx' as the colour value and you don't know which one it is, so then you're thinking, is this `lightBlue7` or `darkBlue-3` or `cyanish4`.
Or maybe a few event listeners pull down style information into the component state after first rendering with a bunch of placeholders, so now the component you're looking to change the background of is a function of the time spent on page.
Or, maybe you found some CSS and it was an easy change, but then the project is in Typescript and the CSS is actually derived at build-time from an enum containing all of the config, which is used to replace specially formed strings in the CSS while having sensible defaults in dev.
If you're cursed, the CSS isn't even in your frontend at all and a server-side rendering system is generating your styles from DB backed configurations, which are queried by a graphql layer in your frontend so users can customise their UI in their profile settings, so you have to write a database migration and run a full deployment to add the new colour and its customisation UI to the frontend.
I think if I was promoted to CEO, I would go full reactionary and demand that all front end javascript code must be vanilla and interact with the dom directly, and all styling contained in css
Yes, I know it's confusing because the language has been so thoroughly corrupted over the last decade.
Let me show you my reasoning:
JSON is not a hypertext, even if you include URLs in it. [0]
HATEOAS requires a hypertext (see the first word of the acronym)
HATEOAS is "an essential part of the of the 'uniform interface' feature of REST" [1]
Therefore a JSON API, even with some embedded URLs, using multiple HTTP Methods and following a traditional hierarchical path scheme, is not REST-ful.
[0] - A sufficiently advanced client could interpret a JSON-encoded hypertext in a general, uniform manner. However, in practice, this is almost never the case.
Yeah, but it doesn't make up for the decade+ now that plain JSON (perhaps with the occasional URL, which still has to be interpreted correctly by client code!) has been called "REST-ful".
On top of that, JSON-LD is still mainly focused on networked object graph serialization. Unfortunately it manages to be a complex specification without providing the functionality that HTML came with out of the gates as a hypertext in an obvious manner.
HTML is a good-enough-to-great hypertext, we should probably stick with it.
In order to learn JS you should grasp the event loop. Once you learned to think async, being able to write queues, limit concurrency, etc its just different flavours of syntax and ES6 is mostly syntatic sugar.
If you are a web dev you should learn the basic web APIs and avoid libraries and frameworks at all cost. Dont use React until you have written a web component without it.
Also if you are a web dev, learn CSS its very simple and powerful once you understand that a rule below overides a rule above, and a more specific rule overides a less specific rule.
What helped me most understanding the tooling around babel & co was to watch an intro video from vue.js on the new Viue 3.0.
Copying anything by hand while he explains it. With minimal package count.
And always use a code generator later like when you start a Typescript/JS project, because you can do so many little things wrong on your own while you don't know enough.
I would add
Javascript- The definitive guide (David Flanagan)
I just bought it again, Version 7 just been released 9 years after version 6.
It’s an amazing book.
"You don't know JS": https://github.com/getify/You-Dont-Know-JS
"How browsers work": https://www.html5rocks.com/en/tutorials/internals/howbrowser...
"High performance browser networking": https://hpbn.co/