391–400 of 456 posts
Earlier quoted context omitted.
Yes, like we had with WebSQL until it was deprecated. Basically a SQLite db per site.
I think the idea is that IndexedDB acts as a more lower level store that you can build higher level abstractions over, for example PouchDB.
Earlier quoted context omitted.
> Experienced programmers know that JS is an awful language BS blanket statement. Some - many, maybe - programmers that in all likelihood multiply your experience and talent by orders of magnitude believe it's a great language. Not everyone working with JS is doing so with a gun to their heads.
I don't know any polyglot programmers who would consider javascript better than at least one of the other languages they use, and would ditch js for those if they had the option. TypesScript, maybe.
I’d choose JS over Java for back-end glue code, and JS+HTML+CSS over Java+Swing for front-end UI and app distribution, any day of the week.
Earlier quoted context omitted.
> You certainly wouldn’t use a language like JS, I disagree with this. You might not want to use JS but a language “like” JS such as TS or Lua would definitely be on the table. Or just JS without the biggest warts. > you certainly would want to provide visual design tools as far as possible, I feel that the promise of visual design tools fell quite short. Issues with version control and general traceability of change…
> You might not want to use JS but a language “like” JS such as TS or Lua would definitely be on the table. Or just JS without the biggest warts. When you remove the warts from JS there's not much left. And I'd be pretty skeptical of someone starting a new project in Lua today. I think the mainstream choice for a "blank slate" language today would look something like Swift or Kotlin; Typescript can gets close, but it…
Well, there is the upcoming play.date SDK for example and a lot of jam games.
The biggest reason why these languages are used is because they are fun.
Don’t get me wrong, I really like swift and SwiftUI. But there is something quite liberating when throwing away the type system completely and just hacking at the code. This brings in new people who get motivated by seeing a thing shaping up rather than staring at weird error codes.
> but thrift/gRPC are a lot nicer to work with than REST APIs.
I agree with this, protobufs are nicer to push around rather than JSON. Ultimately though one can do pretty arbitrary stuff with either.
For your last point I think that is a separate issue. The ubiquity of web is certainly reason for its popularity. But I was mostly talking about why people hacked around issues with upstream rather than trying to find more sound solutions.
Earlier quoted context omitted.
> I'm definitely not a mindless CTO. ;) Based on this comment you do kind of sound like one. Could you elaborate on what you think 'Domain Driven Design' is, and what you think 'boundaries' are in the context of development? It would help dispel the impression I get that you're a clueless CTO who knows enough to be dangerous. (apologies for being a bit rude perhaps; consider it a comment slightly in bad faith, but ve…
DDD is a set of principles where you have conversations with your business partners, model scenarios, determine a ubiquitous language, and build software that mirrors those models and conversations. Determining your bound-contexts, their relationship to other bound-contexts, and determining where sub-domains belong. Though this can be confusing since you could have an "order" domain in several bound-contexts with dif…
I do still feel that the link between that and your suggestions in the initial comment are still tenuous and vague 'management-speak', but still, thanks for the response :). Obviously I don't know the exact details or how you're running things, so the best I can do is poke at it (in good faith).
Earlier quoted context omitted.
Wow. Stack Exchange is a curious case study. I share the general HN sentiment over microservices complexity but just to play devil's advocate... I suspect that server cost in this case is asymptotic. If the (monetary) cost of SE's architecture is F(n) and your typical K8s cluster is G(n), where n is number of users or requests per second, F(n) very large. In essence, the devil's advocate point I'm making is that mayb…
Microservices will add latency because network calls are much slower than in-process calls. Microservices, as an architectural choice, are most properly chosen to manage complexity - product and organizational - almost by brute force, since you really have to work to violate abstraction boundaries when you only have some kind of RPC to work with. To the degree that they can improve performance, it's by removing confo…
A salary of 3 infra engineers per year $300k, cost to company probably $450k.
For $450k a year, you can get about 500 servers, each one with 128 GB RAM and 32 vCPUs.
Has anyone done this type of a ROI?
Earlier quoted context omitted.
I don't know any polyglot programmers who would consider javascript better than at least one of the other languages they use, and would ditch js for those if they had the option. TypesScript, maybe.
I’m a polyglot programmer and I find quite a lot to like about JS. The concurrency model, for one, and also its multi-paradigm nature. I’d choose JS over Java for back-end glue code, and JS+HTML+CSS over Java+Swing for front-end UI and app distribution, any day of the week.
Earlier quoted context omitted.
The question asking for clarification is itself vague. Examples of which part? Look at JS that's written for serious applications today, identify the stuff that you'd label as "idiomatic", and then look at code that was written 10 years ago for serious applications, and see if it matches what your conception of "idiomatic JS" is. Good references for the way JS was written for high-quality applications without the neg…
Hi, I'm also a new JS coder, but I'd like to avoid becoming one of "those people" you're talking about. I've been struggling with exactly what you mention - how to find out the "correct" way to apply patterns/do relatively complex things, but all I get on search results are Medium articles written by bootcamp grads. Can you recommend any sources of truth/books that can guide down the right path? Of course I'll be goi…
Basically, go for anything that teaches you non-js-specific approaches as well as as a solid understanding of the fundamentals.
I've always felt this problem from the first time I touched Angular. It was just so much more complex and fragile without actually a lot of benefit unless you wanted to make a really interactive async application like Google Docs or Facebook Chat. When SPA's became the norm and even static web pages needed to be build with React, developing became more and more inefficient. I saw whole teams struggling to build simpl…
> developing became more and more inefficient Anecdotally I find the opposite to be true. I've been writing frontend code for over a decade, but I've never moved faster and wrote less buggy code than now. Is that because I've become a better developer? Sure, a little bit. But by and large, I don't believe that ultimately is the reason. I think it's the maturity in the technology. My growth as a programmer is hardly l…
I used Turbolinks for the first time on a new Rails app about 2 years ago and was floored by the impact - it felt like a SPA in terms of no page loads and overall speed. I'm convinced that this is the solution for the majority of use-cases, combined with selective usage of either React components or something like Stimulus where you need more sophisticated UI components.
Is there an equivalent of Turbolinks for something like Django? Or even for MVC PHP apps?
Earlier quoted context omitted.
> You might not want to use JS but a language “like” JS such as TS or Lua would definitely be on the table. Or just JS without the biggest warts. When you remove the warts from JS there's not much left. And I'd be pretty skeptical of someone starting a new project in Lua today. I think the mainstream choice for a "blank slate" language today would look something like Swift or Kotlin; Typescript can gets close, but it…
> When you remove the warts from JS there's not much left Modern JavaScript is pretty sweet to write compared to pre 2015. It sure is fun to join in on the "JavaScript bad" circle jerk though.
But realistically you still want a JS build pipeline of some kind, for minification, compiling SASS to CSS, and other things. And of course if you're doing "modern" frontend work, you're not using vanilla JS like I was - you're using a complicated framework like Angular, React etc, and having to deal with the likes of webpack.
And then there's the anaemic standard library - honestly, barely any better than it was 10 years ago. And then, largely as a result, you've got NPM-dependency hell, with hundreds or thousands of deps for just about anything. Want to trim a string - there's a package for that.
And then there are other languages and ecosystems - when you compare JavaScript to those... well, then you really have to admit it's a turd.
Hating on JavaScript isn't a bandwagon - there are many genuine reasons why people dislike it and the ecosystem. IMO, comparing it to a "circle jerk" is like that meme where some character is surrounded by fire saying "this is fine".