441–450 of 502 posts
Earlier quoted context omitted.
It's when you build a business on a technology and then have to re-invest to rebuild the product, that's when it becomes an issue. Think of all the start ups that built running businesses on Angular 1.
as far as i know, angular 1 still works just fine... :) (as it happens 1.7 was released recently.)
Earlier quoted context omitted.
But it's not even independent green developers, it's everyone. Chai, mocha, jasmine, jest, should, expect, lab...omg do we really need another unit testing library? Sure they are all slightly different but there is no reason they all couldn't be condensed down to one or two libraries. Shall we list all the reactive UI frameworks? Or routing frameworks? Everyone is at fault here.
Chai is not a testing framework, it's an assertion library compatible with all the other main testing frameworks you mentioned. Yes, we do need experimentation and innovation in testing frameworks. Jest was a real innovation to the space and is particularly awesome for React testing with it's snapshots feature. This kind of argument never gets made with anything else. "Why can't we all just stick to the Model T. It's…
The reason this is a problem is because web tech is constantly changing, to the point that so many of these projects end up in the scrap heap far faster than other tech. It causes problems with long term service due to compatibility issues with ever changing dependencies.
It's nice to see some recognition of the idea that interpreters are safe by default (excluding infinite loops/OOM), and we can avoid many security concerns (access to files/network/etc.) by simply not including that functionality in the interpreter (unless opted in via a startup parameter, as described). I'm also a fan of using env vars for configuration and locating dependencies, as mentioned in the talk. Much simpl…
Earlier quoted context omitted.
> 1. Get a native Dart VM into Chrome and eventually other browsers. > 2. Get a significant number of client-side web developers that were using JavaScript to move to Dart. > The Dart leads prioritized (1) over (2). ... That didn't work out, unfortunately. That's what I remember hearing when Dart was just getting off the ground. So what happened? Script tags can specify text/javascript or text/dart. Did the the Chrom…
They released an experimental version of Chrome called Dartium that included the Dart VM.
Thanks Miley Cyrus!
Earlier quoted context omitted.
I like the energy around the javascript everywhere movement. So what if they reinvent the wheel, sometimes you find a better wheel and break the rules along the way. There is something exciting about developers using a language in ways it was never designed. Then having the language change to support the changing ecosystem...
So true, at the end of the day people are working like this because it's the way they feel the most passionate about. You can't really blame them considering how disinterested people can get working on that last 10% of even their own projects.
Earlier quoted context omitted.
It's an anthropological effect, not a technological one. A new generation of craftsmen faces a choice between submitting to the rules of the old guard and making up their own rules. Reduced complexity is often a rallying cry, but I think the root of the phenomenon is in trying to find one's own social and professional standing in the situation where all the prominent positions are already taken and what little is lef…
This reminds me of when I first read about fractals: a collection of phenomena I've been staring at all my life, but never really saw until someone pointed out how to see them. Currently popular music mostly sounds like noise to me, but that's not the point. What are the current generation of musicians supposed to do, be silent and spend their lives listening to the great bands of my youth? It's impossible to match P…
It's interest to see which parts of our civilization came which side of the divide. Market economy, for example is a great way for a young enterprising person to find their own footing away from the old (hence startups). Academia OTOH went totally the other way (hence grad school).
Earlier quoted context omitted.
npm is the worst software I use daily. * The maintainers have pushed several breaking updates by mistake (I'm a teapot recently). * There have been a few cascading failures due to the ecosystem (leftpad). * node-gyp (alluded to in the talk) break cryptically on install in different operating system/package combinations. It also obscures the actual package contents. * The lack of package signatures and things like nam…
Here's one thing Node and npm are great at and NuGet fails at completely: local development of two packages. With npm, I can use "npm link" to redirect a package reference to a local folder. With NuGet, the best you an do is edit the .csproj and change the nuget reference to a project reference (if you can find the original source code). This makes simple step-through debugging across package boundaries a chore every…
Earlier quoted context omitted.
I was not happy having to do TypeScript on a project thinking in your point about slowing you down which initially is completely true if you are forced to tslint it to hell. However, I've done a 180 in that TypeScript is very nice when you relax the tslinter and you sprinkle it on as you go which gives you that extra feeling of being auto-guarded when its just more practical but without getting in your way which is e…
Could you summarize what settings you used for the TS compiler and tslint for that "sprinkle it on but keep it out of the way" approach?
I set "transpileOnly" for tsc loader and set different more strict command like "npm typecheck" to "tsc --no-emit ./src/index.ts". I usually add only strict null checks and it's enough for me. I also disable most of tslint as it's way too heavy in standard CRA app for example.
This way you get hints from tsc in editor so you see what is wrong but at the same time you can run your app without fixing everything upfront.
Earlier quoted context omitted.
I'm on the Dart team (but I don't speak for the entire team here). Dart had two initial goals: 1. Get a native Dart VM into Chrome and eventually other browsers. 2. Get a significant number of client-side web developers that were using JavaScript to move to Dart. It's probably not obvious, but these goals are in tension with each other. In order to motivate adding a giant new VM to a browser, you need to make the lan…
> The Dart leads prioritized (1) over (2). The idea was that the VM would be so great users would flock to it giving us (2). This is actually why I, as a developer, decided not to use Dart: because it would give Chrome a competitive advantage and more control over the other browsers. Chrome has enough advantages as it is, and I like having competition in the browser market.
In many ways, this is similar the path that asm.js/WASM took. First it's polyfilled to JS in all browsers. Then some browsers get faster native support while still polyfilling the others. Then eventually all browsers support it natively.
The initial asm.js design was a little different because as a subset of JS, the polyfill was a no-op. But the binary form of WASM, I think, required a JS polyfill on browsers that didn't support it natively.
Dart could have taken a similar path, but we didn't get the level of user excitement required to motivate browsers to follow along.
Earlier quoted context omitted.
There's very few things JS classes can do that ES6 modules/named exports along with closures returning plain objects can't do better, in term of code organization, isolation, and extensibility. For the 6 times a year where I need an actual class (it does happen!), I can write the prototype code. The main issue with adding classes is that they're very, very complex if you want to make them useful. The initial version…
> There's very few things JS classes can do that ES6 modules/named exports along with closures returning plain objects can't do better That's a really good point. I was about to disagree with you but then I created a thought experiment. Thought Experiment: I wonder what the JS landscape would look like if ES6 Modules were introduced as part of ES5 about 8 years ago? I could definitely see how that would make classes…
The rise of Java and the OOP revolution isn't that far behind us (2 decades seems like a lot in the tech world, but its still within a single generation of humans).