Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mechanical Watch

ciechanow.ski

Post reply on HN
Print view View original

311–320 of 425 posts

Re: Mechanical Watch

#311

Post by Handytinge »

phailhaus wrote: post #186
panzerboiler wrote: post #40

Earlier quoted context omitted.

He does it "the right way™". Use the platform. Don't use any framework or generic library. Go straight to the point and code what you need, when you need it. Don't minify or bundle anything, and let the people who are learning and courious a straightforward way to connect the dots, without forcing them into a github repository with 90% of the code unrelated to the thing and existing just to glue 1000 pieces written b…

The tradeoff is that there is basically nobody else that has the expertise or time to do the same thing at a similar level of polish. We're not going to see more Ciechanowski-level posts unless new libraries and frameworks make it more accessible.

We definitely won't if people are taught that frameworks are the only option and never allowed to just write a full program on their own.

Re: Mechanical Watch

#312

Post by jseban »

throwaway2214 wrote: post #190
10000truths wrote: post #47

Earlier quoted context omitted.

I mostly agree with you, but I don’t mind minification when appropriate, as it can serve a functional purpose with tangible end-user-friendly benefits (less downloaded over the network = faster response times). But if you want to be friendly to the tinkerers, you could always host both the *.js and *.min.js versions, and have the webpage just pull the latter - anyone who wants the unminified source can remove the “mi…

minified js is not greatly smaller than gzipped js, I think the whole minification thing is a swing and a miss and now we have to deal with source maps and shit, and build pipelines and etc $ ls -la -rw-r--r-- 1 jack 197609 330905 May 4 22:56 watch.js -rw-r--r-- 1 jack 197609 152172 May 4 22:55 watch.min.js $ gzip watch.js $ gzip watch.min.js $ ls -la -rw-r--r-- 1 jack 197609 43690 May 4 22:56 watch.js.gz -rw-r--r--…

> and now we have to deal with source maps and shit

Yeah minification is only really for obfuscation. The small and unpredictable difference is absolutely not worth the ridiculous complex "solution" of source maps. Just the fact that your debugger really doesn't work right, is a deal breaker in and itself, not to mention all the time spent configuring and fighting with webpack.

I don't think any form of "compilation" i.e. bundling, transpiling, minification etc is needed at all. Javascript can already dynamically load (additional) code files when needed, I don't understand why you need to bundle it in the first place.

I don't buy that the http request overheads are so big that it motivates all this complexity, and in the average case a user don't use every single page of the application anyway, so by bundling everything you are always serving "too much", compared to just dynamically loading additional code.

Re: Mechanical Watch

#313

Post by smetj »

Will we still be able to find and consult this mesmerizing piece of documentation art in let's say .... 100 years? Pretty sure mechanical watches will still exist then.

Re: Mechanical Watch

#314

Post by noitpmeder »

the_cat_kittles wrote: post #254
valtism wrote: post #218

Earlier quoted context omitted.

I strongly disagree that this is "the right way". I think that the platform provides low level primitives that are _designed_ to have abstractions built upon them. Doing it like this has the potential to be the most performant, but it does so in the same way as writing your programs directly in assembly is potentially performant. I also don't think that the source code is particularly readable for me, and contains lo…

it depends if you are doing something to get paid, or to last, or to be really good. only in the first case do i ever consider a heap of abstractions

This is so backwards.

Re: Mechanical Watch

#315

Post by ojr »

Cthulhu_ wrote: post #306
ThePhysicist wrote: post #31

I was curious how he did those visualizations so I looked at the source code. Turns out he codes everything by hand in WebGL [1]. Absolutely impressive stuff. Source code is non-minified so you can have a look and understand everything as well. [1]: https://ciechanow.ski/js/watch.js

I like that; it's a lot of work but a lot of people seem to prefer to have to make libraries work together than to just do the work, and it's timeless since it doesn't depend on any future frameworks; any issues that might come up in the future with regards to browser incompatibility can be fixed relatively easily. Would antifragile be an applicable word to use here?

I have a WebGL project thats been broken for a few years due to a browser deprecated api, it is not a relatively easy fix

Re: Mechanical Watch

#316

Post by mFixman »

throwaway821909 wrote: post #120
causi wrote: post #21

Earlier quoted context omitted.

True multimedia is a lost art. We had it back in the 90s when software came on discs and it was a high-density, polished product that combined text, audio, video, and interactive elements on the same page. The internet taking over turned everything back into text, and then as bandwidth grew the only thing we thought to use it on was higher and higher bitrate video. When I was a kid I thought the future was going to b…

Last time I used Amazon Prime Video, around 2017, it would show info that Amazon deemed relevant for that bit of the show (apparently it's called X-Ray). Back then at least, it wasn't on the same level as what you described but still something. The danger was it made me want to pause all the time in case I missed something interesting, but by putting the user in control of what they get info on, you could avoid that.

The Kindle has a similar feature for some of its native book: if you long-click in the name of a character it would give you a short description and a timeline of where it appeared in prior parts of the books (with future parts hidden to prevent spoilers).

Re: Mechanical Watch

#317

Post by kaba0 »

the_cat_kittles wrote: post #254
valtism wrote: post #218

Earlier quoted context omitted.

I strongly disagree that this is "the right way". I think that the platform provides low level primitives that are _designed_ to have abstractions built upon them. Doing it like this has the potential to be the most performant, but it does so in the same way as writing your programs directly in assembly is potentially performant. I also don't think that the source code is particularly readable for me, and contains lo…

it depends if you are doing something to get paid, or to last, or to be really good. only in the first case do i ever consider a heap of abstractions

Abstraction is the only thing that makes any of our advancements possible. Not even the simplest of math theses could be proves without a “framework” of relevant lemmas, nor could you write even a single hello world without the layers upon layers of abstractions written carefully over the decades. Sure, there is also bad abstraction, but the problem is the bad part, not the concept itself.

Without abstractions you wouldn’t be able to read a text stored on a remote computer with accompanying style information displayed the same on both of our devices and with embedded 3D graphics doing the same thing on vastly differing devices be it a top of the line GPU or a simple low-end phone. Is it not abstraction?

Re: Mechanical Watch

#318

Post by kaba0 »

Cthulhu_ wrote: post #309
selcuka wrote: post #244

Earlier quoted context omitted.

True, but it also removes the comments and the whitespace, leading to slightly better performance and memory usage. There are also less bytes to gzip on the server side.

Slightly, but is it enough to warrant the extra steps? I don't think the difference is significant enough in this case. That said, I do think there should be an alternative to minification+gzipping, like e.g. a compiled version of JS that is more optimized than a browser's own JIT compiler can do. Mind you, that might up being a larger package than the JS source code.

Webassembly is* pretty much that

* hopefully will be

Re: Mechanical Watch

#319

Post by matheusmoreira »

grishka wrote: post #265
ThePhysicist wrote: post #31

I was curious how he did those visualizations so I looked at the source code. Turns out he codes everything by hand in WebGL [1]. Absolutely impressive stuff. Source code is non-minified so you can have a look and understand everything as well. [1]: https://ciechanow.ski/js/watch.js

Are you sure about the by hand part? There's a lot of repetition, it feels like at least some of it must be generated.

I wish he'd write a post about how he developed these visualizations. How does one even learn how to make something this amazing?

Re: Mechanical Watch

#320

Post by tomaskafka »

naikrovek wrote: post #173

Normally I would crap (pretty hard) on web tech, because normally, it's only ever used to make websites harder to follow in the name of design, or to create new ways for ads to be served to me. This site, and the most recent blog entries on this site, are excellent examples of why web technologies are not all bad. People seeking new ways to make money make everything bad, eventually, and thankfully there are bastions…

What is wrong about trying to find ways to produce a nice stuff and keep being to able to pay the rent and raise kids?

I run a small and nice visual weather app for Apple Watch and iPhone (https://weathergraph.app). Some people in reviews object to price, but if I wasn't able to charge a subscription (because weather data costs money continuously), there would be no app. And if I wasn't able to make (about 50 % there right now) a living, I would work for a corporation like I did before, and I wouldn't be able to dedicate enough time to make it great ¯\_(ツ)_/¯.

Post reply on HN