Show HN: embedcurl.com - Pretty curl commands for your web site or blog - <AUTHOR>

Hey all, As a CEO of a growing startup I don't get to code as often as I like and when I do, I try not to annoy my team with my terrible code :) So to scratch the itch, I've built some of side projects related to what our company does. The latest is embedcurl.com
I see a lot of API docs and blogs posting curl commands that are really hard to read and I figured I could make them easier to read and add some niceties like easier copy/paste, tooltips on flags, etc. They also gracefully degrade if javascript isn't enabled back to a <pre> element.
The parsing is done in Python with shlex and argparse (thanks to my co-founder Frank for helping with that part). We're running this on our production infrastructure so it should scale just fine.
My friends at loader.io have already integrated it with their API docs: http://docs.loader.io/api/v2/put/tests/:test_id/run.html
I'd really like your feedback, especially if you enter a command that doesn't parse correctly.
Thanks! <comment><USER2> This is really cool. Would be neat if the whole experience could be embedded using an embeddable version of hurl.it, too.

</comment><comment><USER3> Need to wrap the url in strings, having multiple query parameters (&) in the url will cause issues.

<comment><AUTHOR> Can you post an example command to repro so I can look into it more closely? Thanks!

<comment><USER3> Not sure what you mean by repro but this is a simple command that would cause issues if you were to run it. Not issues with your tool, but BASH will background the command up to the ampersand and then set the variable other to 3

curl [http://example.com/foo/123?stuff=1&other=3](http://example.com/foo/123?stuff=1&other=3)

</comment></comment></comment><comment> Pirate-of-SV Long flags are more readable in my opinion. I always use long flags in scripts, the shorter version is nice on the command line though. Do you plan to open source this? Github repo?</comment>


Launch HN: Synbio School (Synthetic Biology) - <AUTHOR> https://www.synbioschool.com/ <comment><AUTHOR> Hi Hacker News! OP here. We are a few biohackers/synthetic biologists from MIT and UCSC. We are launching a Synthetic Biology course, where our goal is to prepare those who want to pursue synbio projects all the skills and tools necessary to realize their vision.

We are offering an early-bird discount for the online course. If you have any questions please reach out to email@example.com

Thanks and happy to answer any questions!

</comment><comment><USER2> I believe this could work but the website lacks samples (is it better than wikipedia, youtube videos and other tutorials ?) and a proof of authority (what makes you guys experts in the field). For 500$ you need to have a better idea of what you are buying.

<comment><AUTHOR> Hi @zulko, these are great points and thank you for this feedback. We will make sure to address these on our website asap.</comment></comment>


How to Start Programming - <AUTHOR> https://www.vladimircicovic.com/2020/05/how-to-start-programming <comment><USER2> > 1\. Start learning Python

I should preface this by saying I'm still pretty much a programming novice, and this is my personal experience with learning to program.

My very first attempt to was with Zed Shaw's Learn Python the Hard Way. I know his approach is controversial among the Python community; personally, it made learning to program even more intimidating than it needed to be, and I ditched it about halfway through.

Automate the Boring Stuff with Python[0] was a fantastic introduction for me as an absolute beginner, in large part because it showed how useful programming can be to non-IT people. It felt great to have actual, somewhat useful, projects as I went through the book.

I then went through the official Python tutorial[1] to get a rough idea of the basics I should learn. Finding out what I didn't know, that I needed to know, was really helpful.

Real Python[2] has some nice tutorials on developing with Python.

[0]: [https://automatetheboringstuff.com/](https://automatetheboringstuff.com/) [1]: [https://docs.python.org/3/tutorial/](https://docs.python.org/3/tutorial/) [2]: [https://realpython.com/](https://realpython.com/)

<comment><AUTHOR> Tnx for the information. I did not want to suggest any books - the only reason is there is 1000 links on what book. But I want the reader to develop skills from 0 to advance.

Tnx for advice and links!</comment></comment>


GoboLinux 015 released - <AUTHOR> http://www.gobolinux.org/ <comment><USER2> Really excited to see this get active again. GoboLinux sets itself apart from other distributions being one of the few that tackle a drastic change to the filesystem. They keep compatibility with the filesystem hierarchy standard via symlinks but that is mostly hidden from the user.

For those wondering about more information there is definitely a better writeup about the file system layout on wikipedia.

[http://en.wikipedia.org/wiki/GoboLinux](http://en.wikipedia.org/wiki/GoboLinux)

As well as more recently written slides

[http://gobolinux.org/doc/fisl2014/GoboLinux-015.pdf](http://gobolinux.org/doc/fisl2014/GoboLinux-015.pdf)

I'd say the filesystem is really the differentiator here. Back when I first tried it out boot times were insanely fast compared to other distros of the day _. However I 'm sure that gap has been shortened (if not inversed.. haven't tried the latest version.)

_ Not saying the filesystem had anything to do with the boottimes. That was because they use a different boot system.

</comment><comment> vertex-four Another distribution which ditches the FHS is NixOS. On top of this, it implements a configuration management system as a core part of the OS, is a source distro with an online binary cache (so installing things by default doesn't require building anything, but it's very easy to modify package definitions), and allows for very easy rollbacks, multiple system environments, and a bunch more interesting stuff. It's also not had a multi- year hiatus as a recent part of its history.

<comment><AUTHOR> True. But the hashes Nix uses in folder names make it a bit more complicated than it has to be. But I like both GoboLinux and NixOS and really hope one of them or a similar approach takes off some day.

<comment><USER3> As someone that just (2? 3? days ago) migrated his laptop to nixos I can certainly sympathize. That said, hashes aren't a big issue and the community is quite nice. Packages aren't thaaaat up to date, but pull requests to bump these things are answered in days (sometimes hours). I have FreeBSD PRs open for weeks...

In the end I like it. I'm not sure if this is the best thing ever, but I appreciate the fact that I have a single file that describes my whole system.

<comment> vertex-four > Packages aren't thaaaat up to date, but pull requests to bump these things > are answered in days (sometimes hours).

It's also possible to write custom packages as part of your configuration if you need them "right now", through `packageOverrides`. As a general rule, packages are updated by people who need newer versions of packages; there's not really a maintainer infrastructure like most distros have. If something needs to be done, whoever is affected by it does that thing. I'll point out that there's not a security team either yet, so it's not really suitable for real production use.

Personally, as someone who's battled the usual configuration management approach of "here's a fully working OS with its own ideas of how things should be done... now modify that through a really awful ad-hoc scripting language without breaking anything", NixOS is amazing. It's even possible to build tests into your system configuration!

</comment></comment></comment></comment><comment><USER4> I wish other distros would follow GoboLinux's lead and do away with the horrible "standard" Unix filesystem. It is a usability disaster.

<comment><USER5> I actually like the standard Unix filesystem layout, I find it much better organized than the one used by Windows or OS X.

</comment></comment><comment><USER6> So just to be clear this is a version of Linux which abandons the filesystem hierarchy standard? (man 7 hier ; [http://www.pathname.com/fhs/](http://www.pathname.com/fhs/))

<comment><USER7> Based on the first paragraph of the site, they're indeed using their own filesystem layout. Whether or not it's cleaner/easier/useful is, of course, up to the user.

</comment></comment><comment><USER8> From [http://www.gobolinux.org/?page=at_a_glance](http://www.gobolinux.org/?page=at_a_glance)

 _~] ls -l /usr/include/stdio.h | cut -b 45-

stdio.h -> /Programs/Glibc/2.3.6/include/stdio.h_

Does anyone know what happens if e.g. a later version of Glibc overwrites the stdio.h 2.3.6 version found under /usr/include/stdio.h?

How does GoboLinux still retain its "compatibility with the Unix legacy" in such situations without breaking things?

<comment><USER9> It builds software in it's own namespace so it sees /usr/include/stdio.h as a symlink to whatever version it was built for, and the symlink won't change if you update Glibc.

</comment></comment><comment><USER10> Why ? I mean don't get me wrong, it does look organized yes, but can someone explain me the pros and cons about such a thing ? the website is very sparse about it.

<comment><USER11> For example:

* Installation of multiple versions of the same program is trivial

* Uninstall programs just by deleting a Folder

<comment><USER12> But you would still need a tool to manage dependencies, track updates, etc. And it will be this tool that you will need to use to keep the system in a consistent state.

</comment></comment></comment><comment><USER13> I don't see the point. If it's all about easy to compile and use multiple software versions, why not just install stow in your current distro?

</comment><comment><USER14> So is version 015 supposed to be 13 or 15?

<comment><USER15> Yes, 015 is 13 octal. :) Remember when a bunch of distros inflated their version numbers to catch up with each other? We decided to poke fun on that and make the GoboLinux version numbers octal, so we'd have "scheduled bumps", so yes, we went from 007 to 010, and will go from 017 straight to 020 in the future :)

</comment></comment><comment><USER16> The filesystem sounds similar to what Homebrew for OS X does.

<comment><USER17> More appropriately, Homebrew is _very_ similar to GoboLinux's Rootless project.

It's also worth noting GoboLinux predates Homebrew by about 7 years.

<comment><USER15> In fact, the original documentation of Homebrew described this approach as "The GoboLinux Way". (They no longer call it that, but this reference is buried somewhere in their git history.)</comment></comment></comment>


Errata prompt Intel to disable TSX in Haswell, early Broadwell CPUs - <AUTHOR> http://techreport.com/news/26911/errata-prompts-intel-to-disable-tsx-in-haswell-early-broadwell-cpus

<comment><USER2> For those wondering, the TSX instruction set is [http://en.wikipedia.org/wiki/Transactional_Synchronization_E...](http://en.wikipedia.org/wiki/Transactional_Synchronization_Extensions)

I first heard about transactional memory when Sun had plans to implement it for its UltraSPARC Rock processor. There is a decent overview of the concept at [http://en.wikipedia.org/wiki/Transactional_memory](http://en.wikipedia.org/wiki/Transactional_memory)

<comment><USER3> The techreport.com article says:

      The obvious initial targets for TSX optimization are server-class applications like transactional database servers.

Looking at your wiki links though, I would think this would be awesome for almost any high-performance multi-threaded program. Am I wrong about that?

<comment><USER4> In theory yes, though thinking in terms of transactions is subtly different from thinking in terms of threading critical sections. Particularly, they differ in how they handle contention. Locks block while transactions abort/fail. Simply retry-ing a transaction is also not a good idea which is why it is currently suggested to fallback on locks [1]. So I assume the suggestion of using it for dbs is because it would be more straight-forward as dbs are already used to transactions.

1\. [https://software.intel.com/en-us/blogs/2013/06/23/tsx- fallba...](https://software.intel.com/en-us/blogs/2013/06/23/tsx-fallback- paths)

</comment></comment></comment><comment><USER5> >Software developers who wish to continue working with TSX will have to avoid updating their systems to newer firmware revisions—and in doing so, they'll retain the risk of TSX-related memory corruption or crashes.

Say I bought a TSX enabled CPU specifically for that feature, I wonder if Intel will give me my money back... (they can have their broken CPU of course too)

<comment><USER6> Theoretically, yes - I almost returned my laptop with an i7 2630QM CPU, which should, as indicated on Intel's website, support AES instructions. But the specific BIOS of that laptop has them disabled and there was no way to re- enable them. So I contacted the manufacturer, and after a few emails they agreed that yes, I can return the product as "not as described" but they said that a new BIOS is also in the works for that laptop and if I am patient it will be made available soon - and it was, AES instructions were enabled after a patch issued 2 months later.

<comment><USER7> The real question is why does this depend on the BIOS

<comment><USER8> In case of AES I guess US crypto export regulations running amok...

<comment><USER9> But all BIOSes and motherboards are made in China.

<comment><USER8> If the guys on the label are American, then US regulations apply, too.

Even if not, the US stick their nose anywhere, even where it does not belong...

</comment></comment></comment></comment></comment></comment><comment><USER10> Unsurprising. I don't think the details of TSX have been revealed, but the implementation potentially has complex interactions with the cache subsystem: [http://www.realworldtech.com/haswell- tm](http://www.realworldtech.com/haswell-tm).

Given that TSX is one of the features that distinguishes some of the more expensive Haswell SKU's, is Intel going to issue a refund for affected customers?

<comment><USER11> I've been tempted recently by the _Devil 's Canyon_ repackaging of Haswell that for the first time has some of the workstation/server features (VT-d, TSX, but no ECC) enabled on an overclockable model. Losing TSX definitely cuts down on that temptation a bit, but they've still got the combination of full virtualization capabilities and much higher single-threaded performance than anything else out there.

<comment><USER12> Four cores is really not that attractive... also a lack of ECC with the amount of ram systems have today is starting to seem irresponsible. The probability of getting bitflips is macroscopic.

<comment><USER11> I understand that the 4790K isn't really a tradional workstation chip, but it's definitely the right thing for my workload which involves a simulation that's only partially multithreaded and would benefit a lot more from higher single-core speed than it would benefit from more than 4 cores. And ECC would be nice, but in my opinion isn't a hard requirement yet for all workstation usage the way it is for servers; I can certainly get by without it, since the base failure rate of the software I'm using is much larger than that caused by hardware memory corruption.

</comment></comment></comment></comment><comment><USER13> Yeah, this is exactly why high performance chips have a microarchitecture that lags client chips. Such bugs would devastate the value of those chips. This will affect haswell Xeon. I bet some serious discussions for delaying that chip are ongoing right now.

</comment><comment><USER14> Here's the current list of Errata's from June: [http://www.intel.com/content/dam/www/public/us/en/documents/...](http://www.intel.com/content/dam/www/public/us/en/documents/specification- updates/4th-gen-core-family-desktop-specification-update.pdf)

I see two about TSX:

      HSD87 X No Fix          Intel® TSX Instructions May Cause Unpredictable System behavior
      Problem: Under certain system conditions, Intel TSX (Transactional Synchronization Extensions) instructions may result in unpredictable system behavior.
      Implication: Due to this erratum, use of Intel TSX may result in unpredictable behavior.
      Workaround: It is possible for the BIOS to contain a workaround for this erratum.
      Status: For the steppings affected, see the Summary Table of Changes

      HSD114 X No Fix         Intel® TSX Instructions May Cause Unpredictable System behavior
      Problem: Under a complex set of internal timing conditions and system events, software using the Intel TSX (Transactional Synchronization Extensions) instructions may observe unpredictable system behavior.
      Implication: This erratum may result in unpredictable system behavior. Intel has not observed this erratum with any commercially available system.
      Workaround: It is possible for the BIOS to contain a workaround for this erratum.
      Status: For the steppings affected, see the Summary Table of Changes

HSD114 above seems to be the bug from the techreport article.

</comment><comment><USER15> So.. will everyone simply accept the microcode update that disables those instructions? Or will there be some kind of compensation for newer laptops etc? Wonder how Apple will deal with this, for example.

Or is this such a non-issue that nobody cares?

<comment><USER16> Yes, everyone will accept the microcode update. TSX is still pretty new and I doubt a lot of code uses it. Intel tends to phase features like this in over a few generations of CPUs for this reason.

The only real impact is that code that relied on TSX would need to rely on fallback methods of accomplishing the same tasks. Since there's probably not much of that floating around, there's very little impact at this time.

<comment><USER17> How do CPU vendors issue a microcode update such that no hacker could make their own malicious update? It's obviously a cryptographically signed update, and the CPU checks that the update is signed by the expected key, but does that mean every CPU is hardcoded to check for a specific key? What happens if that key is compromised? Is every CPU at risk forever at that point, or can the CPU be updated via software to check for a newly issued key? Also, were is the private key stored? Some vault somewhere? How would a CPU vendor know if the key had been surreptitiously copied, and some rogue group was issuing malicious updates to a specific target's CPU?

Is it even advantageous for an attacker to have the capability of issuing microcode updates to a target computer? What sort of attacks could you mount via microcode updates?

<comment><USER15> I think they are mostly undocumented, but here is some research I found online: [http://inertiawar.com/microcode/](http://inertiawar.com/microcode/)

I'm guessing the private RSA keys are extremely well guarded, probably stored in a HSM that only allows signing, not key extraction, so that the keys cannot even be revealed to Intel.

On the other hand, who knows. There's certainly been cases of code signing keys on the loose (Adobe, etc) and even a compromised HSM host (Fedora, someone managed to sign compromised openssh .rpms)

<comment><USER16> Given that Intel processors largely run the servers that the modern world runs on, I would expect that the NSA/CIA has done a full security audit of their microcode processes. The US government is nothing if not thorough about these types of potential security issues.

<comment><USER18> And in exchange for that audit they gained permission to get their own microcode updates signed, too?

<comment><USER19> I'm not sure why they'd want it. Unless there's secret non-volatile storage on Intel chips, there's relatively little of value that you can do using a rogue microcode update. This is because Intel chips reset to factory microcode when rebooted.

It's plausible that a rogue microcode update could be used to bypass TPM static-root-of-trust protections, though, and a microcode update could certainly bypass TXT's dynamic root of trust. This might enable a bootable USB stick that would load malicious microcode and then reboot warmly enough to preserve the microcode and then launch the OS with a TXT bypass.

Even so, I don't really see the point. So far, essentially every BIOS can be freely (or freely using an exploit) reflashed from kernel mode, and a new image could contain malicious SMM code, and SMM code can also bypass both static and dynamic roots of trust.

<comment><USER18> Make RDRAND less random, store AESNI key data in a place you can later exfiltrate it from, provide SMM capabilities to the current execution context with some magic opcode (I grant that the latter is easier done through a malicious firmware update - but that's also easier to detect, since x86 code is a known format)...

Modulo the microcode signature, flash is better locked down these days: Flash updates are typically arbitrated by the firmware (though that's also just one signature away), requiring a reboot, while microcode updates are still free for all (in ring0 - realtek already lost a driver signing key once, why not again?).

<comment><USER19> Flash updates arbitrated by firmware? In theory, yes, but in most systems they're not. [1][2]

[1] [http://www.syscan.org/index.php/download/get/6e597f6067493dd...](http://www.syscan.org/index.php/download/get/6e597f6067493dd581eed737146f3afb/SyScan2014_CoreyKallenberg_SetupforFailureDefeatingSecureBoot.zip) [2] [http://mjg59.dreamwidth.org/30773.html](http://mjg59.dreamwidth.org/30773.html)

<comment><USER18> I have a board normally running UEFI Secure Boot with no flash lock enabled at all right here on my desk - with UEFI replaced by a sane coreboot implementation (which locks down flash and SMM memory and signals unconditionally on boot).

So yes, I'm quite aware of the immense set of faults in UEFI implementations (some of which are encouraged by UEFI's design, where more layers of UEFI are added to mitigate them).

But as an attacker I wouldn't want to assume that I run into any single of the many UEFI implementation quirks and adapt my attack to everyone of them.

And I really hope for Intel that Tianocore won't become an endless stream of portable UEFI security issues - otherwise the IBVs might get second thoughts about standardizing on a single codebase.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER20> I think this is the latest specification update for at least some of the relevant processors:

[http://www.intel.com/content/dam/www/public/us/en/documents/...](http://www.intel.com/content/dam/www/public/us/en/documents/specification- updates/4th-gen-core-family-desktop-specification-update.pdf)

It was last updated in June, so I guess it doesn't contain this latest erratum. Can't wait until it's updated... though I don't know if Intel is likely to disclose details.

<comment><USER21> This one has been updated: [http://www.intel.com/content/dam/www/public/us/en/documents/...](http://www.intel.com/content/dam/www/public/us/en/documents/specification- updates/xeon-e3-1200v3-spec-update.pdf)

<comment><USER22> I read through this and found the TSX errata as #136 on a list of 140 issues. I was pretty surprised; some of these issues are major, showstopper crash bugs (admittedly mostly only affecting operating systems developers, and many with workarounds.)

Just reading through these issues, I see a handful that deal with specifically with external (proprietary?) hardware integrations, like with integrated Intel graphics boards. Why is the CPU loaded up extra jazz for with specific integrations like this? Is this to support a system-on-a-chip optional kind of configuration, or is this Intel trying to give themselves some sort of advantage in the graphics adapter market?

If it is the latter, then it serves them right to have these errata and instability due to adding all that extra competitive advantage nonsense on the chip.

</comment></comment></comment><comment><USER23> So, what's the bug exactly?

<comment><USER17> I get the feeling that few people know, and they're not telling. Maybe to prevent exploits from being written against the existing CPUs.

</comment></comment><comment><USER24> Dang. I bought an i4770 rather than i4770K specifically because of TSX.

<comment><USER25> I also did this, missing out on 100mhz of base clock (3.4ghz vs 3.5ghz for the k).

TSX seemed like a once in a decade step forward, though as I understand it the restrictions with the cache size (and thus the amount of memory you can write to before the transaction gets too big) meant it wasn't very practical for much beyond optimistic lock acquisition.

For example, PyPy isn't planning on doing a TSX port even with their enthusiasm for transactional memory.

Also influencing my decision, I bought a 2600k a few years back, but never bothered overclocking it, which I guess was an admission that the excitement I found for hardware when I was a child was dead. I guess you either have the money, or the time, but rarely both.

It's disappointing that this microcode update isn't being done in such a way that you can re-enable it after agreeing to a disclaimer that it's not for production use. I'm not sure what the mechanism for this would look like, but given that Intel sold cards that unlocked Hyperthreading, I'm sure it's possible.

[http://www.engadget.com/2010/09/18/intel-wants-to- charge-50-...](http://www.engadget.com/2010/09/18/intel-wants-to-charge-50-to- unlock-stuff-your-cpu-can-already-d/)

Edit: The article has been updated saying that it will be possible to enable TSX for development purposes on Haswell-EP at least.

<comment><USER26> > For example, PyPy isn't planning on doing a TSX port even with their > enthusiasm for transactional memory.

Do you have more information about their reasoning behind this? From my point of view this is the highest profile software project to potentially make use of HTM, and I recall reading that the plan was to eventually introduce hardware acceleration.

<comment><USER27> In reference to the sibling post that gives more details about pypy, I'd like to call to your mind the history of the vector extensions for x86.

First revision: MMX. It reused the same registers as the older x87 floating point coprocessor (even though the x87 transistors lived on the same die). As a result, legacy x87 code and MMX code had to transition using an expensive EMMS instruction.

Second revision: (well, ignoring some small changes to MMX) ... SSE. Finally got its own registers, but lacked a lot of real-world capability.

Third revision: SSE2, finally got to a level of parity with competing vector extensions (see, for example, PowerPC's Altivec).

And so forth.

I guess the take-home lesson for me is that these new TSX instructions are indeed fascinating to play around with, but I wouldn't expect it to blow the doors off. Intel will incrementally refine it.

(The incremental approach also gives Intel a chance to study how it's being used and keeps AMD playing catch-up.)

<comment><USER28> The other big problem with MMX was that it was integer only. While that might have been ok for some application 3D games and other software that could really use the boost needed floating point and not only couldn't benefit (since it was integer only) it actually interfered (since, as you said, it reused the registers).

AMD's 3DNow had single precision floating point support, so it was actually somewhat useful. SSE followed 3DNow and added single precision support (as well as fixing the register stuff). SSE2 added double precision support.

<comment><USER27> Right, thanks for those additional details.

Today, no one would use MMX instructions (since SSE is vastly superior). I expect Intel will continue to add TSX capabilities which will eventually produce some nice results for parallel code.

</comment></comment></comment></comment></comment></comment><comment><USER29> Running a recent Ubuntu or Debian?

Install the microcode by running: sudo apt-get install intel-microcode

Alternatively install a BIOS update once available.

<comment><USER30> sudo pacman -S intel-ucode

</comment></comment><comment><USER31> That's too bad, I was really looking forward to playing around with TSX on some side projects.

</comment><comment><USER32> Well they should consider themselves fortunate since Haswell Xeon isn't yet on the market.

Are there any scenario where Transactional Memory are useful in consumer environment?

<comment><USER27> Mostly for developers to start testing their code.</comment></comment>


A Hacker Just Pwned Over 150,000 Printers Left Exposed Online - happy-go-lucky https://www.bleepingcomputer.com/news/security/a-hacker-just-pwned-over-150-000-printers-left-exposed-online/ <comment><AUTHOR> "Pwned" in this case is sending some text to port 9100 on a bunch of printers where this port is exposed. What would be more interesting to know is how many of these are printers with public IPs vs port 9100 forwarded from a NAT router, and of those, how many were done manually vs via uPnP?</comment>


Show HN: Sapper.js – towards a better web app framework - <AUTHOR> https://svelte.technology/blog/sapper-towards-the-ideal-web-app-framework <comment><USER2> I think this premise is wrong:

> 2\. As a corollary, your app's codebase should be universal — write once for > server and client

This is a mistake a lot of developers make. The server and client are not the same. As far as rendering HTML goes, the client does a superset of what the server does.

This means either the framework has to be without leaks; meaning you never need raw DOM access at all, OR it means once you do need lower-level access (for doing animations, for example) you are in trouble. You now have a problem where you have some code that needs to only run in the client. So you have to special case that code to check if running on the server. And you need a strategy for what to do in the server (do you just omit this part, or do you try to do something more basic or what?)

In my experience you run into more pain trying to plug the leaks in these "universal" apps than you would if you just had separate server and client templates. Remember that the rule of 3 is the rule of 3, not the rule of 2.

[https://en.wikipedia.org/wiki/Rule_of_three_(computer_progra...](https://en.wikipedia.org/wiki/Rule_of_three_\(computer_programming\))

<comment><AUTHOR> In practice, this isn't an issue. Component lifecycle hooks and methods (which is where anything involving raw DOM access or animation takes place) _never run on the server_ — the SSR renderer just generates some HTML for a given initial state. Once you grok that, it's easy. Certainly much easier than maintaining two codebases in parallel!

<comment><USER2> Then you have a server/client difference if the lifecycle hooks change the dom (like a jQuery plugin or something). So you have to figure out what to do on the server.

<comment><AUTHOR> The server is only involved when you first hit the page. After that, the client takes care of all the rendering. There is no discrepancy!

<comment><USER2> There's a discrepancy if the user doesn't see something when the page first renders but then does see it once the JS runs.

<comment><USER3> That would be poor coding or application design. There's no reason for that to happen with SSR. At all.

There's especially no reason for it with modern frameworks like React/Vue/etc - it's not been a technical problem for years.

</comment></comment></comment></comment></comment></comment><comment><USER4> Sorry, I couldn't resist. Second and third paragraphs, with some minor editing:

 _HTML_ is close to this ideal. If you haven't encountered it yet, I strongly recommend going through the tutorials at [https://www.w3schools.com/html/](https://www.w3schools.com/html/). _HTML_ introduced a brilliant idea: all the pages of your app are files in a your- project/pages directory, and each of those files is just an _HTML page._

Everything else flows from that breakthrough design decision. Finding the code responsible for a given page is easy, because you can just look at the filesystem rather than playing 'guess the component name'. Project structure bikeshedding is a thing of the past. And the combination of SSR (server-side rendering) and code-splitting — something the React Router team gave up on, declaring 'Godspeed those who attempt the server-rendered, code-split apps' — is trivial.

<comment><AUTHOR> If you don't mind reloading the entire page on every single navigation, and don't have any dynamic data or interactivity, this is indeed a very solid approach.

<comment><USER5> But this is where the entire argument of "do first page load server side because it's faster" doesn't make any sense.

Because then aren't you suggesting that after that, all the other pages can be slow?

The worst sites I visit now are React.js like sites, instead of the page load being slow, _everything_ is slow. Ugh. I can't wait until web 3.0 and this silly balogna with the "make a browser with React and run it inside a browser" fades out...

(note, Netflix _removed_ their js rendering from their home page cause it was slow)

<comment><AUTHOR> Server-side rendering means you get a quick _first_ load. Client-side rendering means _subsequent_ navigations are quick, because there's less data to transfer (maybe a little bit of JSON, maybe nothing at all). Going back to the server for 100kb of HTML and reloading the entire page, as opposed to fetching 10kb of JSON and instantly updating it in place, is a very 2002 way of doing things!

<comment><USER5> >...because there's less data to transfer...

The problem is that just the theory, reality if often times different.

>Going back to the server for 100kb of HTML and reloading the entire page...

This implies that 1) you don't go "back to the server" to load your bit of JSON. and 2) the JSON loaded doesn't require any extra templates, images or more JSON to be loaded. See the problem? It's all assumptions.

Another thing, what about browser caching? I can see how the next page loads _only_ the html, as all the js, css and images were loaded already. I think you are falling for the exaggerated speed benefits from making a website with a JS framework.

To be clear, I am talking about a web page, an HTML document, static content. Maybe that's where the confusion happens in discussions like this. (I said "sites", not "webapps" in my original comment)

A history lesson, we did this with Flash years ago (no more page refreshes!), and everyone ultimately learned to hate it. Just because the flashy crap is spread over the entire "webapp/site" to every button, mouseover and click doesn't mean it's useful or better. (I think many devs think they need to build basic site features with big frameworks just to "stay modern".) Look at Youtube, it's slower now that they implemented their "webapp" experience, but the page doesn't "refresh", so that is somehow better... (is youtube really a webapp? Or a bunch of pages with videos on them?)

<comment><AUTHOR> Ultimately, the proof is in the pudding. Which is faster, when you start navigating around?

* [https://news.ycombinator.com/item?id=16052558](https://news.ycombinator.com/item?id=16052558)

* [https://hn.svelte.technology/item/16052558](https://hn.svelte.technology/item/16052558)

Bear in mind that HN itself has a huge advantage over HN clones, yet — for me at least, sitting here — the Sapper version is significantly snappier.

<comment><USER6> Hi Rich. On my iPhone, I get a 3-second delay between when I "swipe to go back" and when the page is usable/scrollable on the Sapper HN. When I first went to the site, via the link above, the top nav links did not seem to work reliably, and it may have been the same 3-second delay, but I'm only getting now when swiping to go back — maybe because the page is being reloaded from the server? It's still quite a delay, though.

<comment><USER7> Interesting. I get behavior like that with twitter.com on the iPad. It hangs with a blank white page for a few seconds. I always wondered what kind of client script shenanigans were going with that. Using the back button embedded in the web page does not cause the same delay.

<comment><USER8> I get the same behavior on my phone with their new website too. Service worker infancy bugs?

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> Some bullet points are missing from the "perfect framework" list:

1\. SSR must support streaming

2\. SSR must work in a service worker (so in fact you have 3 targets: server, client/hydration, client/service worker)

3\. All work that can be offloaded to a WebWorker must be offloaded

4\. Navigating to subsequent pages must support prefetching, including dynamic data (Next.js doesn't even tell you how to do it)

5\. Navigating to subsequent pages SHOULD support prerendering (offscreen) where it makes sense, but…

6\. MUST support FLIP-style transitions[1].

Which does mean prerendering anyway for about 100ms at least so the layout can stabilize and cached images load into memory.

For long pages you need to split them into chunks/sections and only animate the part that gets shown (usually above fold).

[1] [http://www.pocketjavascript.com/blog/2015/11/23/introducing-...](http://www.pocketjavascript.com/blog/2015/11/23/introducing- pokedex-org)

<comment><AUTHOR> This is an excellent list, thank you. To answer some of the points:

Sapper supports partial streaming of server-rendered HTML (typically you'll get most of the  while it's fetching data for your page, unless there's no dynamic data in which case you get the whole lot instantly).

I'm not convinced there's actually a benefit to 'server' rendering in a service worker as opposed to serving a shell page. We have an issue for it though! ([https://github.com/sveltejs/sapper/issues/22](https://github.com/sveltejs/sapper/issues/22))

Sapper supports prefetching (including of dynamic data) of subsequent pages — just add rel=prefetch to  elements (we'll add a programmatic way to do this in future as well).

As for the rest, some of it is app-specific, some of it is stuff the framework could help with. We're not at version 1 yet, so bear with us :)

<comment><USER9> It should be "free" with the right architecture, and it should be faster, that's why I included it for the "perfect" framework list.

However, it's only a win on first page load on a subsequent visit. So definitely not a priority for an actual implementation.

BTW one easy way to implement this would be to flip the usual model:

1) Have service worker/server as main renderers

2) On navigation do a fetch to service worker and patch the page

So you're on /main, do fetch to /page2?from=state and get patching instructions.

If you could give the service worker readonly access to DOM without copying this wouldn't actually be that stupid.

It might be possible some day:

[https://github.com/whatwg/dom/issues/270](https://github.com/whatwg/dom/issues/270)

</comment></comment></comment><comment><USER10> As always, my main concern with this is traction. Will this be well supported, with a good community, 4 years down the line? I know React will, just because of the massive amounts of business depending on it. When building something real, i have to think about this because i need to be able to hire developers and actually develop my product instead of rewriting it.

That aside, the idea of svelte is cool, and i'm happy they're continuing to build on that. Excited to see what comes out of this!

<comment><USER11> Massive amounts of business were also built on Angular 1.x but it is no longer supported. To be honest, I am tiring of seeing a new javascript framework everyday. I am pretty sure I saw a post for something called StimulusJs in the last hour and now this.

<comment><USER12> Sorry, but that isn't correct. Angular 1.x had a release just over a week ago. 1.6.8 was released on December 21, 2017.

[https://code.angularjs.org](https://code.angularjs.org)

<comment><USER5> I think he is implying that since Angular 2 is out, 1 is guaranteed to be gone, and no longer supported in the future.

Who would intentionally use an older version of a framework, where the upgrade path breaks compatibility?

Angular 1.x is in essence, dead. It's just going to take a long time to go away.

</comment></comment></comment></comment><comment><USER13> I've been following Rich's work on Rollup, Svelte and now Sapper with interest and great awe. I truly believe he's onto something.

At the same time, if I were designing something like this, I'd use a tool like Flow or TypeScript in a heartbeat. Doing AOT optimization is so much easier when you have type guarantees, I'm sure that once you go deep enough you get into all kinds of little issues that are only issues because JS is both dynamic and very quirky.

Rich, if you're reading this, did you consider this and if so, why not?

<comment><AUTHOR> Thank you.

Svelte itself is written in TypeScript so I'm a believer. I'd like to get first-class support for TypeScript in components at some point. Adding .ts support for the non-component parts of a Sapper app should be fairly straightforward (it's just a webpack config after all) — will add that to the TODO list.

<comment><USER14> Curious, but since you're a TypeScript believer, and venturing into "build yet another JS framework", why not make it TypeScript-first or even TypeScript only?

Granted, you'd loose a large number of JS-only potential users, but seems like it'd be very differentiating (and unique?) to be TS-first, and market/specialize within the large niche of TS developers/teams.

Vs. the usual TS-last/TS-kinda-sorta approach that, again AFAICT, all the other JS frameworks take.

<comment><AUTHOR> Learning a new framework is intimidating enough without potentially having to learn a new language on top of it. I work in the news business, among people who in many cases learned the bare minimum of JavaScript necessary to visualise data and tell interactive stories, so that's my natural constituency — beginner-to-intermediate/casual programmers, most of whom don't even know what TypeScript is.

There are TS-first frameworks, such as Angular, and they're off-putting to people who just want to build something.

</comment></comment></comment></comment><comment><USER15> "While it's true that citing 'ecosystem' as the main reason to choose a tool is a sign that you're stuck on a local maximum, apt to be marooned by the rising waters of progress, it's still a major point in favour of incumbents."

Yet the article makes clear that React is working on implementing some similar technologies. Is there anything in svelte / sapper that cannot eventually be implemented in React / next.js too? I'm more than willing to wait a year for it to show up in React rather than live on the bleeding edge...

<comment><AUTHOR> So far, the React team's work is focused on optimising your app code using Prepack (kind of like Angular's AoT compilation, or similar forms of preparsing that have existed in other frameworks for a few years) — you still need React itself.

It's far from clear that it'll ever be possible to compile a React app to something that doesn't need virtual DOM reconciliation, with all that entails.

</comment></comment><comment><USER16> > the framework should do automatic code-splitting at the route level, and > support dynamic import(...) for more granular manual control

I disagree! Code-splitting is arguably an architectural dead-end for SPAs:

1) It adds a non-trivial layer of complexity to both your application logic and your tooling. SPAs (and the JS ecosystem in general) are already complicated enough without this extra layer of indirection, and that complexity carries a higher cost than most people realize, _especially_ when it's blindly accepted across the industry as best practice.

2) It's based on the conflation of _apps_ with _collections of hypertext documents_ , whereas in reality these are different architectures with different trade-offs. We're under no such delusions for apps in the app store for example, and thus nobody bats an eye if one takes a full minute to download.

I guess this isn't what people want to hear, but the web is more than apps, and we need to stop pushing SPA as the default way to build every new website. Code-splitting is merely the by-product of choosing the wrong architecture. In cases where SPA is the right tool for the job, we need to make users aware that they're downloading an _actual app_. I.e. a one-time install screen implemented via some kind of service-worker-driven bootstrapper: "Just a moment while we install your app..."

<comment><USER17> It's an interesting idea. From the case studies you'll find on the web, it looks like Progressive Web Apps want to play minimal bootstrap time as as card against native apps, but it's true that re-use of existing web know-how could be enough arguments in their, although native app developers are getting almost as easy to find as web developers these days.

</comment></comment><comment><USER18> Isomorphic frameworks are a bad idea. I'm convinced that any attempt at making a single general-purpose web application framework will fail. I've seen it happen too many times before.

SocketStream, Derby, and even MeteorJS which had massive funding and marketing just couldn't do it. NextJS is just the next generation of fools who didn't research the market... Surely we can at least wait for NextJS to go belly up before launching yet another project that's going to waste several more lifetimes of human effort.

There was nothing wrong with the implementation of the MeteorJS project by the way... The problem was the idea itself. All the marketing and funding it received only served to delay its inevitable demise.

<comment><USER17> From what I've gathered, both Next.js and Sapper.js are less ambitious than Meteor and Derby. They require to write your own data access code by hand, by making HTTP requests or importing whatever server-side JavaScript libraries you need, while Meteor and Derby tried to provide the same model API on the server and on the client. Maybe the model API (and the fact that you were almost forced into storing everything in MongoDB) was the greatest limitation.

<comment><USER19> THIS.

</comment></comment></comment><comment><USER20> If the "compiler as framework" idea sounds interesting to you, and you don't mind a little Scala, this paper might also be of interest to you: [https://www.google.co.uk/url?sa=t&rct=j&q=&esrc=s&source=web...](https://www.google.co.uk/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0ahUKEwiA6PvX2bnYAhULb1AKHaABCYgQFggoMAA&url=http%3A%2F%2Fspiral.ece.cmu.edu%3A8080%2Fpub- spiral%2Fpubfile%2Fpaper_284.pdf&usg=AOvVaw3yPlVCT73I81zdV7vNmkVJ)

<comment><USER21> "compiler as framework"

This really does sound like we're slowly reinventing lisp

</comment></comment><comment><USER22> Curious: why use Webpack rather than your own and IMHO much superior bundler, Rollup?

I'm excited to try this more but I have mixed feelings about Svelte. The concept is brilliant but I feel like there's too much API and some weird gotchas. I hope there'll be an effort to simplify it if possible.

<comment><AUTHOR> It uses code-splitting, dynamic imports and hot module reloading, which are all well supported in webpack. We definitely plan to support Rollup as well, once it has those features — it should be possible to shrink down JS payloads by a reasonable amount. (Maybe Parcel too, eventually.)

I think the 'too much API' feelings might be more unfamiliarity than anything. The API surface area is _much_ smaller than anything like Angular, Vue etc, and although it's a fundamentally different approach to React I'd argue Svelte has a much shallower learning curve there as well. We're very open to feedback and suggestions though!

<comment><USER22> Maybe it's just the documentation that is lacking, but when I've played with Svelte, the API and template syntax feels like a hodgepodge of special cases.

For example, what exactly does a tag starting with colon mean? Is it just arbitrary syntax for things that don't fit in? What does a colon in an attribute mean? (i.e., why on:click rather than onclick or onClick or even something simpler like :onClick?) Why is there both {{#if condition}}
Content
{{/if}} and {{{condition && '
Content
'}}}? I feel like all these different concepts break the "it's just HTML" promise, when it seems like it could be simplified a lot.

Yes, JSX has similar gotchas, but at least it has references and specifications.

And what's up with the crazy semantics of computed properties?

Sorry if this sounds negative, but these have been genuine problems for me in getting a hang of Svelte.

<comment><AUTHOR> Colons indicate that something is a _directive_ rather than an attribute — so `on:click` is the `on` directive with the `click` event, and `bind:thing` is the `bind` directive with the `thing` data property. The one place we violate that slightly is with `:foo`, which is shorthand for `foo={{foo}}` (since people dislike the ceremony of passing props down between components, and this makes it easier).

{{#if condition}}...{{/if}} tells Svelte something about the structure of your app. {{{condition && '
Content
'}}} doesn't, and you can't add interactivity to the
 if it's just a string. Moreover, if `condition` is `undefined`, then that's the string that will get rendered to the DOM. Generally, {{{triples}}} should be used for blobs of HTML you get from data sources, such as a blog post.

If you can overcome your distaste for the computed property dependency injection, you'll hopefully find it's an extremely easy and compact syntax for declaring arbitrarily complex graphs of properties. The advantage of doing it this way is that Svelte can generate, at compile time, very efficient code for updating computed properties without any wasteful runtime dependency tracking. I realise it's slightly controversial (because it's a Svelte idiom, rather than something in JS itself), but for those who have embraced them, computed properties are one of the best features of Svelte!

<comment><USER22> The problem with Svelte's computed properties is that it's not just an idiom, but a completely new language that happens to look like JS. It does things JS can't, and breaks very basic things like functional composition.

Why not simply use the "correct" ES6 syntax to do the same thing? It's almost identical:

      computed: {
        hours: ({time}) => time.getHours(),
        minutes: ({time}) => time.getMinutes(),
        seconds: ({time}) => time.getSeconds()
      }

This way, the compiler could simply optimise idiomatic cases where it's easy to see which data is depended on, without breaking the language.

<comment><AUTHOR> Interesting idea! I've raised an issue, thanks — [https://github.com/sveltejs/svelte/issues/1069](https://github.com/sveltejs/svelte/issues/1069)

</comment></comment></comment></comment></comment></comment><comment><USER23> What I don't get in all these frameworks is the desire to invent new and incompatible template languages with increasingly inane syntaxes. Oh. And, of course, with stringly-typed programming and magic binding rules.

Just look at Svelte's templates: [https://svelte.technology/guide#template- syntax](https://svelte.technology/guide#template-syntax)

Not only it's some custom implementation, it also breaks all assumptions about _javascript_ code

       const counter = new Counter({
          data: {
            count: 99
          }
       });

       ...then {{count}}, or counter.get('count')

Why is it `counter.get('count')`? WTF?

Or just the section on computed properties[1]: oh, it's no longer even Javascript. It's some magic Javascript-like scripting language that gets injected with properties based on what you write.

Much like in Vue data, properties, and methods are magically hoisted up to the object breaking everything you learned about Javascript:

      export default {
        methods: {
          say: function ( message ) {
            alert( message ); // again, please don't do this
          }
        }
      };

      // and then

      import MyComponent from './MyComponent.html';

      var component = new MyComponent({
        target: document.querySelector( 'main' )
      });

      component.say( '' );

Why the hell is `.say` a top-level method now?

And so on and so forth.

[1] [https://svelte.technology/guide#computed- properties](https://svelte.technology/guide#computed-properties)

<comment> purple-again I'm not an expert can I can chime in and say that .get and .set are common in Ember data objects as well. No idea if it's an ES6 thing or Ember thing though.

<comment><USER24> Those are Ember-specific, because ES getters and setters weren't widely available at the time of introduction. They just dropped < IE 11 though so they'll start to go away.

</comment></comment></comment><comment><USER25> I think the major missing principle on this list is "streaming." (This is missing in Next, too.)

The server should send down parts of the page as soon as their data becomes available. Typically, pages have a "header" section that requires no data at all, and the server should render it instantly and stream it to the client. Then there's typically some fast-loading "above-the-fold" data; the server should render and stream that as soon as it's ready. Beyond that, there's other below-the-fold components, which may load/render more slowly. The server should render those as they come in.

Then, the magic technique is to progressively attach event listeners to components as they stream in, so you don't have to wait for the whole page to load to be able to interact with above-the-fold components.

<comment><AUTHOR> Sapper supports partial streaming if you have data that needs to be loaded asynchronously (i.e. you'll get most of the  immediately, then other stuff later), but it doesn't currently do what you suggest (such as loading a  while  is pending). That's something that we intend to tackle in future, though _hydrating_ pages with async data dependencies is a hard problem.

</comment></comment><comment><USER26> How the fuck something that is in early development advertises as military grade!

<comment><USER27> Getting new technologies to gain traction is not easy - regardless of their technical merit. I do admire the framework designer's P.T. Barnum like showmanship. He's got it down to a science.

</comment></comment><comment><USER28> Now add to this the ability to write native apps on the iPhone and Android and I'm sold.

</comment><comment><USER29> Question:

> 1\. It should do server-side rendering, for fast initial loads and no > caveats around SEO

Is server-side rendering still an issue for SEO? Don't major search engines evaluate pages now so that SPAs can be indexed?

<comment><USER30> I can confirm that Google can crawl SPA's like any other page. But do note that they crawl using Chrome 41 (!) so make sure you have sufficient polyfills in place.

This also applies for AdWords, it drove me mad when Google kept insisting my site was not reachable, even though it was.

Only after installing a client-side exception tracking tool (like raygun or errorception) I found out the page was not rendering on the 'old' browser Goolge uses internally.

</comment></comment><comment><USER31> Hey Rich, your hackernews clone doesn't perform all that well globally

[https://testmysite.io/5a4c2cdf819876444fa127b5/hn.svelte.tec...](https://testmysite.io/5a4c2cdf819876444fa127b5/hn.svelte.technology)

I really like Svelte! But I don't even serve my content from Express middleware anymore due to the above problem.

I just feel like you're under-estimating a developer's resourcefulness to make the content that actually _is_ static a static page, and also over-estimating the number of new, traditional client/server web apps (at least by people who are probably in your target audience).

Static performance is hard to beat _especially_ globally and there's a clear performance degradation once you get away from the epicenter. Believe it or not Svelte.technology's landing page actually performs noticeably more poorly coast to coast in the US (>2x worse to load in California than NY--150ms vs 500ms).

I'm not saying give up or anything, just saying it might be a good idea to talk to more JAMStack people :)

<comment><AUTHOR> This is more of an ops thing than a framework thing. If you're making a purely static app, JAMStack is great. Sapper is solving a different problem.

Having said that, we will eventually add the ability to 'export' a purely static site that can be deployed to services like Netlify. Next.js has this, but they didn't launch with it either. Bear with us!

</comment></comment><comment><USER32> Is there any way to use Sapper.js with React, Vue or anything framework? I find the premise behind Sapper interesting, but I just don't see the appeal of Svelte, where they are basically reinventing HTML syntax.

<comment><AUTHOR> Svelte _is_ the premise behind Sapper. If you want to use React, use Next; if you want to use Vue, use Nuxt; if you want that 7kb Hello World (instead of Next's 204kb or Nuxt's 175kb) then you have to adopt a more efficient approach.

We're not reinventing HTML, we're _using_ HTML. And CSS. ('Reinventing HTML' is a far more fitting description of JSX, and then there's CSS-in-JS...)

Doing so is what allows us to statically analyse your app and compile it to a) a tiny client-side JS payload, and b) an incredibly efficient server-side renderer.

</comment></comment><comment><USER33> If you can "customise every aspect of the system" why does he spend a whole paragraph complaining about people who like JSX? Shouldn't the answer be, "and you can use JSX if you want"?

</comment><comment><USER34> "This framework is 95% ideal, let's build another framework for my personal 5%."

This attitude is why we have a hundred different relevant frameworks right now. How about instead of a building a new framework, you contribute to an existing one? You even say that Next is close to what you want... why not help to make it better?

Relevant song about this issue: [https://www.youtube.com/watch?v=Wm2h0cbvsw8](https://www.youtube.com/watch?v=Wm2h0cbvsw8)

<comment><USER35> Because then we'd all still be using an improved Angular, or even something earlier. If that's what you want then you're welcome to make that happen for yourself.

</comment></comment><comment><USER36> Sounds interesting. He mentions that his gzipped size for the RealWorld project is about 40KB. There was a good comparison done with this project[0] in which one of the frameworks (AppRun) weighed in at 19KB. 19KB is pretty crazy. Has anyone here used AppRun?

[0] [https://medium.freecodecamp.org/a-real-world-comparison- of-f...](https://medium.freecodecamp.org/a-real-world-comparison-of-front-end- frameworks-with-benchmarks-e1cb62fd526c)

</comment><comment><USER37> Why on earth would I give a shit about SEO for a web application? The SEO is for the brochure site that leads people toward the webapp, not the webapp itself...

</comment><comment><USER38> "Compiler as framework" seems like a really terrible unifying vision — a far more interesting framing I think would be "type system as framework". It's the difference between "this app is assembled by cobbling together a bunch of random domain specific syntaxes" and "this app was assembled by combining together resources with different well-defined, well-enforced constraints."

<comment><USER39> I'm having trouble visualising what you're hinting at. How do DSLs relate to static typing? Are you referring to writing all code in the same language (as in JSX + JSS)?

</comment></comment><comment><USER27> I've used many web frameworks over the years and I really wanted to like this Sapper technology, but for the life of me I just don't understand what problem it's trying to solve. Can someone give me a comparison of what comparable technologies it is replacing?

<comment><USER19> There isn't really anything comparable. Really. It doesn't include the framework in the end build. It's only in the original source. So it's a compiler, not really a framework, that compiles to code that's performant to specific tasks.

</comment></comment><comment><USER40> One of the authors of Next.js here. I want to clarify that all the points against Next.js are virtues! They probably just arise from Rich not being so familiar with it (or not having looked at the examples/ directory extensively: [https://github.com/zeit/next.js/tree/canary/examples](https://github.com/zeit/next.js/tree/canary/examples))

1\. I think this point is trying to say that we don't have special "mask files" inside `pages/`, which is an idea worth exploring. Right now, Next.js instead gives you full flexibility on how you want to match the routes on your server (as it should be). For example, `your-domain.com/xyz` can even first perform a database query before deciding what page to render it with (if any).

2\. What the author points out as a weakness here is that you can handle server things directly in your server code (`server.js` using micro or express for example). That sounds like the right thing to do to me, and if you don't want that, you still can do something like:

      // pages/my-server-page-only.js
      export default ({ req, res }) => res.end('hi')

3\. "To use the client-side router, links can't be standard  tags." This is by design. Magically overloading `<a>` to add client-specific behavior sounds like the days of jQuery or TurboLinks. If you want client-side behavior, wrap `<a>` in the higher-order `<Link>` component. There also very important properties of the `<Link>` like `<Link prefetch>` that are simply not part of the `<a>` standard definition.

Also noteworthy: the entire ZEIT Documentation is written in Markdown with React components. It's open source: [https://github.com/zeit/docs](https://github.com/zeit/docs)

On size: the Next.js and React teams are both working towards really interesting solutions to ship only the code that's necessary, without resorting to templating as the main strategy. Our team actually spends more time on the 'compiler' parts of Next.js than the 'framework API' parts. (the API has barely changed since the initial 0.1 release in fact).

Additionally, since Next.js uses React as peer dependencies, you'll also get to do `yarn add next react react-dom-lite` [https://github.com/jquense/react- dom-lite](https://github.com/jquense/react-dom-lite) in the future.

Overall, I think Sapper is an excellent framework for Svelte users. I'm looking forward to seeing more Next.js-like frameworks.

For Vue users: check out [https://nuxtjs.org/](https://nuxtjs.org/)!

<comment><AUTHOR> Thanks Guillermo. I hope the respect and appreciation I have for the Next team came across in the post.

My criticisms aren't based on misunderstandings, however. Route masking provides flexibility but it really _does_ undermine the ability to navigate a complex app structure — Nuxt.js evidently reached the same conclusion, because they too have dynamic route parameters encoded in filenames.

The my-server-page-only.js results in a 'Cannot read property 'end' of undefined' error for me, because it seems Next can't distinguish between universal and server-only routes. If you have any examples of this working, please do share them!

The Markdown ZEIT documentation is cool, but doesn't really address the problem I was getting at with <Link>, which is that your content is likely to come from a database. (Incidentally, Sapper does provide support for , which works exactly the same as <Link prefetch>.)

> On size: the Next.js and React teams are both working towards really > interesting solutions to ship only the code that's necessary, without > resorting to templating as the main strategy.

I'm excited to see where that takes us. My conviction remains that templates will always provide more and deeper optimisation possibilities than JSX, but this is a competition in which ultimately we're all winners.

<comment><USER41> > Nuxt.js evidently reached the same conclusion, because they too have dynamic > route parameters encoded in filenames.

nuxt.js applications don't need to rely on filenames for routing. there's a handy nuxt module for this -- [https://github.com/nuxt-community/router- module](https://github.com/nuxt-community/router-module)

</comment></comment></comment><comment><USER42> ITT: a complete misunderstanding of how a universal JS web app works.

<comment><USER43> Agreed. As a JS app developer I now feel more confident about my job security.

</comment></comment><comment><USER44> Why dont you guys use laravel when you need better SEO and server side rendering? It is fast, easy to learn, easy to deploy, etc.

</comment><comment><USER45> Could webpack be replaced with something else? IMO webpack is a giant mess.

<comment><USER19> Have you had a look at Rollup.js (incidentally by the author of Sapper).

</comment></comment><comment><USER46> Is there a reason why most Javascript web frameworks, like this one, tend to ignore relational databases?

hmm, I don't even see a mention of how to integrate any datastore with Sapper or did I miss something?

<comment><USER24> > Is there a reason why most Javascript web frameworks, like this one, tend to > ignore relational databases?

Yes, because these are frontend frameworks and that is a backend concern.

<comment><USER46> I could be wrong, but this doesn't look like a front end framework.

</comment></comment></comment><comment><USER47> An ideal web app framework would not be in JavaScript...

<comment><USER48> Do you have any other frameworks in mind? Ones that easily and concisely hook into the DOM APIs provided by browsers? One that hot reloads in dev? Or maybe just accomplishes even a handful of the 11 targets listed at the beginning of the article?

Because I don't know of any. Except maybe the new Rust framework, Yew. Which seems very interesting.

<comment><USER49> Perhaps you're right, there may not be one. However, I think the point the OP is trying to make is that JavaScript is a shitty language and it would be better to invest some effort in replacing it with something better than to continuously try to "fix" all its inherent shitty-ness over and over again to little avail. Sure, JavaScript isn't as shitty today as it was 10 years ago, but it still isn't a well-thought-out, well-designed, or consistent language.

For examples of JavaScript's shitty-ness, I'd point to its various function declaration styles and their disparate effects on the code you write, its wishy-washy scoping, namespacing, the number type's precision problem, NaN being a number type, the ambiguity of _this_ , just to name a few.

<comment><USER47> yes. well put

</comment></comment></comment></comment><comment><USER50> How many of you actually built a React/Redux stack SPA that actually came anywhere near what Sapper offers?

The file size problem is underrated. Not everybody walks around with 5G like in South Korea. Not everybody has the latest and greatest Samsung or Apple phone.

It's a big problem when you advertise PWA as quick and fast but then in tiny letters mention its using the best case on best network and best phone. If you design without worst case in mind, you've discriminated people based on whether they can afford the best or not.

The vast majority of users don't. It's only recently that Android phones have gotten cheap that its seeing widespread usage. These people are not going to wait around for the React/Redux stack to load AND still wait on more data coming through their 2g/3g connection. Oh, and there's slow rendering on older Android phones and now you have a laggy Javascript app experience that Lighthouse tells you everything is okay.

Let's not be so quick to judge. It's not as if Sapper has deviated from the trend that even React team is acknowledging. This is a fresh approach to a quickly monopolizing space, from an organization that has other agendas in seeing their tech stack flourish.

I'm gonna definitely be watching Sapper.js in 2018 and if they deliver on most of the 11 criterias, I know my customers and their customers will be happy.

<comment><USER51> You can boil down react to virtually nothing. preact-compat turns it into 4kb. Redux + router don't add _that_ much. The loading impact, if you watch out, code split, isn't the dire problem.

As for laggy experience, Fiber is the only feasible attempt at the moment to actually tackle it. Microbenchmarks will not help and neither Svelte nor anything else will make a webapp fast on a slow phone as baseline diffing has never been the problem in the first place. The problem is and has been the dom and the single threaded handling of it.

Fiber will allow apps to schedule. Imagine an app with 100.015 rows that Svelte renders in, say, 500ms, let it be 10ms faster than React 15's 510ms. It would still eat into your frame budget and cause heavy jank _like all web apps do_. Fiber just wouldn't render the 100.000 rows that don't fit your phones screen finishing the whole op under a single ms. It culls and prioritizes similar to how virtual lists operate in general, but you get that as a _first class primitive_ being able to defer any render call of lesser importance without causing visual distortion or code complexity.

Not to mention that with React you could actually produce a real native app, while redux would allow you to share most of your code. With something like react-native-web you could even write a universal app being able to render both in the web and natively.

<comment><USER52> > Imagine an app with 100.015 rows

i can imagine an app like this. and such an app would have been designed with 0 thought given to the actual usability by humans. the _proper_ solution is to provide sorting, grouping, filtering and pagination. your UIs should be small enough to remain fast without insane optimization tricks. mobile and even desktop browsers are plenty slow at rendering/reflowing 100k DOM nodes; the fastest way to render this is simply not to.

it's not as if suddenly you don't have to worry about the shitty UX and performance of your app's architecture "because fiber".

<comment><USER51> The list is an example, the cheapest one to make it understandable. Let it be 2000, or 100, filtered and pre-processed. It would still take longer than the 15 the user actually sees. The point isn't the list, but the primitive.

I don't even know where the scepticism comes from, culling and priotization is normal on the desktop. You've been offloading UI related tasks that could interrupt animations or interactions in C# forever - it is a great tool to have and getting it for the web is a major step. Microbenchmarks that measure baseline deletes/adds/changes will simply not result in apps that feel native. Thinking framework xyz will just feel acceptable to mobile users because Krausest says it takes 1ms less adding 100.000 rows, that is just silly.

<comment><USER53> I would think that some combination of sorting, grouping, filtering and pagination would still make for a more user-friendly experience.

<comment><USER51> I don't think there's anything more user unfriendly and annoying than pagination. Pull/click/scroll to load have been made to help it. But that aside, the list isn't important. It could be dialog items, complex tree-views, plugins, graphs, visuals in general, etc.</comment></comment></comment></comment></comment></comment>


Show HN: PHP serialization/deserialization library in Go - <AUTHOR> https://github.com/lazyfunctor/gophpcereal <comment><AUTHOR> I have been learning Golang in my free time, this a toy project that I tried my hands on.</comment>


Convert shortcomings into advantages without lying - <AUTHOR> http://blog.asmartbear.com/blog/convert-shortcomings-into-advantages-without-lying.html <comment><USER2> Nice article. Mild tangent: Salesmanship is great, but I get kind of sick of it in a hurry. I went to a new gym (Equinox in Los Angeles) for the first time last night, worked out on a guest pass with my friend, and then went into a sales office and said, "We've got a dinner reservation for steak really soon, can you give me your rate card and best specials?" I then took notes on the ratecard about what he offered. So now, I've got their baseline rates which almost any gym will come off of/throw some freebies along with, and I didn't have to hear, "Well, yes, our joining fee is $500, but please remember that our gym is... clean... has whirlpools... the finest equipment, blah blah blah." Hooray for being in a hurry so as to get numbers instead of pitch.

<comment><USER3> I'll remember that trick. thanks</comment></comment>


Beyond grep, Ack: a better grep, for programmers - <AUTHOR> http://beyondgrep.com/ <comment><USER2> I use something like this which i wrote myself years ago, but i still use it every day. My version is called qgrep (for quick grep).

It does this:

* knows which files are source code and which are not * ignores tmp files like _~ and #_ * automatic recursive search.

Some differences from ACK which i still want,

* can be given a filename pattern and can glob within each directory. * can search binary files too! * doesn't do regexp at all!

> why? regexp is much slower than straight string search if using something > like Boyer-Moore-Galil, and this is _important_ when you're searching > massive subtrees of files.

For regexp, I'll use grep with its fancy options. For straight, find this string in all my code, I'll use qgrep.

For those linker undefined, mangled functions, it's great to qgrep the .o files and .libs.

</comment><comment><USER3> I must be getting old. I dread the idea of learning a new, complex command- line option set.

<comment><USER4> Don't worry. The most common switches are the same between ack and grep:

        -i, --ignore-case
        -v, --invert-match
        -w, --word-regexp
        -l, --files-with-matches
        -L, --files-without-matches
        -o
        -m, --max-count=NUM
        -H, --with-filename
        -h, --no-filename
        -c, --count
        -A NUM, --after-context=NUM
        -B NUM, --before-context=NUM
        -C [NUM], --context[=NUM]</comment></comment>


Who's using Docker? - <AUTHOR> http://opensource.com/business/14/7/docker-through-hype

<comment><USER2> I work for a large enterprise company and we're using Docker in our Continuous Integration environment to unit test components needing to run on an application server. We have an eye to using Docker to manage production migration - ultimately we want to be migrating containers into production rather than software. We're not there yet, but we're working on it.</comment>


Steve Jobs "never had any designs. He has not designed a single project" - <AUTHOR> http://reprog.wordpress.com/2010/09/06/steve-jobs-never-had-any-designs-he-has-not-designed-a-single-project/ <comment><USER2> Steve may not design the product, but he is the hard-grain sandpaper that gets a design from prototype to best in market.

Ars says it best:

"On his own, Jobs could not create much of anything. But that's not his superpower . .. He is Apple's übercritic: one man to pare a torrent of creativity and expertise down to a handful of truly great products by picking apart every prototype, challenging every idea, and finding the flaws that no one else can see."

[http://arstechnica.com/staff/fatbits/2009/05/hypercritical.a...](http://arstechnica.com/staff/fatbits/2009/05/hypercritical.ars/2)

Further reading on this process in action - Steve's take on the Segway design:

[http://tech.fortune.cnn.com/2008/07/07/behind-the-scenes- ste...](http://tech.fortune.cnn.com/2008/07/07/behind-the-scenes-steve-jobs- meets-the-segway/)

<comment><USER3> I actually had dinner with a well-known hedge fund manager a few months ago and while talking about Blackberries and iPhones, he mentioned "that nobody has ever got rich betting against Steve Jobs"

Sums it up for me pretty well.

<comment><USER4> Bill Gates rather puts the lie to that.

<comment><USER5> He does? How?

Microsoft was happy to place bets on every system they could. Bill Gates didn't bet against anyone. He placed lots of bets on lots of systems, knowing that one would work out. The IBM PC is what made their fortune. But the bets they placed on other systems were already doing very well for them. Including on Apple.

The Microsoft-Apple relationship began in 1977 with Microsoft introducing Applesoft BASIC and later licensing it to Apple. Microsoft SoftCard followed in 1980, enabling Apple machines to run to programs designed for the CP/M. Sure, there was the infamous MS-DOS deal with IBM. But in the same time period Steve Jobs visited Microsoft to demo early prototypes of the Macintosh, and Microsoft was the first major company to develop programs for the Mac. In the end Microsoft BASIC and Microsoft Multiplan were shipped simultaneously with the introduction of the Macintosh, and Microsoft announced at the launch that Word, Chart, and File would ship soon.

When I look back at the history, I see no sign that Bill Gates was betting against Steve Jobs. His most successful bet was not on Steve Jobs. But he had lots of bets on Jobs as well.

For more on the history, see [http://www.thocp.net/companies/microsoft/microsoft_company.h...](http://www.thocp.net/companies/microsoft/microsoft_company.htm)

<comment><USER6> Early on, before a leader in the PC market was established, investors had the choice of betting which horse would win--Bill Gates at Microsoft or Steve Jobs at Apple.

Many people did get rich betting on Gates, so indirectly, yes, Bill Gates does show that people have gotten rich betting against Jobs. The hyperbole is nice, but only that--hyperbole.

<comment><USER7> Isn't that choice a false dichotomy? A bet on Gates is not a bet against Jobs.

An investor who could only envisage one winner may be a little naive. It's not a horse race.

<comment><USER8> _A bet on Gates is not a bet against Jobs._

Yes it was.

<http://en.wikipedia.org/wiki/Macintosh>

"The first Macintosh was introduced on January 24, 1984; it was the first commercially successful personal computer to feature a mouse and a graphical user interface rather than a command-line interface. The company continued to have success through the second half of the 1980s, only to see it dissipate in the 1990s as the personal computer market shifted towards IBM PC compatible machines running MS-DOS and Microsoft Windows."

<comment><USER7> So, when Gates bought 150M of Apple stock in 97, was he betting against himself? Worked out to be a winning bet for Gates.

As Jobs said at the time: "We have to let go of a few notions here. We have to let go of the notion that for Apple to win, Microsoft needs to lose."

<comment><USER8> _So, when Gates bought 150M of Apple stock in 97, was he betting against himself?_

Pretty much, yes. It made him seem like less of a monopolist.

 _Worked out to be a winning bet for Gates._

That's what happens when you bet on every horse in the race. It's something that Microsoft does a lot.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> The fact is, the Macintosh was nowhere near completion when Jobs took it over and shepherded it there himself. The whole Raskin/Jobs controversy smells like 30 year old corporate politics, nothing deeper than that.

Some potentially relevant folklore.org bits: [http://www.folklore.org/StoryView.py?project=Macintosh&s...](http://www.folklore.org/StoryView.py?project=Macintosh&story=I_Invented_Burrell.txt&characters=Jef%20Raskin&sortOrder=Sort%20by%20Date&detail=medium)

[http://www.folklore.org/StoryView.py?project=Macintosh&s...](http://www.folklore.org/StoryView.py?project=Macintosh&story=The_Father_of_The_Macintosh.txt&characters=Jef%20Raskin&sortOrder=Sort%20by%20Date&detail=medium)

<comment><USER10> Note that Jef Raskin actually disputes both those accounts himself in the comments sections.

<comment><USER11> Which just reinforces the "it's 30-year old corporate politics full of 'he- said, she-said'" perception.

</comment></comment></comment><comment><USER12> Wozniak's all-planet engineering skill and user empathy is the cornerstone of everything that came afterward. To this day I cannot understand why the prototypical managerial leech that is Jobs, however good his taste, is venerated over Woz. By technical folk, of all people.

<comment><USER13> The figurehead gets the glory. As a RULE.

Lance Armstrong is the Man Who Went to the Moon. We remember him, Buzz Aldrin, and the Presidents who got us there. Nobody else- not a one of the architects and engineers or anybody else.

<comment><USER14> I don't know how to tell you this, but...I think you meant Neil Armstrong.

<comment><USER13> Wow, I feel stupid.

<comment><USER15> It happens to us all, just laugh, smile and move on :)

</comment></comment></comment></comment></comment><comment><USER16> FWIW, Paul Lutus is calling this accurate over on reddit:

[http://www.reddit.com/r/programming/comments/daabf/steve_job...](http://www.reddit.com/r/programming/comments/daabf/steve_jobs_never_had_any_designs_he_has_not/c0yq1lf)

</comment><comment><USER17> Woz' interview in _Founders At Work_ seems to confirm that Jobs played a major part in many design decisions on the initial Macintosh, especially the removal of extension slots:

 _We had a real argument over slots. (...) Steve said, "All people really need is a printer and a modem." And that was just false because he'd come from a different world than I. (...) He wanted just one slot for a printer and one for a modem(...), so I said, "If you want 2 slots, get another computer." That was the only time we had a real argument._

<http://www.foundersatwork.com/steve-wozniak.html>

</comment><comment><USER10> It would seem his opinion only got worse with time:

[http://www.azarask.in/blog/post/macintosh-project-genesis- an...](http://www.azarask.in/blog/post/macintosh-project-genesis-and- history-16-feb-1981/)

His mid-90s annotations retract things he thought politic to say in the 80s.

</comment><comment><USER18> At the end of the article it was revealed that that Raskin quote was made 24 years ago. Whether it was true then or not, it's certainly possible that Jobs has designed, or contributed to the design, of _something_ at Apple in the 24 years since. Just a wee bit of a possibility there.

<comment><AUTHOR> Actually, that was revealed at the _beginning_ of the article: "It was published in 1986".

</comment></comment><comment><USER19> "[..] The next afternoon, instead of a new iteration of the calculator, Chris unveiled his new approach, which he called "the Steve Jobs Roll Your Own Calculator Construction Set". Every decision regarding graphical attributes of the calculator were parameterized by pull-down menus. You could select line thicknesses, button sizes, background patterns, etc.

Steve took a look at the new program, and immediately started fiddling with the parameters. After trying out alternatives for ten minutes or so, he settled on something that he liked. When I implemented the calculator UI (Donn Denman did the math semantics) for real a few months later, I used Steve's design, and it remained the standard calculator on the Macintosh for many years, all the way up through OS 9."

via: [http://folklore.org/StoryView.py?project=Macintosh&story...](http://folklore.org/StoryView.py?project=Macintosh&story=Calculator_Construction_Set.txt)

</comment><comment><USER20> Title is hardly a surprise. What did you expect? Will we next learn he never implemented a single NS_* class?

<comment><USER21> JOBS CREATED INTERFACE BUILDER IN 20,000 LINES OF ASSEMBLY HOW DARE YOU

He also wrote the entirety of the NeXTSTEP developer docs on scrolls in his kitchen.

Despite the abstract level where Jobs usually lives, it's interesting to note just what a hardon he had for OOP back in the day:

"With our technology, with objects, literally three people in a garage can blow away what 200 people at Microsoft can do. Literally can blow it away. Corporate America has a need that is so huge and can save them so much money, or make them so much money, or cost them so much money if they miss it, that they are going to fuel the object revolution."

<http://www.landsnail.com/apple/local/jobs_rs1994/jobs.html>

With his usual flair, he almost implies in the quote that NeXT invented OOP altogether.

Jobs seems to have a nose for the things that matter. Especially meaningful stuff that would escape most traditional business guys.

<comment><USER22> According to Wikipedia[1] Inteface Builder was invented and developed by Jean- Marie Hullot, originally _in Lisp_.

[1] <http://en.wikipedia.org/wiki/Interface_Builder#History>

<comment><USER23> Hell, it was probably originally _in French_ , too.

<comment><USER22> Only the functional specifications.

</comment></comment></comment></comment></comment><comment><USER24> "He has not designed a single project" is a bit of a strawman argument. What Jobs does is focus a team of designers and engineers on creating a product that is really satisfying to use. It doesn't sound like much, but if it's easy, how come no company but Apple seems to be able to do it?

Anyway here is a Mac application that applies some of Jef Raskin's ideas to a finder alternative: <http://www.raskinformac.com/>

<comment><USER25> Raskin said that as a response to Jobs' claim that (quoting from memory) "I feel I still have a couple good designs in me." It's unfortunate that the article omits this bit of context from the original interview in Programmers at Work.

He's not saying that Jobs is without merit, just that he steals credit from those to whom it rightfully belongs.

</comment></comment><comment><USER26> folklore.org paints a pretty interesting picture of Jef Raskin, and one which indicates his words should be carefully weighted and not taken at any more face value than those of Jobs.

For instance:

> Whatever idea that you came up with, Jef Raskin had a tendency to claim that > he invented it at some earlier point.

folklore also shows Jobs's contribution very differently than Raskin's own take:

> The plan of record for the Macintosh industrial design was still the one > conceived by Jef Raskin, which chose a horizontally oriented, lunch-box type > shape, with the keyboard folding up into the lid of the computer for easy > transportability, kind of like the Osborne I, which we weren't aware of at > the time. But Steve had a real passion for industrial design, and he never > seriously considered following Jef's recommendations.

As well as complete and utter disagreement with what was apparently written by Raskin, behold from ZeroGravitas's link:

> The elimination of slots had been dictated by Jobs, however I thought this > would hamstring the product. Thus I invented the all-important bus > diagnostic port discussed below

Whereas on folklore.org:

> But Jef Raskin had a very different point of view. He thought that slots > were inherently complex, and were one of the obstacles holding back personal > computers from reaching a wider audience. He thought that hardware > expandability made it more difficult for third party software writers since > they couldn't rely on the consistency of the underlying hardware. His > Macintosh vision had Apple cranking out millions of identical, easy to use, > low cost appliance computers and since hardware expandability would add > significant cost and complexity it was therefore avoided.

> Apple's other co-founder, Steve Jobs, didn't agree with Jef about many > things, but they both felt the same way about hardware expandability: it was > a bug instead of a feature. Steve was reportedly against having slots in the > Apple II back in the days of yore, and felt even stronger about slots for > the Mac. He decreed that the Macintosh would remain perpetually bereft of > slots, enclosed in a tightly sealed case, with only the limited > expandability of the two serial ports.

> Mac hardware designer Burrell Smith and his assistant Brian Howard > understood Steve's rationale, but they felt differently about the proper > course of action. Burrell had already watched the Macintosh's hopelessly > optimistic schedule start to slip indefinitely, and he was unable to predict > when the Mac's pioneering software would be finished, if ever. He was afraid > that Moore's Law would make his delayed hardware obsolete before it ever > came to market. He thought it was prudent to build in as much flexibility as > possible, as long as it didn't cost too much.

> Burrell decided to add a single, simple slot to his Macintosh design, which > made the processor's bus accessible to peripherals, that wouldn't cost very > much, especially if it wasn't used. He worked out the details and proposed > it at the weekly staff meeting, but Steve immediately nixed his proposal, > stating that there was no way that the Mac would even have a single slot.

<comment><USER3> Also good to note is Andy Hertzfeld's account of "Black Wednesday" in February 1981 when Raskin was fired and Hertzfeld given his desk.

The book was published in 1986, which would probably mean that the interview was done after he was fired by Jobs. Certainly reinforces the warning to take Raskin's word, too, with a grain of salt.

[http://folklore.org/StoryView.py?project=Macintosh&story...](http://folklore.org/StoryView.py?project=Macintosh&story=Black_Wednesday.txt&sortOrder=Sort+by+Date)

</comment></comment><comment><USER27> Steve Jobs having nothing to do with the original Macintosh doesn't imply that Steve Jobs' aesthetic sense didn't result in Apple's resurgence.

It might imply that Jobs is not a nice guy but I think even a lot of Apple fans are OK with Jobs being a not-nice-guy-who-gives-them the coolest stuff.

I am personally distributed by the cult-like-climate that Apple is described as having but I am also appreciate that Apple is seen as where the best UIs appear.

I think having single persons aesthetic control _is_ very important to and we should think about why.

My suspicion is that one wouldn't necessarily have to have genius to do this, just a willingness _not to accept the usual croft that infects just any large engineering project_. Any _average user off the street_ can walk and say "I don't want to do that in five steps, I want to do it in one". The only genius it take here is a willingness to keep attitude even though a team of twenty spent a year deciding that five steps made sense (and their _terrible_ decision happen because the logic of engineering process crept slowly and insidiously into their aesthetic, their idea of what is "OK").

</comment><comment><USER28> The Mac was an improved version of the Lisa, which was a copy of the Xerox Alto, which was inspired by Englebart's NLS.

You can see what it would have been had Raskin carried out his plans, because he did, to something called the Canon Cat: <http://tinyurl.com/47hj7m>

Raskin has a better claim to the iOS design, in that it is an "incredible morphing computer".

<comment><USER29> Ah, yes, the Canon Cat. A real world-changer, that.

<comment><USER28> Yes, too bad. It looks far superior to what I'm typing in now.

<comment><USER30> You know, if you wanted to implement a Canon Cat, you could probably do it pretty easily and on a reasonable budget with a modern 16-bit or 32-bit microcontroller, an SRAM chip, an SD card, an LCD, the keyboard of your choice, and Lua instead of Forth. Or you could hack up Emacs or something to support LEAP keys and whatnot (maybe you can relabel the Windows key on your keyboard), although that wouldn't give you the instant-turn-on ability. Most of the detailed specs were available on the web for a while under the name "The Humane Environment".

</comment></comment></comment></comment><comment><USER31> Steve is the 'brave general' that sparked Apple, destroyed it, and rebuilt it again. He may have been a sociopath artist in his 20's but he grew up to be the world's greatest CEO in his 40's and 50's. Just look at the Apple 10 years ago and look at them now.

<comment><USER27> Hmm,

Does building Apple to the level it is now prove he stopped being a sociopath or prove that he was the right sociopath for the right job?

<comment><USER31> Once a sociopath, always a sociopath. However, the Steve running the show today is not the same as the Steve that got kicked out.

He certainly would not have been able to execute grand plans like the iPod, iPhone, and iPad without having hundreds of brilliant people working with him and being proud of their work.

<comment><USER26> > However, the Steve running the show today is not the same as the Steve that > got kicked out.

I really don't think that's true.

> He certainly would not have been able to execute grand plans like the iPod, > iPhone, and iPad without having hundreds of brilliant people working with > him and being proud of their work.

Most of the Macintosh team did seem proud enough under him (so much so that some followed him to NeXT). He probably learned a lots of stuff inbetween, but the biggest difference is the people he found to work around him. He doesn't seem to have significantly changed himself,

<comment><USER31> What is your problem with the guy? What evil has he done to you or to Earth?

</comment></comment></comment></comment></comment><comment><USER32> Steve jobs need not do it. He provides the vision, his engineers design his vision into a product and he sells it . period.

</comment><comment><USER33> regardless of the truth it appears it's never too late to change and get better at what we do.

</comment><comment><USER34> Well, guess what. He finally had success, regardless of what happened decades ago. ;)</comment>


New browser extensions let you hit the NSA where it hurts: in the data - <AUTHOR> http://qz.com/125642/new-browser-extensions-let-you-hit-the-nsa-where-it-hurts-in-the-data/

<comment><USER2> Hmm... this looks interesting and I totally would do it- but part of me is afraid of being the only person to jump in on this, and end up having NSA knocking on my door lol..

Is it illegal to 'trick' the NSA? If they branded me a terrorist even if I wasn't one - would I have due process? Would anyone even know where I was when they come and get me?

<comment><USER3> _Is it illegal to 'trick' the NSA? If they branded me a terrorist even if I wasn't one - would I have due process?_

I'm sure they deal with false positives all the time, it's not as if anyone who types "terrorist jihad pressure cooker bomb death to america" into a form is suddenly going to</comment></comment>


Switch to DuckDuckGo in iOS 8 - <AUTHOR>

Settings > Safari > Search Engine <comment><USER2> DDG is good for English related terms. For Greek (and I guess other languages) lags way beyond Google in terms of results quality.

</comment><comment><USER3> You can do this in Safari 7.1 on Mavericks, too. (And Yosemite, obviously.)

</comment><comment><USER4> I've done also in iOS 6, using web-app!</comment>


We asked every member of Congress with a CS degree about the Apple/FBI battle - <AUTHOR> http://bgr.com/2016/03/23/apple-vs-fbi-congress-interviews/ <comment><USER2> I don't know why someone would believe that politicians with a CS degree would be any less of a politician. It's not that politicians without CS degrees can't comprehend nuanced arguments on security. It's just in their best interests to expand the power of the legislative body.

If they were approached under the guise of "we're here to ask all CS majors", then, like any good politician, they will tailor their answer to "it's a complex question, and I value security, but we all need to work together", which is really a non-answer.

<comment><USER3> I'm not even particularly sure why content expertise is relevant here. There are a lot of arguments _both for AND against_ the FBI that demonstrate a poor understanding of the underlying science. But there are also strong arguments _both for AND against_ the FBI that are backed by a strong understanding of the underlying science. Ultimately, the question at hand is social and political -- not technical.

That's why so many arguments technical people make in favor of Apple miss the point entirely -- they think that it's a technical problem, but it's actually not. In fact, I'm much more interested to hear the opinion of an ethicist or political historian or public policy expert than the opinion of a technical person.

 _> It's just in their best interests to expand the power of the legislative body._

That's _also_ true of politicians who _do_ have technial expertise. E.g. Herman Cain has a masters in CS.</comment></comment>