The Guts of Android - <AUTHOR> http://lwn.net/Articles/439620/ <comment><USER2> The Intent system is indeed awesome, but Google seems to have forgotton something. How does a developer know all the possible intents? If i define a new intent, it isn't registered anywhere globally for other developers to use, so every app developer has to communicate it through some unofficial channel.

There is some community work in that direction, i'd hope google would endorse it more:

<http://www.openintents.org/en/intentstable>

<comment><USER3> Intents are an open messaging system. The fact that they use java package names shows you they're meant to be user-extensible and infinite.

Compare this to the bit-packing retardedness that is the Win32 message crackers[1]. Commercial software companies used it just like intents, and whenever you licensed "components" you got a print-out of all the magic constants the developers thought were available.

Dammit, Java IS a better language than either C and C++ for application development.

\--

[1] Remember Me? MagicProc(HWND hwnd,WORD msg,WPARAM wParam, LPARAM lParam);

<comment><USER4> So intents are just like D-Bus, except with fewer features, docs and used only on Android?

By the way, from your statements you can at most conclude that the Java libraries are better than Win32.

<comment><USER3> What do you mean fewer features? Intents are how everything is done. Android is basically four major components: Activities, Intents, ContentProviders and Services (Views are not really a components, just a nice hack which uses reflection & XML to make the GUI DOM-like .. but without having the foresight to allow for DOM-like _manipulation_ \-- why can't I configure layouts & content with xpath-like selectors?)

Android has the cleanest architecture of any visual environment out there, bar none. D-Bus is far lower level than Intents (you can't send a D-Bus message to fire up the default "camera" application to take a picture, then fire up another message to the default "email" application sending the picture you just took as an attachment.)

Java libraries ARE better than anything on win32. They're equally verbose, but java has better tooling, and it wears toddler gloves, so it doesn't scratch itself and doesn't gouge your eyes out while you feed it.

<comment><USER5> Can you explain what you mean about 'cleanest architecture'? Having written a content provider, service, activity, and of course used intents in the past few weeks (and for months before), I would not really identify Android as "clean".

<comment><USER3> Compare it to any major API and tell me what you think. there are just about 4-5 platforms of the same calibre, and none come close. They thought it out well, and whatever other platform got you spoiled, I can tell you it's not win32, .net, mac, symbian, java2 anything, XNA, or anything on X. Enjoy the sub-single digit market share! ;-)

</comment></comment></comment></comment></comment></comment><comment><USER6> Nice summary.

Two things that I find to be very nice/cool when developing for Android:

\- As mentioned in the article, applications are bundles of components and have no specific entry point. To be more accurate, they have multiple entry points.

\- The Intent system. Not only does it provide an easy and robust way to integrate deeply with other apps, it also provides a simple IPC mechanism. Intents can be used to publish and subscribe to events between applications and are incredibly simple to use.

<comment><USER7> _\- As mentioned in the article, applications are bundles of components and have no specific entry point. To be more accurate, they have multiple entry points._

Like Web sites.

 _The Intent system. Not only does it provide an easy and robust way to integrate deeply with other apps, it also provides a simple IPC mechanism. Intents can be used to publish and subscribe to events between applications and are incredibly simple to use._

Almost RESTy. Except for the callback part. But using an app model that is similar to Web service and Web app development is quite handy.

<comment><USER8> You know, when I first learned android development, its similarity to web development stuck me. Xml layouts (html), content resources (rest), the back button etc etc. I don't think its a coincidence or my web dev background

</comment></comment></comment><comment><USER9> Here's a nice diagram of the framework / structure of the Android / Linux libraries [1]. It's interesting to compare it to Nokia's Maemo [2] and Intel's MeeGo [3], which are much closer to a desktop Linux. I haven't been able to find a diagram for WebOS but expect it to be fairly similar.

[1] [http://www.forum.nokia.com/piazza/wiki/images/e/ef/Android-a...](http://www.forum.nokia.com/piazza/wiki/images/e/ef/Android- architecture-485b.jpg) (strange the 1st Google hit for this was on Nokia)

[2] <http://wiki.maemo.org/images/9/90/MaemoArchitecture.png>

[3] [http://www.99bits.com/wp-content/uploads/2010/09/meego- archi...](http://www.99bits.com/wp-content/uploads/2010/09/meego- architecture.jpg)

</comment><comment><USER10> Video of the talk can be found here: <http://free- electrons.com/blog/abs-2011-videos/>

</comment><comment><USER11> "It was a political decision not to use Busybox, rather than a technical one, he said."

Anybody know what that means? Licensing conflict, perhaps?

<comment><USER12> It's probably because busybox is gpl

</comment></comment><comment><USER13> Very nice description of the Android architecture. I understand that all the applications have to be written in Java. But how did Firefox port its browser to Android? I doubt they have ported it from C++ to Java. At least from the article I do not understand what is necessary to write Android applications in non-Java languages. Can anybody please explain or give a link?

<comment><USER5> What you're looking for is the NDK. Here:

<http://developer.android.com/sdk/ndk/index.html>

<comment><USER14> To expand on this - apps on Android do not need to be written in Java.

To use the full Android SDK, you can write in any language that produces Java .class files (eg, Java, Scala, etc).

However, if you are happy to work at a lower level you can use the NDK (= Native Developer Kit, linked in the parent), which lets you work in C with a fairly traditional Linux/C API. It also gives you access to OpenGL etc etc.

<comment><USER15> _[The NDK] also gives you access to OpenGL etc etc._

The Java interfaces also give you this. Unfortunately, since OpenGL is mostly about making a ton of little function calls that build up a list of GL commands, it can be kinda slow since each call has to cross the JNI boundary. But it's performant enough for most things, and you can find your bottlenecks and drop down to native code where necessary.

</comment></comment></comment></comment><comment><USER16> nice tour / deef dive. similar content in this 2008 google i/o talk, "anatomy and physiology of an android" <http://www.youtube.com/watch?v=G-36noTCaiA>

</comment><comment><USER17> Some important things are missing:

For example in Android development we do not use java serialization but instead use a parcelable interface to store stuff and write to an android OS bundle to pass data between activities, etc as it is somewhat faster than java serialization.</comment>


The Frontline Interview: William Binney - <AUTHOR> http://www.pbs.org/wgbh/pages/frontline/government-elections-politics/united-states-of-secrets/the-frontline-interview-william-binney/

<comment><USER2> Oh this is a very good interview. I have read and seen others but this is one of the most detailed ones on Binney.

Binney came before Snowden and he raised all these issues and it didn't really sway the public. That was pretty frustrating. He didn't bring a database with him so naturally some assumed he was making stuff up because he was bitter his system was being used and deployed under a different compartment and he was sort of not part of it.

One interesting thing here is that it really undermines the often repeated PR phrase "Oh why didn't Snowden just come to us (higher ups) and tell us. There was no need to go public like that". The implication is "we could have listened and fixed the problem".

Here is Binney years before trying to do that. Yes he didn't go directly to his bosses, I think it was clear they wouldn't have listened. He went to Intelligence Commetee (Congress). Went to DOJ. Nothing happened. Some anemic 90% redacted reports. "Vows to take to be more careful in the future", nonsense like that.

All it ended with was FBI raids and persecution for those involved.

The crucial part comes at the end and that is Snowden studied their case and he made sure to take documents out with him.

<comment><USER3> The story about Thomas Drake was fascinating and very sad too. He went from being a senior executive at the NSA to being accused of violating the espionage act (all charges which were later dropped) and having his entire life ruined. Spent his life savings fighting the legal battle, his wife left him, and he could only get work at an Apple store.

<comment><USER4> I didn't realize Snowden had studied what happened to Drake and Bennie et al, and determined that if he took a massive amount of documents it would actually protect him and not just be his word against theirs. And of course, he could have only done that as an admin. That was some pretty impressive high stakes chess there. Wow.

</comment></comment></comment><comment><USER3> The whole Frontline 'United States of Secrets' episode is very good and worth a watch. Part two is this week, I think on Tuesday.

<comment><USER5> Knowing the full history of the "program" and everyhing the lead to The Big Leak really puts it in perspective and grounds the entire NSA domestic spying apparatus in reality. At least for me. I'm fairly young and was in school 03 to 07 but I wish I paid more attention back then.

</comment></comment><comment><USER6> The whole discussion about deleting code vs commenting it out seems to imply that the NSA wasn't using any sort of version control system in 2001. Does anyone else find that odd?

<comment><USER7> It's just to explain to the layperson how easy it is, on the software side, to intentionally remove the feature he considered necessary for NSA to keep working consistent with the laws and the constitution. It also explains the difference between his approach and the approach the organization took.

It also doesn't mean what you imply. They've certainly used revision control systems at that time and his example doesn't contradict that.

<comment><USER6> From the interview:

"So either that, or they took that entire block of code and deleted it. So there's one of two ways of getting rid of it. If they commented it out, it would only take a couple minutes to reinstate it. It wouldn't be difficult to do. If they deleted it, they'd have to reconstruct all that code.

I suggested that to Diane Roark. That was the way that they probably did it, and they could reinstate it very simply, if they only commented it out."

If you are using version control, it would only take a couple of minutes even if you had deleted everything. You wouldn't have to rewrite all that stuff, just go back in the history.

I realize that this is off-topic to the main thrust of the discussion, but I found it a curious.

<comment><USER8> It seems to me, like the parent said, he's just simplifying a normal process. Sure, if his code was a few lines, and someone deleted a few you could use version control to get them back. On the other hand, if his code was a full fledged program, and the deletions were institutional such that further work was carried on after the deletions making the entire datflow go through different assumptions and processes, it would be significantly more difficult to reinstate. Preserving the dataflow might be done if you're just commenting out a line to test things. But if a whole chunk is straight up deleted, the flow of data will likely shift to be incompatible with the old way of doing things within a couple of revisions of the code such that no version control would help.

<comment><USER6> Ah yeah thanks for that explanation. It makes sense. I guess I wasn't thinking about the effect of the commented out code on the mind of the programmer trying to make the current version of the code "backward compatible" with the old feature.

</comment></comment></comment></comment></comment><comment><USER9> William said if one wanted to comment a line of the source code, they'd place a C at the beginning of the line.

Is this a familiar language behavior to anyone, or are they using in-house languages/interpreters. I wouldn't put it past them, but I found that comment interesting and would like to know more if anyone has any data.

<comment><USER10> It's Fortran. Placing a "C" in the first column means Comment [1][2].

This burned one of my teammates once because he used Emacs to edit a Fortran file and in trying to type C-x C-c he accidentally added a "c" to the front of a line of code. This broke our application in production.

[1] [http://www.stanford.edu/class/me200c/tutorial_77/03_basics.h...](http://www.stanford.edu/class/me200c/tutorial_77/03_basics.html) [2] [http://docs.oracle.com/cd/E19957-01/805-4939/z40007332024/in...](http://docs.oracle.com/cd/E19957-01/805-4939/z40007332024/index.html)

<comment><USER9> Thanks! I've never worked with Fortran.

</comment></comment></comment><comment><USER11> They really need to update their site for mobile. I couldn't read anything</comment>


Could Wordpress Be the Natural Successor to Twitter, Friendfeed and Facebook? - <AUTHOR> http://siliconangle.com/ver2/2009/08/11/could-wordpress-be-the-natural-successor-to-twitter-friendfeed-and-facebook/ <comment><USER2> This is extreme echo-chamber bias. Facebook has gone mainstream and their changes so far have only increased engagement and traffic.

The fact that some early adopters and their little cliques are jumping around from service to service every 6 months in search of the new hotness does not say a whole lot about the future of any of these services.

In my opinion it's going to be hard for any startup to cross the chasm and displace Facebook in the next 10 years. I know that's a bold statement, but look at the people who are using it now. You're not going to suck average people in with some incrementally better service with no critical mass.

Why has Twitter's growth suddenly dropped off compared to Facebook's? Because regular people joined, followed celebrities, found out they had nothing interesting to say, asked "that's it?" and left. Facebook provides value to almost any real person right now. While a federated stream is nice in theory, it doesn't really mean anything to anyone except extroverted geeks and San Francisco hipsters.

</comment><comment><USER3> WordPress and WordPress MU are complete PHP4 hackjobs. It is a developer's nightmare to fine-tune any website that uses these platforms. Since BuddyPress just turned stable and barely has any plugins, it is not worth its salt as a Social Platform, unlike Vanilla 2, which uses the MVC design pattern and ships with just as much if not more out-of-the-box features. The OP's suggestion makes 0 sense.

The main reason, I find, that people use WP is because it is free and does the relatively simple task to managing and displaying a blog decently out of the box.

If WordPress was completely rewritten (like Vanilla 2 was in lieu of Vanilla 1), then I'd change my argument. But you'd lose the thousands of plugins it currently supports, though perhaps only 100 of out them are actually production-ready.

</comment><comment><USER4> "Seesmic, Tweetdeck and the top three or four iPhone Twitter clients could form a consortium and suddenly mirror everything that takes place on Twitter to a third party or federated platform – in essence deprecating Twitter and Facebook in one fell swoop."

Unless these clients start duplicating the entire functionality of Facebook, that is completely untrue. Facebook is much more than a Twitter-esque messaging platform.

</comment><comment><USER5> No, based on my experience with WordPress.

<comment><USER6> Did you read the post?

There's a lot more to it - particularly when you look at the roadmap for where Wordpress and Buddypress are headed.

<comment><USER5> Yes, I did read the post. Haven't had to try to use it (because of a colleague's specification of WordPress for one site for one of my organizations), I'm not convinced that WordPress is built on the right base of fundamental design choices to meet those needs. In other words, I think WordPress is a kluge. A different webmaster of another website I am closely familiar with uses completely different tools to do what WordPress supposedly does, and finds his site much easier to run as an administrator and much easier for contributing users as co-authors.

<comment><USER6> I think that largely depends on how you have it set up, and how much of a coder you are. It's definitely geared to be a nice compromise for folks that are jacks of all trades and masters of none. It appeals to the coder and the writer in me, since I split my time between the two.</comment></comment></comment></comment>


Show HN: YouTube Podcast Generator – Create a pod from YT channel and playlist ids - <AUTHOR> https://rundexter.com/app/youtube-podcast-generator <comment><AUTHOR> Hi everyone - here's a Dexter app we made that can be configured to feature the YouTube playlists and channels you choose. Initially we built one that was pre-configured with all the late shows, but saw how it could really be used for any content that features interviews, monologs, MOS, etc. If you remix the app, there are private variables in the settings where you can provide your own artwork and file paths. Looking forward to hearing your feedback!</comment>


Show HN: Neural TTS App with Voices of Elon Musk, Jack Dorsey, Tim Cook & 25more - <AUTHOR> https://apps.apple.com/us/app/id1489706295 <comment><AUTHOR> Parodist is a text-to-speech mobile app that uses AI technology to sound personalized messages in voices of famous politicians, celebs, and tech leaders.

Our early users love the opportunity to congratulate their friends with the personalized audio of Taylor Swift or prank their family members with the video of Barack Obama endorsing them for the POTUS position. Now, we have 45 voices, and we're constantly adding new ones.

It's fun, safe, and easy to use. Just enter any name into the template and get the video or audio voiced.

</comment><comment><AUTHOR> the app is also available for android</comment>


Elements of Clojure - <AUTHOR> http://elementsofclojure.com/ <comment><USER2> The learning experience for Clojure is superb. Coming from C/Python languages, it really put things in perspective to learn to think more in terms of composing primitives than wrangling syntax.

OT: Does anyone know of other projects in the spirit of Pixie? To be more specific I'm looking for existing work on a clojure->rust project, would contribute or start one if none exist. Sorry for the offtopic!

<comment><USER3> I'm working on Clojure-looking lisp with a borrow checker and static analysis in the vein of Rust. It's especially tailored for games since most lisps don't account for that use case (GC, dynamic types). Here's a link, let me know if you have any questions: [https://github.com/eriksvedang/Carp](https://github.com/eriksvedang/Carp)

<comment><USER2> This looks nice and feels right in terms of syntax. I'm not sure I see the value of exposing the borrow checker to the user however; couldn't it be used implicitly while handling the s-expr to c compilation? In any case I'd love to talk more about it, can I reach out via the github project?

<comment><USER3> Absolutely! We have a gitter chat that would be a perfect place for that kind of discussion [https://gitter.im/eriksvedang/Carp](https://gitter.im/eriksvedang/Carp)

</comment></comment></comment></comment><comment><USER4> "Natural names allow every reader, novice or expert, to reason by analogy. Reasoning by analogy is a powerful tool, especially when our software models and interacts with the real world. Synthetic names defy analogies, and prevent novices from understanding even the basic intent behind your code. Use them sparingly."

I'm not sure that I completely agree, but this is a great conversation to be having!

<comment><USER5> Hi, I'm the author. I would be very happy to discuss this point (or any other) in more depth on the mailing list: [https://groups.google.com/forum/#!forum/elements-of- clojure](https://groups.google.com/forum/#!forum/elements-of-clojure).

</comment></comment><comment><USER6> I really wish I had the time to learn Clojure. Between Rich Hickey's general wisdom and skill, my (small but fun) exposure to Lisps, and David Nolen's ClojureScript, it looks like a great environment to get into.

<comment><USER7> "really wish I had the time to learn Clojure."

I would say don't bother. The language is a nice lisp (nice simplifications, great immutable ADTs, edn, pretty good async libs, etc), but the ecosystem tooling is still miserable IMHO - this is coming from someone who has worked around 6-12 months on a couple of clojure projects, so I'm not a die hard expert but I've worked enough with it to build with/have used clojurescript,clojure,java bindings,leiningen/boot,clojars etc.

I really wanted to like clojure. The idea that I could run my code on the JVM and in the browser is alluring. And, I would add, if you like using mvn or ant or gradle or in general the java way of doing things, you will probably think leiningen is good enough.

But I have zero tolerence for annoying/unnecessary headaches, and so I can't take it, and don't program any of my projects in it.

What do I consider good? Well an analogous project is Mix for Erlang/Elixir, and I think its an excellent example of what I wish leiningen were. Anyone can learn Mix in about 10 minutes, you can easily use it for erlang & elixir projects, I have had zero problems and stuff just works. This is not the case with leiningen, which makes building and deployments unnecessarily complicated in clojure.

I don't see clojure getting mainstream until someone starts concentrating more on the user experience in the tooling, though this may be more of a java/jvm originated problem, still it affects your whole experience while using clojure.

<comment><USER8> As much as I love Clojure and even more so ClojureScript, I would have to agree with you on this. To add to what you said, another big pain point for me is starting new projects. Although I wouldn't say don't spend any time learning the language, especially if you are new to functional languages, you can learn a lot from Clojure.

<comment><USER7> "Although I wouldn't say don't spend any time learning the language"

Yes, I can see your point. And there are some really good innovations clojure has made I think - specifically the immutable data types are really beyond compare, anyone wishing to learn more about immutable data structs should definately read their source in clojure its clear and understandable.

Still, if anyone wants to learn what lisp is all about. I'd just recommend common lisp (clisp or sbcl) for getting the special forms, repl, and beauty of macros bits. It also means you don't have to know anything about java to get the key concepts of a lisp, which is less overhead overall.

Regardless of common lisp or clojure, I'd always recommend anyone listen to Rich Hickey's talks on clojure, they are very good, especially his talks about values, composition, and simplicity. ([http://www.infoq.com/author/Rich- Hickey](http://www.infoq.com/author/Rich-Hickey))

</comment></comment></comment></comment><comment><USER9> Exciting! Zach Tellman's work had always impressed me. Looking forward to seeing what he brings this time around.

</comment><comment><USER10> I wrote a similar kind of style guide for Python.

[https://github.com/amontalenti/elements-of-python- style](https://github.com/amontalenti/elements-of-python-style)

"Elements of Python Style": goes beyond PEP8 to discuss what makes Python code feel great.

Looking forward to reading Elements of Clojure. Python is my primary language but Clojure is my hobby language.

</comment><comment><USER11> Surely a good book. But it would be nice to see the complete TOC... Leanpub says it's 25% complete?!

<comment><USER5> The four chapters shown are the complete list, only the first chapter has been completed. I have tried to make this as clear as possible, let me know if you see a way to make it more so.

</comment></comment><comment><USER12> Can't wait, I'm sure I'll learn a lot from this.

</comment><comment><USER13> I fear this reads not very precise, mostly arbitrary and random.

Examples:

> If a value is an arbitrary Clojure expression, it should be called form. If > a macro takes many expressions, the variadic parameters should be called > body.

A value is an expression? what is a Clojure 'expression'? Why should it be called a 'form'? If it is arbitrary, why not call it 'expression'? What does it mean to 'take an expression'? What is 'many'? A macro, the variadic parameterS, which should be called 'body'? The macro has more than one variadic parameter and they all should be called 'body'?

> These defaults derive from the idioms of the Clojure ecosystem and common > sense.

'Common sense'? What?

> If a value can be anything, we should call it x. This is fairly rare, as > usually the only things we can do with an object involve =, hash, and str.

What is a value? what is 'anything'? The next sentence talks about 'objects'. Is 'anything' always an object? Why don't we talk about 'any object', instead of 'anything'? What does the number of possible actions have to do how 'rare' a name is?

> Let's consider a student datatype, which is represented as a map whose keys > and values are well defined, either using documentation or a formal schema. > Anything called student should have at least these entries, and sometimes > only these entries.

A data type is 'represented' by a map? What does that even mean? 'Anything'? What is 'anything' in this context and what means 'entry' in this context?

This goes on and on.

> At runtime, our scope is any data we can see from within our thread.

What is this 'we' at runtime and what does it mean for 'we' to 'see' data?

> Conversely, we can think of sending an HTTP request as sailing across an > ocean; any transfer of data, pushed or pulled, requires effort.

What?

> If a function crosses scope boundaries, there should be a verb in the name. > If it pulls data, it should describe the datatype it returns.

What does it mean for a function to cross scope boundaries? What is a scope boundary?

> There are two kinds of macros: those which we understand syntactically, and > those which we understand semantically.

There are two kinds of macros, those who begin with WITH and those who do not. What does it mean to 'understand syntactically'/'semantically'?

> To use with-open effectively, we must macroexpand it in our heads whenever > it appears in the code.

what?

> syntactic macros

What is that exactly?

> Transforming arbitrary code is difficult and sometimes impossible

What?

Macros: ... > Readers must not only understand the semantics of the transformation, but also its exceptions and failure modes.

Personally I, as a reader, am more interested in the semantics of the generated code.

> macroexpanded syntax

How can I macroexpand syntax?

> Naming is a problem which cannot be solved, but also cannot be ignored.

What kind of problem is it and why can't it be solved. But then I can not ignore it? It can't be solved, but I can not ignore it?

Worse: much of the advice assumes a static text program where the only option I have is to read the text. Not a Lisp system with data<->code.

Probably also a good idea to write a glossary, where the basic terms (form, value, expression, scope, scope boundary, data, parameter, argument, variadic argument, syntactic macro, failure mode, ...) are defined/described.

<comment><USER14> > To use with-open effectively, we must macroexpand it in our heads whenever > it appears in the code.

I'd like to add that if you find yourself needing to mentally expand a macro every time you use/read it, you have a poor abstraction. Consider going back to the drawing board and coming up with a good abstraction instead.

<comment><USER13> Right.

For a macro which only implements a 'simple' syntactic transformation, I would expect that I need to understand the semantics anyway. Additionally I need to understand the syntax it implements.

What I don't want at all, is to macroexpand macro forms. If I need to macroexpand those, then I would do this for debugging, when there is something wrong during expansion or with the generated code. I would also do the expansion not in my head, but using a function called 'macroexpand'.

For example as a reader, I don't want to macroexpand the following form in my head:

        (with-open-file (foo "bar.text")
          (read foo))

What I really want is to understand the syntax of WITH-OPEN-FILE and semantics of such a form. To what it transforms itself is the least important thing I (as a code reader) want to know when dealing with macro forms.

* it's a WITH- type macro which sets up a scope.

* a WITH- type macro usually expects a variable, something which helps creating an object that is bound to the variable and a bunch of options

       (foo-var "the-file-name.text" :direction :input)

* it then expects a body, a sequence of forms, where the variable FOO-VAR is bound to a file

That's the syntax.

The semantics is that at runtime it opens a file as a stream and makes sure that on all forms of exit, the stream gets closed.

To what form this actually expands (even if it is a simple transformation) is uninteresting and may be different from implementation to implementation.

</comment></comment></comment><comment><USER15> Really brillant !</comment>


Hack Lodge: A Week-Long Buildathon for Student Hackers! - <AUTHOR> https://hacklodge.org <comment><AUTHOR> Hi all!

Applications for the summer 2019 Hack Lodge are open! Hack Lodge is a week- long hackathon organized each summer/winter in NYC, Seattle, and the Bay Area. It's everything you love about hackathons, but with more sleep and more time to really get to know your cohort (~20 people), who you become really close with! Food and lodging covered, though there are no prizes, just your own satisfaction from having built something. Engineers, designers, and everyone interested in building are encouraged to apply:

[https://hacklodge.org](https://hacklodge.org)</comment>


Free PHP URL shortener script that can shorten over 4 billion URLs - <AUTHOR> http://briancray.com/2009/08/26/free-php-url-shortener-script/

<comment><USER2> Hi, looks like it was a fun project. While you save yourself from checking the DB for a duplicate hash with your hex id strategy, a side effect of this technique is that every URL created with your service is effectively public. For instance, I could start at <http://briancray.com/tests/shorturl/0> and work my way up through every URL ever shortened by incrementing the id in hex. Whether this is a vulnerability or undocumented feature is up to you to decide :)

I bring it up because I ran across the same issue with my own site, droplink.me. It was a more serious problem for me, because user uploaded files are supposed to be private. I went with randomly generated URLs.

<comment><AUTHOR> That is a side effect of this strategy, but I figured I'd add my own to the bunch to give people more choice.

</comment></comment><comment><USER3> the urls could be much shorter if you used a-z and A-Z and not just hex (a-f). But it saves some lines of code.</comment>


Internet Archive, decentralized - <AUTHOR> https://dweb.archive.org/ <comment> ezequiel-garzon I strongly believe IA or any serious project working on permanent persistence must provide an option (opt-in if you will) to make the published material irremovable, à la arXiv [1].

[1] Red parts of [https://arxiv.org/help/license](https://arxiv.org/help/license)

<comment><USER2> And that is your right. However most people would like to remove slander with a court order.

<comment> ezequiel-garzon Pretty sure arXiv would remove slander with a court order as well. It's an unrelated issue.

<comment> crooked-v If material can be removed, it's not irremovable.

<comment><USER3> I think it's fair to assume "not-${VERB}able" means "as not-${VERB}able as legally possible".

<comment><USER4> This gets tricky with things like blockchains.

</comment></comment></comment></comment></comment></comment><comment><USER5> I didn't see any articles relating to how it was decentralized. Is internet archive going for something similar to a blockchain setup, because that would actually be one of the few cases it would make sense

I am not familiar with this new dweb subdomain, what is unique about it?

Archive has actually lost some of the archives I stored on it, which is weird, because I ran multitude of backups on it a few years back when the site got taken offline

<comment><AUTHOR> I wanted to submit an article about this but couldn't find anything either.

My understanding is that this loads content from various protocols (listed at the top of the page), many of which support replicating data in a decentralized way. As far as I know, there's no blockchain involved in anything here yet.

If you browse to the Community Video section and choose a video, you can see peer information as though downloading through WebTorrent. If I disable WebTorrent and look at a video, I don't see the peer information and it seems to fall back to HTTP. Pretty cool! It looks like almost everything is only seeded by the Internet Archive right now, but hopefully they want to encourage more people to participate.

<comment><USER5> Hm that's interesting, I imagine the internet archive has lots of seedboxes/CDNs/datacenters distributed globally. I have no idea how much information the internet archive is currently backing up though, but its growing at an increasing rate.

I would love to see a write up of how their infrastructure works though

<comment><USER6> My understanding is all of their digital content is stored and served from their location in SF, although it would be awesome if they started geographically distributing their storage nodes.

[http://archive.org/web/petabox.php](http://archive.org/web/petabox.php)

<comment><USER7> There's been at least a partial copy in Alexandria and Amsterdam for a long time, and they opened a full replica in Canada last year. At least I think the Canada one is done, can't find a blog post saying it was finished. [https://blog.archive.org/2016/12/03/faqs-about-the- internet-...](https://blog.archive.org/2016/12/03/faqs-about-the-internet- archive-canada/)

<comment><USER6> Was not aware; this is excellent news!

</comment></comment></comment></comment></comment></comment><comment><USER8> What is it? My browser (firefox) sees nothing* even after enabling javascript.

*Except the sentence "The decentralized web is everywhere, but we have to find it." and a Name form that does nothing.

<comment><USER9> the problem is not firefox... it's probably addons or your internet connection that blocks content

<comment><USER10> It is also nothing for me in a Firefox fork with almost all add-ons disabled. Error console says there's a bunch of "class is a reserved identifier" and syntax errors of missing semicolons (before main() can even run).

My guess it's trying to use some bleeding edge emcascript stuff which borks the parsing in non-bleeding edge browsers.

<comment><USER9> oh... I forgot, I'm using the beta version of Firefox, that might be why.

<comment><USER11> If you run into problems, I'd love to know specific details - this is an experiment to see what was achievable with Dweb tools like IPFS, WebTorrent, Gun on browsers, with a big site like the Archive. It certainly pushes the edge of browsers - and does use the latest ES6 features without much attempt to support older browsers (unlike the production site at archive.org). We only currently test in the latest Chrome & Firefox, though it seems to work (mostly) on current Safari on iPad and iPhone and I heard its working on Android though I haven't seen it yet.

If you can get on, there is a feedback button, if you can't feel free to go straight to the form at [https://docs.google.com/forms/d/e/1FAIpQLSe7pXiSLrmeLoKvlDi2...](https://docs.google.com/forms/d/e/1FAIpQLSe7pXiSLrmeLoKvlDi2wODcL3ro7D6LegPksb86jr5bCJa7Ig/viewform) or open an issue on [https://github.com/internetarchive/dweb- archive/issues](https://github.com/internetarchive/dweb-archive/issues) .

<comment><USER10> > ... and does use the latest ES6 features without much attempt to support > older browsers (unlike the production site at archive.org)

Except the wayback machine which recently changed it's interface to be entirely JS dependent and fails on older browsers. And the old interface is no longer accessible.

</comment></comment></comment></comment></comment></comment><comment><USER12> When cloudflare screwed up and published everyones secrets there was a coordinated effort involving, amongst others, archive.org to try and scrub the internet of those secrets. Are there any mechanism available to allow similar efforts with this dweb version?

<comment><USER13> There should not be a mechanism for that. China mastered such mechanisms. We should rather optimize for not having that kind of points of failure.

<comment><USER14> I think of the two evils, the possobility of censorship or mistakes being eternal, I think I prefer the former.

For the same reason I find it comforting that an old fashioned bank transfer can be corrected if I transfer money and make a mistake writing the account number. Mutable history is a powerful feature.

<comment><USER13> This feature is an illusion though. Mallory still can save anything that appears online for a second and so can you.

<comment><USER14> Sure. But if I e.g. accidentally uploaded something sensitive to GitHub (that can't simply be changed to a new secret), I'd certainly delete it in a hurry, rather than shrug and say "oh well It's on the someone has already copied it so I'll leave it".

<comment><USER15> But in that case, are you saying you _wouldn't_ immediately change the credential you committed? Sure, the possibility of an adversary forking your repo after that commit but before your revision is small, but still exists.

Once a secret is exposed to the internet, it should be considered public and rotated. In this case mutability/immutability is moot though likely there are applications for other, non-credential secrets that are not so easily rotated (like your home address or something).

<comment><USER14> Yes a changeable credential you just change, but say the medical records of all staff your entire company or similar.

</comment></comment></comment></comment></comment></comment></comment><comment><USER16> Aww I was going to add almost exactly the same thing to [https://github.com/pirate/bookmark- archiver](https://github.com/pirate/bookmark-archiver) but IA beat me to the punch! I still hope to add decentralized storage and lookup mechanisms to BA eventually, but considering one BA's archive outputs is the Internet Archive, it's less pressing now.

</comment><comment><USER17> This is really cool! A bit sluggish, but I love the idea!

If you think back to, say, the library of Alexandria, to how much knowledge has been lost over the ages, it is so important to preserve as much as we can for future generations.

And building a decentralized foundation for this archive is a big step going forward, congratulations!

<comment><USER18> I recently went to the Internet Archive in SF, got a tour of their operations etc. Absolutely amazing place, very forward thinking, and they indeed are very serious about prevent something like the destruction of the Library of Alexandria from happening again.

<comment><USER17> There is a (great, IMHO) science fiction novel, "The Mote In God's Eye" by Larry Niven and Jerry Pournelle that describes humanity's first contact with another intelligent species.

Due to their biology, this alien species experiences periods of massive population growth that eventually lead to all-out war and collapse of civilization. Over uncounted thousands, maybe millions of years, these aliens have accepted this vicious cycle as kismet, and deal with it by building "warehouses" filled their most advanced technology to jump start civilization after the next, inevitable, collapse.

I hope humanity will never have to deal with such a collapse, but I given our collective tendency towards self-destructive behavior, maybe we should build such an archive as if it was meant for future cavemen to jump-start them into a new Anthropocene. Even if that collapse never happens (I am keeping my fingers crossed!), the resulting tome of knowledge would be a suitable monument to all the incredible things that humanity has accomplished, as well as an insurance policy in case we manage to mess up on a monumental scale.

EDIT: A more positive perspective would be The Library from David Brin's uplift saga, a humongous collection of knowledge acquired by many, _many_ species over millions, if not billions of years.

EDIT: typo

</comment></comment></comment><comment><USER19> How does this work?

</comment><comment><USER20> Look, feel and content-wise this feels a lot like the internet of the 90s...

<comment><USER21> Unfortunately, it's not 90's enough, as it still requires fucking javascript.

<comment><USER22> This is one of the (admittedly few) cases where javascript is actually required.

<comment><USER11> Of course it is, Javascript is what allows us to run significant code on the browsers without extensions or plugins or downloaded apps/peers, and its amazing how far its come as a language in the last few years. WebAssembly would probably work as well, but was far less developed when we started this project last year.

</comment></comment></comment></comment><comment><USER23> Unsupported mediatype: data

:(

<comment><USER11> Yes - we don't yet support some of the more unusual types on the Archive (including "data" and "software")

</comment></comment><comment><USER24> on firefox it hangs past http.

<comment><USER11> Its still an experiment to see what was possible with a big site, in today's browsers using some of the emerging tools (IPFS, WebTorrent, GUN). We only test on absolutely current releases of Chrome & Firefox. If you run into problems on the site, there is a feedback button, otherwise you can report directly on [https://docs.google.com/forms/d/e/1FAIpQLSe7pXiSLrmeLoKvlDi2...](https://docs.google.com/forms/d/e/1FAIpQLSe7pXiSLrmeLoKvlDi2wODcL3ro7D6LegPksb86jr5bCJa7Ig/viewform) or open an issue on [https://github.com/internetarchive/dweb- archive/issues](https://github.com/internetarchive/dweb-archive/issues)

</comment></comment><comment><USER25> very nice

</comment><comment><USER26> GUN author here ([https://github.com/amark/gun](https://github.com/amark/gun)) happy to answer any questions.

IA did this integration in 1 week, Mitra is awesome.

Also, decentralized Reddit ([https://notabug.io](https://notabug.io)) was built in 1 week on us, and pushed 0.5TB P2P traffic on 1st day.

Note: I may not be awake for several hours, and might not be able to reply until Monday.

<comment><USER27> GUN looks great! I love the quick-start tutorial too: [https://gun.eco/think.html](https://gun.eco/think.html)

How suitable is GUN for live multiplayer (non turn-based) web games? (Similar to [https://airma.sh/.](https://airma.sh/.))

I see one game example at [https://github.com/amark/gun/wiki/Awesome- GUN](https://github.com/amark/gun/wiki/Awesome-GUN), although it's turn-based.

<comment><USER26> Thank you!!!

I need to fix the organization of the documentation (and update the docs, oye!). I'm impressed you found Awesome-GUN.

[https://github.com/amark/gun/blob/master/examples/game/space...](https://github.com/amark/gun/blob/master/examples/game/space.html) is probably what you were searching for.

What would be better is if I made a blog/tutorial for ^ link. Not a priority for me, sadly, but maybe it is for somebody out there, that they could help?

Thanks again!</comment></comment></comment>


This guy will run against the Congressman who introduced SOPA. Support him - <AUTHOR> http://www.reddit.com/r/politics/comments/nehr6/as_requested_i_am_willing_to_run_against_lamar/

<comment><USER2> Good. That fucktard who introduced the SOPA should be promptly eliminated (from congress that is)...</comment>


Do Not Follow JavaScript Trends - <AUTHOR> https://pragmaticpineapple.com/do-not-follow-javascript-trends/ <comment> andrewl-hn I vividly remember 2016. I was doing backend programming at the time, but no one I knew were using Angular.js at that time for new codebases.

React emerged in 2013, by 2014 the hype was at full swing, and by 2015 React "won" the framework battle.

It's been 5+ years since then, and React JavaScript world was remarkably stable. Fashion changes were largely superficial: React.createClass vs ES classes, Heavy use of Decorators vs not using them, and now Hooks. These were mostly cosmetic choices, and if your team picked the wrong side they could migrate over relatively painlessly or straight up ignore the issues for years.

On the other side of spectrum we have Ember that maintained backward compatibility and ease of upgrades since ~2013, Angular 2+ is doing the same for many years, too.

The whole "JavaScript fatigue" meme has to go.

<comment><USER3> You make it sound like we're all using React and that's all there is to it. That's not quite true, and it's just one of the choices you have to make. So you've decided on React, but what about state management, transpilation, do you use GraphQL? What am I doing for styles, should I write them in Javascript too now? Oh no! Webpack isn't for me! Can I use modules yet? Ah bugger, we need SSR, suppose I should have managed state the "Right Way (v28.6)", doh!

<comment><USER4> I even got fatigued reading your list of choices and you even missed critical choice such as flavor of SSR.

</comment></comment></comment><comment><USER5> A good way to not be completely overwhelmed by all the new tooling and frameworks is to have a strong grasp of the fundamentals, here are three foundational resources:

"You don't know JS": [https://github.com/getify/You-Dont-Know- JS](https://github.com/getify/You-Dont-Know-JS)

"How browsers work": [https://www.html5rocks.com/en/tutorials/internals/howbrowser...](https://www.html5rocks.com/en/tutorials/internals/howbrowserswork/)

"High performance browser networking": [https://hpbn.co/](https://hpbn.co/)

<comment><USER6> Agreed. I think a lot of folks suffer from not understanding how web 1.0 worked and really groking REST/HATEOAS (which has since been hijacked for JSON APIs, which is complete nonsense.)

Sometimes I jokingly call htmx "web 1.1 tech", but increasingly I wonder if I'm really joking.

<comment><USER7> In 1996-1998 as a teen I "made some websites" for local businesses. The one I made for my parents even had a search function (in PHP) in a CSV with their products (which were like 100). The CSV was generated by taking whatever Lotus Approach (their desktop DB) generated and transforming it with some custom Haskell code (I was a teen, what did I know). They clicked an icon to pull the data and another to run a FTP batch file.

Fast forward, I understand _nothing_ of the website being developed in React for my startup. The othe technical cofounder does grok it, but I could _not_ lend a hand and can barely even supervise the outside help we brought. I like to think of myself as well-versed in a generalist manner. I can hack a custom sparse matrix (with a very particular structure I was able to prove an iteration for) inversion algorithm, but I understand _nothing_ about painting the background the correct shade of blue!

<comment><USER6> I have something for you:

[https://htmx.org](https://htmx.org)

<comment><USER7> Yow. I have an application growing out of control in Streamlit ([https://streamlit.io](https://streamlit.io)), which is a rshiny-type interactive dashboard gizmo. I'm now able to consider rewriting it with a proper front-end.

It's like a whole world I had been sealed off from has reopened.

<comment><USER8> (Note: I'm Head of Developer Relations at Streamlit)

Out of curiosity, which features are you looking for in a "proper" front-end? Flexibility?

<comment><USER7> Streamlit is _magic_ and I don't want this to come off as a dismissal, but it can be unpredictably unreliable. I keep having this issue if I run > 0.58:

[https://github.com/streamlit/streamlit/issues/1440](https://github.com/streamlit/streamlit/issues/1440)

It's over a month old now, with multiple people reporting the same bug and iterating on the problem with no apparent narrowing towards a reason for why this happens, let alone a solution.

<comment><USER8> Thanks for clarifying. Since HN isn't the right place for a detailed discussion, I would invite you to comment on that issue and try to help us work through it.

As one of our engineers mentions in the linked issue, this bug is hard to trigger (as is the nature of many bugs), and she is working on a solution[1]. This issue has also been reported here[2], with the solution of adding time.sleep(1) inside the loop usually resolving that problem.

[1] [https://github.com/streamlit/streamlit/pull/1494](https://github.com/streamlit/streamlit/pull/1494) [2] [https://discuss.streamlit.io/t/displaying-images-from- opencv...](https://discuss.streamlit.io/t/displaying-images-from-opencv/3014)

<comment><USER7> Yeah. What I should have added here, but didn't want to sound brash and rude, is that Streamlit should focus on having a reliable working product before spreading out as an org with a Dev Relations department.

I know this is a complicated problem domain ( _because it 's the web_, Mathematica did this well with complex graphs in the mid-90s), but as it stands now my project has an input on which the graphic depends and a default value; the image breaks before the input control is touched. And it's not a slider, it's a dropdown that makes the app query a db first... I mean, I think I can do this in plain Ajax if I get my story right about sending images. But it's a hobby project meant to explore mathematical ideas...

If you can't do sliders reliably, they should be moved to a beta branch. Streamlit overpromises and underdelivers. But it's a great project, I don't want to be too negative about it.

<comment><USER8> I see you've both commented here and on GitHub, so I'll make my last comment here and then we can address the specifics on your ticket (I didn't realize I referred you to your own GitHub issue).

As I mentioned, there is a pull request already created for this issue; our head of engineering/founder says its being held up by a lack of tests before merging. This problem isn't a slider issue, but a race condition in our session state manager.

Regardless, one month is a pretty trivial amount of time as far as open-source projects go, as well as in the history of Streamlit (project became public Oct 2019). Like all projects, we try and address things in the order of severity, and as far as this issue goes, it's a pretty isolated one, not an indication that the library is unreliable or somehow reflects that our engineers can't design at an early-90s level of engineering.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> I'm a little lost on the examples.

There are reasons to use fetch and hooks, and the article seems to relegate them to being unnecessary 'trends' without doing what it suggests, actually evaluating what value they might have...

In React you can use hooks with a class heavy application and still be just fine / get the benefits of hooks in a given component(s).

If you want to use fetch, that also is hardly an ordeal to do / should not be a big cognitive load for anyone.

I get it, resume driven development bad, we get it, we hear it in opinion pieces all the time. Also you should think about it before rewriting an entire application. Yup, that makes sense.

But here we have examples of small changes that are pretty light weight... and no effort is made to do exactly what it suggests, evaluate those choices.

<comment><USER10> But do we get it? If we get it, why is frontend churn so prevalent?

I don't think we get it.

<comment><USER11> Is front end churn really so prevalent? I hear this opinion all the time, but React is 7 years old. I've been using it for around 5 years, I think. Redux is 5 years old. How old does the most popular web framework need to be before we consider it to be low churn?

[Edit: Also, anecdote: before JS, I was mostly a C# developer, and the churn there was at least as bad, maybe worse in my personal experience. Over 15 years of my career, I had to learn ASP, then ASP.NET, and in the Windows app world, we went from WinForms to XAML, then .NET Core came out, and things shifted again... See Rails' history for more examples of churn. It's not like every other platform is a paragon of stability. Clojure is a bulwark of stability compared to just about anything else, but it's hardly fair to hold the front-end community up against that gold standard...]

<comment><USER12> JS has always been relevant as an ecosystem because it incorporates new ideas. I liked jQuery more than what came before it, and I like React more than jQuery. They make the task of translating an idea into a work app much easier for me, and other programmers I work with also benefit from more readable code.

I wouldn't re-write an existing app to use fetch or hooks, but now that I've taken the time to learn, I'm happy I did. The vast majority of the mental work was done by other people, and I get to reap the benefits. The alternative to this is stagnation, and relegation to legacy systems... I guess the author wishes they could work in COBOL?

</comment></comment></comment></comment><comment><USER13> I find it interesting the blog post mentioned Kent Dodds article recommending everyone rewrite fetch. I just argued adamantly against Redux docs about writing tests being switched off of Enzyme to his library because it's "more trendy".

[https://github.com/reduxjs/redux/pull/3708](https://github.com/reduxjs/redux/pull/3708)

Unfortunately, the community overruled me and the docs no longer show how to test Redux apps with enzyme. It only shows Kent's "react testing library". The library authors are complicit in this. Rather than showing the pros and cons of both, the trends are being pushed, leading people to falsely believe they must rewrite their whole code base in my experience.

The troubling part for me is often those creating these trends may be working on a very different type of app. When you're writing something complicated, and the ecosystem is dominated by patterns (also preached by Kent) that work best in simpler apps like "only write integration tests" it can be frustrating.

If Kent thought enzyme promoted anti patterns he could have technically made a docs PR or just written a thin layer on top of enzyme. Now we have yet another divisive issue. Getting him early access to new react apis and officially recommending RTL in the react docs (while he sells his training videos) make it sit worse with me. It doesn't feel like the trends are always based on the merits, it feels more like "not invented here" and "nepotism" driving some of these trends for sure.

<comment><USER14> As I said in that issue, I'm not completely against having Enzyme info in that page. However, we're not obligated to have the Redux docs show information on _every_ other tool that exists in the ecosystem, and our own recommendations may change over time.

Right now, we have an entire docs page on how to use Immutable.js with Redux [0]. That page was submitted by a user who cared about Immutable.js. They took the time and effort to write it, and the information is useful.

However, at this point we now actively recommend _against_ using Immutable.js [1], and _do_ recommend using Immer [2]. So, that docs page will be removed in the near future, because it now goes against our recommendations.

As I said in that thread, I personally would not recommend Enzyme at this point. Doesn't mean it's useless, or that people shouldn't use it at all, but it's not something I would use or tell people to use. Given the focus of that specific Redux testing docs page, I also don't see a _need_ to show both methods at once.

I agree that the ecosystem shouldn't just chase new shiny, but there's also a lot to be said for actually keeping docs and recommendations up to date. I understand your concern in this particular case, but it also feels like you're extrapolating rather broadly from one specific issue.

It's also the case that sometimes creating _new_ tools is the right answer. Yarn's release forced NPM to wake up from stagnation. There were dozens of Flux libraries when Redux came out. In the case of RTL, Kent created something because he saw a need, the community has seen that it's useful, and he's well within his rights to promote the tool that he created.

[0] [https://redux.js.org/recipes/using-immutablejs-with- redux](https://redux.js.org/recipes/using-immutablejs-with-redux)

[1] [https://redux.js.org/style-guide/style-guide#use-plain- javas...](https://redux.js.org/style-guide/style-guide#use-plain-javascript- objects-for-state)

[2] [https://redux.js.org/style-guide/style-guide#use-immer- for-w...](https://redux.js.org/style-guide/style-guide#use-immer-for-writing- immutable-updates)

<comment><USER13> Really all I want is instructions on wrapping the component under test in the redux provider that don't presume I'm using Kent's library. It should show how to wrap, not how to call RTLs proprietary helper function.

I'm not arguing that you're violating anyone's "rights" here, I'm arguing some of these trends feel like nepotism. The fact Redux and React are seemingly abandoning official support of Enzyme, after years of recommending it, after some of its users have written 100s of thousands of tests, is my issue, and I feel like is directly related the article about "trends" OP posted about.

<comment><USER15> You've been on this crusade for over a year. There's a thread on reddit between you and @acemarke from May 21, 2019 on this exact topic.

In that time, have you stopped to consider that perhaps the incredibly narrow "legacy maintenance" use case you've been bandying about (which isn't enough to justify dedicated documentation space in a project that isn't enzyme) and your overly insulting insinuations about the authors of popular libraries are not a winning combination?

</comment></comment></comment></comment><comment><USER16> Shiny new thing (SNT) comes along, sales people and thought leaders get excited about SNT because they can sell it, everyone piles on as SNT picks up more and more hype, SNT falls apart as soon as it hits real world use cases, sales people and thought leaders start looking for new SNT and the cycle repeats.

I can not stop the cycle. You can not stop the cycle. All we can do is notice it and let it pass and hope some SNT will eventually be useful instead of pure hype. Oh, and also, avoid joining any cults: [https://www.infoworld.com/article/3440104/10-software- develo...](https://www.infoworld.com/article/3440104/10-software-development- cults-to-join.html).

<comment><USER17> That is a great article!

Thanks!

BTW: I did write a bit about this phenomenon, here: [https://medium.com/chrismarshallny/concrete- galoshes-a5798a5...](https://medium.com/chrismarshallny/concrete- galoshes-a5798a55af2a) _(Scroll down to "It's Not An Either/Or Choice")_

</comment></comment><comment><USER5> From a developer perspective, changes in frontend web development have been pretty dramatic: CSS Grid / Flexbox, React, WASM, extensions to the web API, lots of new JS features, countless frameworks, plugins and build tools more homogeneity between browsers. There is always lots of change and excitement.

I wonder how much of that "innovation" really makes a difference to users. As a programmer, I get a bit cynical about having 50 ways to do the exact same thing. What is possible today that was very hard to do 10 years ago in web dev land?

If we think about users first, maybe we can feel a bit less guilty of not having deployed React Hooks to prod yet?

<comment><USER18> > What is possible today that was very hard to do 10 years ago in web dev > land?

Declaratively writing components and reusing behavior (e.g., hooks) across components/applications was basically impossible with the tools of 10 years ago. The benefit to the user is more stable interfaces and a faster release rate.

<comment><USER19> > benefit to the user is more stable interfaces

Doubt. Websites are _constantly_ redesigning their interfaces so that they can use the latest trendy technology.

<comment><USER18> Is that the fault of the frameworks for existing? That's like saying we'd be better off if we didn't have so many programming languages.

</comment></comment></comment></comment><comment><USER20> As a software developer I consider the most important part of my job to be evaluating new tools and techniques. This craft is in its infancy and our profession borders on complete incompetence when it comes to predictably building usable tools at a reasonable budget. Nobody can afford to miss out on productivity enhancements and that means following trends, but with a critical eye. If someone is "tired" of this process it might be time to consider another profession.

<comment><USER21> > As a software developer I consider the most important part of my job to be > evaluating new tools and techniques.

Really? I would argue it's building software.

> This craft is in its infancy

We've been building software since ... dunno ... 1950s? 1960s?

> our profession borders on complete incompetence when it comes to predictably > building usable tools at a reasonable budget

This is probably true, but I suspect chasing new tools isn't the solution. I've seen a lot of very much with it development teams fail at building stuff because they couldn't get their shiny new stuff to work predictably.

> If someone is "tired" of this process it might be time to consider another > profession.

On the front end, yes, it's probably par for the course. I suspect it's because front end development is even more removed from rigorous engineering practice than back end development.

On the back end, however, lots of stuff is still built in Java and C(++) and it all works reasonably well.

It's just not very exciting.

</comment></comment><comment><USER22> The user does care. At a previous company we started migrating from angular to vue. Vue was so fast that those parts would be completely rendered and the rest would be white. It was also snappy.

Of course, one has to be mindful about the transition. You cannot stop business, but you can take a little extra time whenever there's need to modify a section to improve quality (both code and ui). Actually that's why we chose vue, it allowed to a progressive migration out of angular.

BTW, someone had the "great" idea of not using a framework for an internal admin portal. It turned immediately into a huge ball of mud.

<comment><USER23> > BTW, someone had the "great" idea of not using a framework for an internal > admin portal. It turned immediately into a huge ball of mud.

It's never the case that you "don't use a framework" for something like that. You'll use a framework, alright. The choice is between using something well- built based on best practises as we know them, or... building it yourself. Other than in very rare circumstances, I fail to see the point of reinventing that wheel. UI frameworks (web front-end or not) are a quagmire of edge cases and other infinite time sinks.

</comment></comment><comment><USER24> On the react bandwagon for almost 5 years now and haven't regretted it a single day. Started using it because it allowed me to build d3-type data visualisations but with way more flexibility in terms of hierarchy and grouping of DOM elements in what for me felt like a very intuitive format of components and JSX. So I would say thrust your own judgement when considering which tools! Not all trends are pure hype, there might be something real behind it :)

<comment><USER25> In my opinion, React is one of the few libraries out there where the gains from using it is much larger than the effort needed to learn it. It has a relatively small API, more so now that you can get a lot done with just function components. In return, once you grok the whole "components as a function of state" concept, designing data models and designing app components becomes very simple.

I really like react, and I'm glad to see other environments adopting a React- like approach to UI development (Apple's SwiftUI and Android's Jetpack Compose, to name two)

</comment></comment><comment><USER26> Almost every time it is better to invest in learning your framework well and learning patterns to work around framework's issues rather than learning a new framework.

First, it is naive to think the new framework does not have any problems. Marketing would like you to think everything is perfect but if that ever happened, why do we have new frameworks all the time?

Second, you will pay with decreased productivity while you are learning the new framework and you are not guaranteed to be more productive than with the old framework.

Third, due to decreased initial productivity, even if you potentially get more productive with new framework, it is going to take time to realize any benefits. If you are switching the framework too frequently you are cutting yourself off from the benefits.

<comment><USER26> I forgot to mention there is actually one reason to learn new frameworks and it is to educate yourself on the tools that are available. If you do it correctly you can get 90% benefits with 10% effort.

Just don't decide to build your new production application with a framework that you don't know or did little more than hello world.

</comment></comment><comment><USER27> I feel like these problems are endemic to React and the surrounding ecosystem.

Since its introduction in late 2016 Angular 2+ has had no major changes on the scale of hooks and is unlikely to introduce them, because its target audience - large companies making large-scale applications is fairly conservative.

Vue I think had one measurably large syntax shift around v2.5(or 2.6) and will have another one with 3.0, but that's about it.

Meanwhile in React every year there's this new convention that isn't explicitly mandatory, but for some reason "cooler" than the previous one.

All this won't matter once the next gen compiler-frameworks reach maturity. My take is that hooks are React's swan song.

<comment><USER28> > Since its introduction in late 2016 Angular 2+ has had no major changes

As someone who has used Angular 2 since beta, I can tell you, it's been a bumpy ride nonetheless.

> its target audience - large companies making large-scale applications - <USER2> > fairly conservative

React was built for Facebook, which is a large company building a large-scale application.

> All this won't matter once the next gen compiler-frameworks reach maturity.

And here I am using HTML and CSS with tiny sprinkles of JS for most websites, and it's working just fine, and has been for many years.

Personally, I hope that server-side rendering will be the new ~old~ trend.

<comment><USER27> > As someone who has used Angular 2 since beta, I can tell you, it's been a > bumpy ride nonetheless.

Oh yeah. I remember the "let's just apply the good parts of AngularJS here and there" in v4-6.

"React was built for Facebook, which is a large company building a large-scale application."

 _One_ large scale application, which is not enough to create stable conventions that are badly needed in a framework that's supposed to be used in multiple such projects done by very different organisations.

 _Personally, I hope that server-side rendering will be the new ~old~ trend._

Users don't tolerate the inherent delays caused by this approach anymore.

All those hoops current frameworks are jumping through so that we can eat the cake and have it too are there because of this.

<comment><USER29> > Users don't tolerate the inherent delays caused by this approach anymore.

Well, I certainly also do not tolerate the delays in contemporary React sites either. Take Reddit for example, which used to be lightning fast when it was mostly serverside, which now is painfully slow, especially on mobile.

<comment><USER30> Yep, I agree. Was just talking to my wife about Reddit. It's so slow now, especially on mobile. The page constantly crashes on my Android phone and they always recommend the app. No thanks.

<comment><USER31> Today is the day I decided to switch to old reddit... My Mac can run garageband and vsc and 40 chrome tabs at once, but as soon as I click a front page Reddit link, that modal is like pouring sludge into my computer.

</comment></comment></comment></comment></comment></comment><comment><USER17> Not just JS. JS is an enormous ecosystem, so it shows this issue, but pretty much all tech (and other industries, as well), have the same problems.

We can have problems when folks start suddenly painting "The New Thing™" over classic designs and architectures.

In my experience, that's even worse than rewriting everything.

Also, it can become a requirement for hiring, because some manager, or their "top tech," have suddenly latched onto a technique/technology they encountered at a conference.

I remember applying at a company, and they gave me a "take-home" test.

Fair 'nuff. I like these better than the silly "draw spunky" tests that are so _en vogue_ , these days.

They said I needed to use a certain third-party library, and use MVVM, or PM. That made no sense to me. It would result in the dependency being "married" to the application.

In my response, I used dependency injection to add the third-party library they wanted me to use. I wrote the app in about three hours, and incorporated the library (which is a great library, but one I had never used before). I delivered an app that met their specs -very quickly-, and of remarkably high quality. It also featured the ability to easily "swap out" the dependency (which is a huge reason for using dependency injection).

Dependency Injection is not a new thing. I think the name may be a bit new, but it's a fairly classic pattern that is a great way to encapsulate dependencies (which is something I always do).

It Freaked. Them. Out. I have no idea why. They literally shredded my résumé, at that point.

I have my suspicions why. I think they found out something else about me during the process (my age), and that may have been a contributing factor.

<comment><USER16> I once worked with a group of people that were afraid of makefiles. I doubt it was your age. People are always afraid of things that are unfamiliar. This applies to snakes and spiders just as much as it applies to programming languages and associated technologies.

<comment><USER17> _> I doubt it was your age._

Wish I could share your confidence, but I have run face-first into this phenomenon.

 _[...removed some stuff that I don 't feel like backing up...]_

We are an unpopular bunch. It used to get me quite upset, but I've learned to make it quite clear that I am no youngster; right up front. Avoids stuff like what I mentioned.

<comment><USER16> Really? Do you have specific examples. In my experience hacker news tends to be much more friendly and sympathetic towards older programmers.

<comment><USER17> I'll withdraw the post (rather than spend a bunch of time, hunting down comments that just get me depressed), but the tide may be turning.

Now that the VC money may not be as easy to get as it once was, there may be a bit of a demand for software that _ships_ , as opposed to glossy slide decks.

Us old farts ain't so bad at that.

<comment><USER16> Indeed. Focus on fundamentals never hurts.

</comment></comment></comment></comment></comment></comment><comment><USER32> Let me make the argument against axios.

Even if you are happy, your users may not. Axios (btw still on version 0.x despite being one of the older javascript packages, means it can introduce breaking changes without any warning, think about that) adds 4.4kB (minified+gzipped) to your bundle. Do that a few times and you have hundreds of kB of additional code your users don't need to download (and execute!). If all you need to GET or POST, without any special needs, the w3c fetch function is definitely better for your users.

<comment><USER33> My argument for using axios is developer ergonomics. There are a few libraries that I use both in the frontend and the backend, for which I gladly accept the increased bundle size: axios, lodash, moment, Q. My users get the benefit in me being able to ship features faster because I don't have to constantly keep up with which feature ships in which browser version etc. I also found the fetch API horrendous to use. It's a tradeoff I'm willing to make.

<comment><USER34> Do you take on the entire of Lodash as a dependency?

If so, do you use any of the Lodash features not described here?[0]

If you use more than described, or if a specific Lodash feature is more performant, you can selectively import[1].

[0] [https://github.com/you-dont-need/You-Dont-Need-Lodash- Unders...](https://github.com/you-dont-need/You-Dont-Need-Lodash-Underscore)

[1] [https://www.npmjs.com/search?q=keywords:lodash- modularized](https://www.npmjs.com/search?q=keywords:lodash-modularized)

</comment></comment></comment><comment><USER35> No one I know has moved away from React as the base of their front-end UI for the last three years.

Maybe I'm out of touch? It doesn't seem like the churn is as much of an issue.

</comment><comment><USER36> The underlying problems are mainly psychological in my opinion. FOMO (fear of missing out) and attaching your identity to a language or tech stack.

People get so religiously tied to their technology sometimes that they cannot change without changing themselves.

It's the same case with the fractured ecosystem of Linux distros, there's tonnes of them! From the outside it looks overwhelming as all these projects are concurrently developing similar things. But the benefits are a rich and diverse ecosystem meeting a range of needs.

Imagine if everyone used one language like Java and never created new packages... and simply maintained existing libraries... that's not a world I'd like developing in...

</comment><comment><USER37> I agree totally with this - but if you want to get a new job, you have no choice but to follow the latest javascript framework, because thats who's hiring. They want to build their new doodad in the latest doodad - react, Vue, ...., because thats what their google turned up thats the latest and greatest.

Further if you're looking at getting your next job, you'll make your next project using the latest doodad, because thats who's hiring when you finish this project (as long as your project doesn't take to long and you miss the boat - you can probably quit midway, I suppose)

</comment><comment><USER6> Javascript has always gone through hype cycles.

Interestingly, it appears to be somewhat correlated with market manias and peaks near the tops of markets.

Generally, following industry trends appears to be good for individual careers but bad for code bases (on average, but with occasional big payoffs.)

<comment><USER38> Since I own my career but signed away all rights to the code I write as a condition of employment I'm OK with this trade-off.

</comment></comment><comment><USER39> Agreed entirely. Now all you have to do is convince my team of this without being bombarded with the platitude of "don't reinvent the wheel."

</comment><comment><USER40> Have followed the trends and I now know Ember, Angular(both legacy and new), Vue(with and without typescript), and React(both classes and hooks). I've also used Svelte, and Stencil JS in my personal projects. In addition, I've also dived headfirst into GraphQL and Typescript pretty heavily lately.

Do I regret investing time in learning any of those frameworks or technologies?

Not at all. It was fun and interesting at the time I learned something different from each of them. Perhaps the most valuable thing I learned was that it is worthwhile to evaluate new technologies and to continue learning new things.

Does it devalue me as an Engineer to learn many things as opposed to becoming an expert in a single tech stack?

Much the opposite. A lot of the underlying principles and architecture remain the same and yet, I find each framework offers something new. Whether it's questioning some convention, or approaching a problem with a different paradigm, or just being heavily opinionated, I feel like I gained some value from each of these and had fun while doing so.

<comment><USER41> The downside probably being that an employer paid you during that time of learning and didn't get much work product out of it.

Learning for the sake of learning is an infinite endeavour.

I try to practice strategic learning - learning skills/frameworks/topics that will have a high likelihood of being used in the course of my _current_ project.

There's just so so much out there... focus is everything.

<comment><USER40> I am actually paid by my employer to do 5 hours of training per week. It's required and I am allowed to study anything I want, whether it's a new framework or a self-improvement book.

I usually spend that time studying something that I think may be useful or related to my job but I have been encouraged to explore. My employer is a big believer that innovation comes from exploration.

As you pointed out, it is an infinite endeavor. I'm okay with that. If I just stuck with the current technologies that were used when I first came in, we'd probably still be using jQuery and .ERB templates. Instead I personally pushed for using new technologies and my team is personally responsible for introducing Vue, Typescript, and GraphQL to our stack among other technologies.

</comment></comment></comment><comment><USER42> One problem I have with that hype cycle diagram is that it appears to show that all technologies that get a lot of hype will eventually even out and get good adoption once they go through some growing pains.

Realistically though a lot of new tech will get into the hype stage and then everyone will realise that is in fact no good or just disappear for some other reason.

People see that diagram and think it doesn't matter if you jump in at the hype stage because _eventually_ this tech will become mainstream, when a lot of the time that graph just drops to zero after the hype stage.

</comment><comment><USER43> Agreed. I approach it more from a "Draw a line in the sand" perspective.

We start a project, pick our stack, pick framework versions and features to use. And then we code for a year using those decisions. We do watch to see what new things come up over the course of a year. We also learn lessons from our choices. When our year is over, we talk about new things, evaluate them, decide what we want to adopt, and move the line in the sand to include the changes that make sense. Then... for another year, stay where we are.

</comment><comment><USER44> One thing that is, unfortunately, a bit neglected in the post: dependencies deprecate and JS has a lot of them.

One npm audit shows a lot of vulnerabilities for the long trail of dependencies in my Angular 4 app. My web app uses Hapi 17 and many plugins have changed APIs in the more recent version.

This fact alone leads to many heavy refactorings and even rewrites.

As a solo dev, I can only try to reduce dependencies (taking a massive hit on productivity) or keep up with the newest way to write stuff in my former self's framework of choice.

</comment><comment><USER45> This lustrates a problem I've encountered on a few recent projects - we are suffering an embarrassment of riches when it comes to front end technology.

I found myself slipping in the architect role on a few recent projects with various employers and being forced to make the call on which front end framework to use. The problem is that there are so many to choose from and it very hard to predict what you will need in terms of features from your chosen framework six months or longer after making your decision.

Plus, your fellow devs will probably be arguing with you over which one is better based on their experience. All the emails and messages pointing me to various websites claiming React/Vue/Angular etc is best with stats and graphs I really don't have to the time to get my head around.

It's that fear of making the wrong choice that bothers me. The idea a year down the line the front end seems a bit sluggish and someone then points out that {other_framework} would be flying with the same workload.

Don't get me wrong choice is good, but with so much going on in the world of front-end right now coupled with all the hype and shouts about which is best it is hard to just pick one and run with it. Especially in the metric driven world we live in where a manager who doesn't get tech will berate you for choosing the wrong framework or wonder why you aren't buying in the latest hyped up framework.

That being said my preference is to use a framework to prototype and then convert to plain old JS where possible.

</comment><comment><USER46> I think Software Engineers' role is to pick the right tool for the job - taking into account all the advantages and drawbacks of each one. Following the trends is a good way of knowing if any of the drawbacks of the previous tools were alleviated in the new ones. Of course the refactoring time must also be a deciding factor in a switch - most of the times it won't be worth it. I think what the author meant was don't follow the JS treds _blindly_.

</comment><comment><USER47> Let's reverse the question: if you didn't follow the trends, were a decision maker, and wanted to bet on a frontend "framework" for the next 10+ years for a greenfield (or full rewrite) project. What would you chose in 2020 ?

From where I stand, it seems vue or react aren't going away anytime soon. But the same could be said of angular, ember, and probably many others. What would you chose and why ?

</comment><comment><USER48> The problem to me isn't so much hype trains for this or that framework but that, as a Front-Ender myself, many Front-End Devs don't know how to do anything without a framework; the person I report to, the Front-End Manager, had been mucking about with jQuery for 15 years straight and didn't know about CSS animations.

I was able to work alongside a very saavy consultant for a year when I started out who I feel pointed me in the right direction wrt coding 'from the problem itself', if you will, but they'd have me do interviews and I'd be astounded at what applicants didn't know or grasp who'd been doin this front-end thing much longer than I.

If there were better solution design pedagogy instead of React's original marketing of "We know better about efficient DOM updates than you" I think you'd see substantially less reliance on these types of things, and probably a lot less unmaintainable code disguised as maintainable because it uses "a framework".

</comment><comment><USER49> I'm teaching frontend development to designers right now and after almost a semester, I have the feeling I have to cut out much more concepts.

There are just too many ways to do things to teach a beginner in one semester and they just should be able to create basic prototypes anyway.

<comment><USER50> Serious question, why do they need to know anything about creating prototypes?

<comment><USER49> The argumentation went like:

We did design projects for companies and showed them our ideas as mock images and they didn't like them.

We then implemented the exact same designs as prototypical apps, they clicked around in it and loved it.

<comment><USER51> You can mock user interactions in Sketch and Figma.

<comment><USER49> I don't use these apps.

It were design teachers that hired me, so I guess they knew and still wanted their students to learn a bit programming.

</comment></comment></comment></comment></comment><comment><USER52> I think either vanilla js, or the other route, a full blown batteries included, like Visual Basic 6 was for windows development. Either abstract away nothing, or everything.

In the middle, is developing with a framework. The problem is you have to know the language + the peculiarities of the framework. New frameworks and "features" happen on too short a timeframe. And, frankly, it costs too little to just invent a new framework. So, 10000 frameworks.

There is a mental cost that increases exponentially with every layer of abstraction. When people have to post questions about why they can't understand such "features" of panacea x , that's the problem.

<comment><USER53> Been a while for me, but I agree

But when I spent a year doing Javascript I found that in JQuery there were a lot of shortcuts I was writing my self to lower the RSI from typing long Javascript statements.

Beyond that there is nothing useful in JS frame works. They make simple things easy and the complicated stuff (which is design and logic) stays hard.

</comment></comment><comment><USER54> I just wish more developers would stop trying to improve their products by chasing the newest, coolest standard, and instead work on fixing bugs. But that's not en vogue these days.

</comment><comment> seph-reed I don't use frameworks, and have found more efficient, better organized, more native ways of doing everything that frameworks do.

It took a lot of time and effort and being a stick in the mud, but the trick was ultimately an algorithm/abstraction I call source derivation (SDx).

Here's a simple example of the algorithm: [https://codepen.io/SephReed/pen/gOaeQLv](https://codepen.io/SephReed/pen/gOaeQLv)

</comment><comment><USER55> Unfortunately we work with others and sometimes powerless in this. I worked in 2 front-end teams both using redux inherited from the early stage of the projects. In both cases the marority of the team don't like it but we're too deep in it to get out without affecting our roadmap. Another case I had to talk a college into not using graphql just because he could, felt like a jerk.

</comment><comment><USER56> this is a fight a developer alone cannot win. my first job after college was in a company that created a software to manage industrial production. they were on their third refactor of their frontend. first was polymer?, then angular and now they were trying vue. I spent a lot of time and energy trying to convince them to write they own framework, if they like frameworks so bad. funny story, that's how I built FOS, the framework I use on my website. anyway, I was hired by some other company and don't know the end of the story there, but I'll bet they went with vue, just to rewrite the whole thing in react in a couple of months

</comment><comment><USER57> I recently started a new app using Material UI, after doing web dev since pre- CSS days. I'm trying to grok CSS-in-JS, and it's only been a few weeks but it still feels so completely unneccessary.

</comment><comment><USER58> tl;dr: use TypeScript, but don't worry so much about hooks.

\---

I recently switched my JS + PureComponent mobile app to TypeScript and FC Hooks. I felt motivated to do so because:

\- You cannot use hooks in PureComponent render(). The two modalities do not play nice together.

\- Many of the libraries I use like react-spring and react-navigation have fully embraced hooks, sometimes without an HOC equivalent. So I felt forced to also embrace hooks or write complicated wrappers to facilitate them, for example new component lifecycle methods (e.g. componentDidFocus).

Some things I noticed...

1\. TypeScript is amazing. Combined with Intellisense it has given me coding superpowers. I can write code faster and with dramatically more confidence.

2\. You can incrementally shift your JS app to use TypeScript. You can even write type declarations for your JS code without rewriting it in TS. Most of your favorite libraries already have such type definitions (see DefinitelyTyped).

3\. Hooks require a significantly different mental model than PureComponent. It feels horribly wasteful at first but apparently relies heavily on JS interpreter optimizations and memoization to achieve superior FMP performance[1]. My app feels noticeably snappier now, but it took a good bit of tuning to correct issues introduced during the port.

4\. It IS indeed possible to write a functional wrapper that provides otherwise unavailable hook support for your Component or PureComponent. The tricky part is that you need to use a ref to invoke lifecycle methods on your wrapped component[2].

In retrospect I think I would recommend _against_ porting an existing React project to hooks. However I would absolutely recommend porting to TypeScript, even if you do so slowly and incrementally.

1\. [https://medium.com/@dan_abramov/this-benchmark-is-indeed- fla...](https://medium.com/@dan_abramov/this-benchmark-is-indeed- flawed-c3d6b5b6f97f)

2\. [https://medium.com/reactnative/custom-lifecycle-methods- in-r...](https://medium.com/reactnative/custom-lifecycle-methods-in-react- native-f84c7257eaa6)

<comment><USER59> I was initially kind of worried about TS. It has kind of a high barrier to entry with linter settings, typescript-specific setting, solving how to compile your code easily, learning the new syntax, etc. etc.

I literally spent like an hour reading up on it and learning it, and I realized I never want to go back to a plain old JS. TS feels way closer to Java than to JavaScript, with its own quirks and way of functioning of course. The barrier of entry seems perceived, but not really that big of a deal.

I wonder what are the cons of TS.

<comment><USER60> > _TS feels way closer to Java than to JavaScript_

You and I clearly have different understandings of Java, JS, and/or TS. Typescript's structural typing feels like the opposite end of the spectrum from Java's nominal types.

<comment><USER59> > Typescript's structural typing feels like the opposite end of the spectrum > from Java's nominal types.

Be that as it may, I said nothing about type systems. I said that TS feels closer to Java than it does to JS. Seeing as JS has no type system, I fail to see your argument.

<comment><USER60> > _Be that as it may, I said nothing about type systems._

Typescript is nothing more and nothing less than a language that adds static typing to Javascript. Any discussion about how Typescript changes the feel of Javascript is a discussion about type systems.

> _Seeing as JS has no type system, I fail to see your argument._

Javascript absolutely has a type system. It's not static, and there are lots and lots and lots and frankly too many ways to automatically coerce types, but it definitely has a type system.

</comment></comment></comment></comment></comment><comment><USER61> I remember 2016 as the year my peers started telling me that jquery was evil. Also a year of switching from angular to React/redux

</comment><comment><USER62> Didn't read. Follow JavaScript trends that make sense for you and your team. Ignore the noise, get shit done.

You know what I hate more than "JS fatigue" \- it's ppl complaining about "JS fatigue". Software evolves, and I'm always looking to bring a better experience for my users - and then means replacing components sometimes when there are clearly better alternatives, whether that is for developer experience, smaller bundle sizes, etc.

<comment><USER53> Depends if you want your code to be maintainable into the future with other teams.

If you do not care about the future (which os OK in some contexts) then you are correct

</comment></comment><comment><USER63> Stay curious, try new things! Party of being a developer is exploration and discovery. Do not discourage!

</comment><comment><USER64> Some days I miss using prototype.js and script.aculo.us

</comment><comment><USER65> Article very empty of any real, tangible advice.

</comment><comment><USER55> What do these have to do with managing fads?

</comment><comment><USER66> I remember having a coworker who was "learning clojure". That guy did more damage than could even be imagined.

</comment><comment><USER67> A while back, I got tired of dealing with the mess of Gatsby, Next.js, and Vuepress, so I made my own static site generator in Python.

I don't want a GraphQL database for my static site. I just want something to template out my site's boilerplate, and I don't want to deal with Webpack speed, or lack thereof. One file, ~200 loc, and I understand all of it.

The tentatively named Zhi works fast enough for full rebuilds triggered by fswatch. It does one thing and does it well:

      fswatch -0 -e .venv -e out . | xargs -0 zhi build

If there's interest in a simple, understandable Jinja-based static site generator, I can clean it up and release it: [https://github.com/0az/zhi](https://github.com/0az/zhi) (empty repo).

<comment><USER59> If you didn't like Gatsby, why not simply use one of the tens of simpler static generators? Hugo is extremely popular, but also just Jekyll or something similar. You won't understand the whole codebase, most likely, but on a user level, it's literally just a "put a markdown file in this directory" type of a thing for most of these generators...</comment></comment>


Linux - Stop holding our kids back - <AUTHOR> http://linuxlock.blogspot.com/2008/12/linux-stop-holding-our-kids-back.html

<comment><USER2> Is this real? Or did someone make it up to generate a strawman argument?

<comment><USER3> This must be made up, because the person admits to trying out Linux then goes on a ridiculously over the top pro Microsoft slant (without argumentation). Somebody so clueless wouldn't even know (if) they tried out Linux in college...

<comment><USER4> Two possibilities come to mind: Satire, as mentioned by other people, or the original teacher is lying about having used Linux. As anybody who has been around on the internet (or BBS or Usenet or...) for a while has learned, some people take a very scorched-earth approach to argumentation, and if lying about having tried Linux bolsters the argument, in it goes, regardless of whether it's true. (Maybe.)

<comment><USER5> It's also possible that the she was forced to use Unix in college. As she is not a techie, and probably wouldn't pay a very large amount of attention to the details, mixed the two up.

<comment><USER6> The way I read it she had to use the command line when she was in college, and thinks the GUI is "stolen" from Windows. (Hence the concern about legality)

</comment></comment></comment></comment></comment><comment><USER7> This is very, very old satire. If this really is a recently received email, then the person who responded got punkd. I'm gonna go see if I can located the oldest such letter.

</comment><comment><USER8> Balanced updates:

[http://www.austin360.com/blogs/content/shared- gen/blogs/aust...](http://www.austin360.com/blogs/content/shared- gen/blogs/austin/digitalsavant/entries/2008/12/11/breaking_local.html)

[http://www.austin360.com/blogs/content/shared- gen/blogs/aust...](http://www.austin360.com/blogs/content/shared- gen/blogs/austin/digitalsavant/entries/2008/12/11/aisd_director_o.html)

</comment><comment><USER9> I can understand the subtle anger in the response... but belittling someone is not the way to win new converts.

conversely, i've seen worse responses

</comment><comment><USER10> Old:

[http://www.google.com/search?q=%22called+a+confrence+with+th...](http://www.google.com/search?q=%22called+a+confrence+with+the+student%22&ie=utf-8&oe=utf-8&aq=t&rls=com.ubuntu:en- US:unofficial&client=firefox-a)

</comment><comment><USER11> Did I miss something? There are 2 parts, one which is pro microsoft and then a defense post which is pro Linux...right?

</comment><comment><USER12> TRS-80 was good enough for me, should be fine for today's kids.

</comment><comment><USER13> Wow, Karen is an embarrassment to society.

</comment><comment><USER14> _Mr. Starks, I along with many others tried Linux during college..._

Anyone else hear a tone alike one admitting to past drug use?

<comment><USER15> Hey, it was college. Everybody experiments. I used to swing both ways... dual booting that is.

<comment><USER16> What does it say about your sexuality if you also had BeOS on there? I hope my wife doesn't read HN.</comment></comment></comment>