"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/
I also want to give mention to JavaScript: The Good Parts by Douglas Crockford[1], and his new book, How JavaScript Workers[2]
[0]: https://eloquentjavascript.net/
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?
ES6 and ES7 are widely supported now and are much better languages IMO.
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.
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).
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.
Today this book makes a good companion but not a great single source reference.
Sometimes I jokingly call htmx "web 1.1 tech", but increasingly I wonder if I'm really joking.
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.
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!
It's like a whole world I had been sealed off from has reopened.
Out of curiosity, which features are you looking for in a "proper" front-end? Flexibility?
https://github.com/streamlit/streamlit/issues/1440
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.
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.
[1] https://github.com/streamlit/streamlit/pull/1494 [2] https://discuss.streamlit.io/t/displaying-images-from-opencv...
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.
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.
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.
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.
Anyone who really grokked REST would never say it's nonsense to use with a JSON API.
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.
I'm sorry, I couldn't resist the pun.
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.