Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
thelarkinn
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
6 ms
·
1.
▲
by
thelarkinn
6y ago
Hey Sean from webpack, this was really just about our third party plugin ecosystem needing to catch up to v5. If you are feeling IRL Stress, then please don't update yet. Sometimes you have to break things to create progress and ship m
2.
▲
Microsoft Edge Team Reddit AMA
(reddit.com)
1 points
by
thelarkinn
7y ago
|
1 comments
3.
▲
by
thelarkinn
7y ago
I never said there wasn't a cost. Every technical decision comes with trade-offs. But costs don't hold us back from developing amazing new features [for developers and consumers] for the future. <3
4.
▲
by
thelarkinn
7y ago
On the Edge team and I can tell you, in no way, does supporting IE, hold back our development capabilities. If anything, it enables more companies to adopt Edge without concern of breaking support for their legacy applications. We see that
5.
▲
by
thelarkinn
7y ago
/* Looks to other top HN Posts */ A majority of consumers do not expect Google to track their activities (niemanlab.org) Ironic?
6.
▲
by
thelarkinn
8y ago
Technically JavaScript is only ~7% slower then C++ to execute. But snipe away at that stats with real data.
7.
▲
by
thelarkinn
8y ago
No harm done <3
8.
▲
by
thelarkinn
8y ago
This is right, its more nativeish apis and webview for UI and friends. Worthy Snipe and misinformation on my part in thread.
9.
▲
by
thelarkinn
8y ago
Sorry I offended. These aren't rumors just things we've been blogging about, etc. and I'll own being unclear. The Electron and UWP bits are things we've tossed around internally. I don't want to give more details be
10.
▲
by
thelarkinn
8y ago
> JS would be unusable for projects of this scope Blanket statements don't really make great arguments. That aside, in my experience (webpack for one), projects at scale with JavaScript, are harder to maintain without some type safe
11.
▲
by
thelarkinn
8y ago
Those are product decisions someone like me can't actually confirm right? I just know that the purpose or the goal is having a single code base, single toolchain, many targets. I just know I've heard of all of those targets being
12.
▲
by
thelarkinn
8y ago
Could be! Didn't we just announce (and got meme'd to death by InfoSec world) that Excel is going to be able to _run_ JavaScript. BTW this isn't breaking news, we have been talking about our love, bets, and use of ReactNative
13.
▲
by
thelarkinn
8y ago
Yup, and that really was what the tweet was trying to portrait. JavaScript, and many scripting (or maybe author meant interpreted languages), are incredible languages to start with. I have a love for the "sharper" langs like Rust,
14.
▲
by
thelarkinn
8y ago
If by "They" you mean me, someone who doesn't work on the project itself, but is advising over a toolchain for it. Also, I do not know what the Linux plans are (but hey maybe a great time to voice that special love you have f
15.
▲
by
thelarkinn
8y ago
I don't think I mentioned Skype for Business anywhere did I? :-)
16.
▲
by
thelarkinn
8y ago
Hi there, original tweeter here. Just to clarify: no one said when this work would land, simply that we are working on it! Sorry to disappoint XD, but I guess blame the OP.
17.
▲
by
thelarkinn
8y ago
For sure! That's our preferred way of using JavaScript. TypeScript in the end is just a static type linter that compiles to JS. Heck you can even "use" TypeScript's typechecker without even using a .ts file. We do this f
18.
▲
by
thelarkinn
9y ago
Exactly. Alt-Title: Why we use webpack.
19.
▲
by
thelarkinn
9y ago
Hi there!!! Sean from the webpack team! For a development environment this is great. However if there's any takeaway from this post, it is the reminder that all of the resolve, parse, eval, execute, graph traversal, and linking has to
20.
▲
by
thelarkinn
9y ago
I honestly don't feel you did! In fact this gist we actually had from a contributor kind enough to document his experience so we could identify exactly what hot path migration would look like for users. So we were really happy to have
21.
▲
by
thelarkinn
9y ago
Sure, but since your experience is not configuring anything, how are you going to know what it's actually doing to your code. And what are the tradeoffs? Seems like many don't have this answer because they don't have good arc
22.
▲
by
thelarkinn
9y ago
PS: I submitted this response also in Reddit for those who come across it twice. It's not meant to be disingenuous (as I'll likely respond to individual comments also), just meant to show what our statement is. Hi all, We apprecia
23.
▲
by
thelarkinn
9y ago
And we haven't implemented persistent caching and multithreading yet ;) just getting faster and faster.
24.
▲
Webpack 4: released today
(medium.com)
15 points
by
thelarkinn
9y ago
|
1 comments
25.
▲
by
thelarkinn
9y ago
The number one cause of slowness for a page is the time it takes to parse, eval, and execute JavaScript (even if it is dead code). So this static async bundle creation helps ensure that you are only shipping what you need on initial downloa
26.
▲
by
thelarkinn
9y ago
Ah yes so we removed the page but is all still under our WIKI on webpack/webpack. Mind submitting an issue and we could surface a little note on our README?
27.
▲
by
thelarkinn
9y ago
We strive to be as backwards compatible as possible. But we also hold ourselves accountable to keeping pace with the ecosystem. Most breaking changes are to accommodate the number one ask of our users: faster, smaller builds. We asked what
28.
▲
by
thelarkinn
9y ago
This isn't our intention, rather to recognize those who helped make webpack what it is today. I wouldn't have been able to fit everyone on one page of image otherwise :)
29.
▲
by
thelarkinn
9y ago
We just find that it reaches people better!!! Sometimes in the JavaScipt ecosystem it takes a lot for a 6 year old tool to stay on top of people's focus and attn. But it got yours right?
30.
▲
Webpack 4 beta released – try it today
(medium.com)
19 points
by
thelarkinn
9y ago
|
0 comments
More ›