room271

This kind of AMP-like approach is something I'm a big fan of for simpler, more news-like articles. There are potentially a lot of developer experience and user experience (especially performance) benefits if done right. For my thoughts on the whole AMP-style vs React/SPA approach see: https://niclong.uk/2019/07/20/amp.html .

The thing is, I would rather you are more restricted or stop driving for Uber, and full-time drivers get decent terms, then you get to keep your (seemingly) unnecessary side money and full-time people, for whom it is the main job, have substandard conditions and rights.

Ideally there wouldn't be a tradeoff, but in practice it seems like there is one.

Thanks, this is a pretty great write up. It's not a langauge-war, the discussion is knowledgeable and pragmatic, and I like that you recognise that a language suitable for work might be different from one you'd use on a side project.

I am still amazed Uber IPO'd for what it did (even though it was still considerably less than they'd expected).

'By this everyone will know that you are my disciples, if you love one another.' (Jesus, John 13:35)

$6k for 32gb ram and a 256gb SSD?

I'm not sure this is really about Huawei at all, so in a sense it doesn't really matter if they have (up to now) done anything wrong. It's really about the extent we feel comfortable trusting the Chinese government.

Now obviously, every country has its own agenda, but there are (arguably) stronger reasons to be concerned about China than most others. They are undemocratic and suppress significant parts of their population (the Uighurs, Tibetans, Christians, ..), don't believe in free speech or freedom of religion, but also have a large economy and military presence. Now of course, other countries are not saints, but the differences with China (and in particular its disregard for human rights) make future disagreement much more likely.

Clojure is particularly well suited - at least Rich Hickey would claim - to real world applications with unsafe or unstructured inputs. I.e. complex programs that receive or pull data from external and loosely-typed sources. A lot of web programming falls into this category. Why is it well suited to these? Because it is dynamic, and offers rich runtime solutions to validation (Spec), has immutable data structures, safe and relatively simple concurrency primitives, and has the expressivity of a lisp. It also has access to the vast array of JVM libraries which helped early adoption (but possibly hindered it in the longer term?!).

In addition to the other replies, it also depends on your computer. I have a new Matebook 13 and 18.04 didn't quite work as well out of the box for me as 18.10, because it lacked some of the newest drivers and the laptop has some pretty new components. But if you have an older laptop, or a desktop computer it's probably less relevant so the LTS version is likely better.

I have six years programming in Scala and I unfortunately agree with everything in this article. Our work experience is very similar; competing approaches/styles, poor tooling, and slow feedback cycles. The language itself is nice is many ways, but it turns out that these things are more important.

We've started using Typescript a lot for http-templating style use cases (instead of Play) and I'd lean towards Go for the pure networky stuff. Combined these give a much better experience than Scala for our types of use cases.

Ha yes definitely. One of our motivations in this work is to be able to identify and serve only the CSS that is needed for the specific page/components being requested.

Hey thanks. I think probably our experiences are just different here. I've found that convention (one css file next to the JS component in this case) is sensible but can break down over time or with larger dev teams. In these cases, I tend to prefer a technical constraint over convention when there is a choice between the two and it's for something important. On tracking down the styling, we haven't found identifying the relevant component where CSS lives difficult in practice but I can see that might not always be the case.

Edit: just to add, the comment in this thread https://news.ycombinator.com/item?id=19608498 does a much better job of explaining all the benefits of CSS-in-JS.

(I work on this team at the Guardian but views my own.)

You are definitely right that there are still challenges around how you structure and re-use JSX components.

However, our primary motivation with CSS-in-JS was to achieve decoupling between different parts of the page when it comes to CSS. I.e. if I change this part of page A, will I break other parts of the page? Or even, will I break something on a completely different page? By scoping styles to components, CSS-in-JS helps avoid these kinds of issues. Of course, it introduces its own complexities.

This is really not an academic concern on a large website with daily commits by developers often from different teams and not necessarily experts in CSS. Only last week I had to fix an issue of this kind.

That's reasonable. But you still have to obey the law in the meantime.

I'm not sure why the above is getting downvoted. It's a perfectly reasonable question given what the parent comment said.

If your business cannot handle possible parental leave then it is not really profitable in the first place. This 'cost' is not different from any other (taxes, transport costs, rent, etc.).

The pay-as-you-go reductions give you more flexibility about when you make optimisations to your code though and help you handle uncertainty around this.

For example, if I have a new workload that won't fit on existing hardware with AWS, I can either: a) reserve the new instances, or b) not reserve on the assumption I will be able to optimise in the 'near' future.

In practice this is hard to know but AWS forces you to come to a correct decision up front, whereas Google Cloud allows you to not have to answer this up front without being punished later for making the 'wrong' choice.

Ah thanks. I'll take a look. I'm definitely most interested in the JS side (although I agree static site generators can be great).

To give some more context, I work for a big media company on the main website team. We have a lot of developers contributing to the codebase. So AMP(ish) seems attractive as one way of introducing discipline/preventing an explosion of client-side ad-hoc behaviour over time.

I remember reading the original article and discussing with colleagues at work. The premise just seems wrong to me:

* CSS-in JS isn't gatekeeping; there are huge benefits to breaking the global CSS model, which these articles seem to ignore, which is surprising to say the least

* the market reality is that most companies are better off with 'full-stack' people - the need adaptable people, who can get things done, albeit not always with the perfect approach

To ignore these and instead point to gender bias seems bizarre.

The NHS is gigantic - it is the umbrella term for publicly funded (universal) healthcare in the UK. There are lots of agencies within this that will have a web presence who can now (if they like) use this UI library for accessible and usable components.

Going further back Mill is probably the better starting point for the negative view of freedom:

https://en.wikipedia.org/wiki/John_Stuart_Mill.

So it's really not a US/Europe thing at all - both very much value negative liberty, although it is probably fair to say that Europe also values positive liberty a bit more. It's more about the role of corporations. The US seems to view corporations as almost equivalent to people, whereas in Europe more often they are viewed as quite separate. And Europe has a broader definition of harm around monopolies than the US does currently at least, especially around the importance of data protection (but again both in respect to negative liberty).

Yeah just ignore. His initial tweet ('precious white dudes...') is borderline racist even. Reading the github issue, you handled things well even if others didn't, regardless of the merits of renaming the library or not.

While I agree it probably never ends well, this is hardly off topic in this case.

Wow they have 45k projects? I imagine a lot are dead/outdated modules, but even so it's a fair amount.

I think you could be clearer in what precisely you are disagreeing with in the article. From my reading, the author is trying to describe the state of the US today and struggling to find parallels in history because, while the US is productive and has lots of resources, the people have a surprisingly poor quality of life.

We've had a fair bit of work around cyber-security - being a bit sharper on checking project dependencies, encrypting all data (including things like access logs) restricting firewalls even further, better audit trails, and also things like automatic password rotation.

I'd say this is all good stuff, and in most cases we were already doing it, but it is difficult to retrofit in one go.

Going forward it will be a lot easier though as new projects will simply be designed better from a security-perspective.

That's great news! Thanks for the reply.

As a heavy Scala user I'm excited by this. But really I don't think it will improve Scala adoption because the blockers there are all around developer experience (tooling is terrible - sbt, and feedback cycles are very slow).

Personally, for a lot of my current use cases (APIs) I'm veering towards Go more and more as I find it a lot more productive.

Yes, Rich Hickey (amongst others I am sure) has talked about precisely this model of backwards compatibility - i.e. if you break the contract you have to rename the thing.

This feels far better than the current model used in most languages. If you've ever had struggles creating an uberjar you know this pain.

Agree, prefer non AMP versions please.