Guy Kawasaki launches Alltop, an "online magazine rack" - <AUTHOR> http://www.alltop.com Announcement here http://blog.guykawasaki.com/2008/03/announcing-form.html <comment><USER3> It looks like a made for adsense site created by a spammer who buys thousands of domains a day.

<comment><AUTHOR> What do you think would help it look more legitimate? It seems to me like it would be hard to make a site like this - a collection of links - <USER2> otherwise while still keeping the simple, spare look.

<comment><USER3> Having a non-generic slogan/tagline would help. MFA sites often have a meaningless slogan on them like "when you need it, you need it".

Clearly identifying what the site is the way reddit does would also help.

Make it look like it's not autogenerated by a script. How about a link to a blog or something?

</comment></comment></comment><comment><USER4> Its simply <http://originalsignal.com> sans technology articles.

Not that clever or ground breaking really.

</comment><comment><USER5> I gave the site a whirl, but my main problem is that it just aggravates information overload. There are way too many headlines to scan through and most of them don't appeal to me.

I like the concept of an auto-generated RSS aggregator for the masses that can't create their own, but I think the user should have some input (i.e. ask them their preferences before-hand) in order to reduce the sheer number of articles on each page.

</comment><comment><USER6> Am I the only one, that actually likes it :)

<comment><USER7> I like it too.

</comment></comment><comment><USER8> I think once Sea Dragon becomes a viable technology to use on sites, something like AllTop might be of great value if it could directly display the content (each page) in the listings.

Demo: <http://www.ted.com/index.php/talks/view/id/129>

</comment><comment><USER9> I like the site. Requires no setup. No third-party tools to track feeds. Just go to the site, pick a topic and start browsing.

Sure, it's not something built for tech-saavy users who want to customize their own RSS feeds, but the majority of internet users don't fall into this category anyways.

</comment><comment><USER10> This doesn't run on PHP, it runs on ego.

<comment><AUTHOR> There's been plenty of valid criticism directed at Guy here at news.yc (for example, he gives startup advice but hasn't had a successful startup of his own), but I really don't think he has a large ego. In fact, what I like most about his presentations, interviews, and moderatorships is that he's always poking fun at himself. He always mentions his stupid mistakes in a way that's funny and endearing.

I've also emailed him personally a couple times and he answered the email himself, which is not a characteristic of someone with a delusional sense of his own importance.

<comment><USER11> He's also quite up front about having no successful startup, at least in two interviews I've listened to (he brings it up without being asked directly).

</comment></comment></comment><comment><USER12> how is a random selection of links from categorized topics from Hacker News, or Digg, or Reddit, thrown on one page any different?

this seems like a big waste of mind-ffff-space to me.

</comment><comment><USER13> I thought he launched this months ago? Correct me if I'm wrong.

<comment><AUTHOR> the "formal" announcement was today: <http://blog.guykawasaki.com/2008/03/announcing-form.html>

</comment></comment><comment> daniel-cussen What happened to trumors? Is that still going?

</comment><comment><USER14> I'll show you an online magazine rack

</comment><comment><USER15> A good idea: an index of RSS feeds cataloged by subject and selected by an editor with good taste. (The recommendation engines and delicious just can't substitute for an editor.)

Too bad this site isn't about RSS feeds and it isn't discerning enough.</comment>


Ask HN: How do I fund an open source project management app? - <AUTHOR>

I am part of a open source project which has an interesting way to get things done from the network you are part of. We are hoping to crowdfund it via IndieGogo.
Where I can find backers for such project.
Any open-source communities you recommend? <comment><USER2> One option which you may want to explore is Assembly. I haven't used it myself but I'm interested in potentially launching something on it in the future.

[https://assembly.com/discover](https://assembly.com/discover)</comment>


Facebook down - <AUTHOR>

The webpage is down! <comment><USER2> Just use [http://www.isup.me/facebook.com](http://www.isup.me/facebook.com) instead of complaining on HN.</comment>


SkimFeed – A Tech News Dashboard - <AUTHOR> https://skimfeed.com/ <comment><USER2> I like the concept and the lightweight presentation, but this site really suffers by excessive trimming of subject lines. In many cases, I can't tell what the story is about at all, and so I just didn't bother continuing to explore.

<comment><USER3> I used it but turned back to HN because of missing stories. Also when there is an aggregator for aggregator perhaps something is wrong</comment></comment>


The Grandest Art of the Ancients - <AUTHOR> http://www.nybooks.com/articles/archives/2015/aug/13/greek-bronze-grandest-art-ancients/

<comment><USER2> Brings to mind the following Ode from Horace ([https://en.wikipedia.org/wiki/Horace](https://en.wikipedia.org/wiki/Horace)):

      Exegi monumentum aere perennnius
      regalique situ pyramidum altius,
      quod non imber edax, non Aquilo impotens
      possit diruere aut innumerabilis
      annorum series et fuga temporum.
      ...

(I have finished a monument more lasting than bronze and higher than the royal structure of the pyramids, which neither the destructive rain, nor wild Aquilo is able to destroy, nor the countless series of years and flight of ages.) ...

Full of himself, yes, but a good summary up the durability of a beautiful thing ("A thing of beauty is a joy for ever:/ Its loveliness increases;/ it will never Pass into nothingness;" from Keats' _Endymion_ [https://en.wikipedia.org/wiki/Endymion_(poem)](https://en.wikipedia.org/wiki/Endymion_\(poem\))). Horace was talking about poetry, of course, but I think same applies to these statues.

<comment><USER3> Reminds me of the last lines of the Shahnameh (Book of Kings) from Ferdowsi:

      I've reached the end of this great history
      And all the land will talk of me:
      I shall not die, these seeds I've sown will save
      My name and reputation from the grave,
      And men of sense and wisdom will proclaim
      When I have gone, my praises and my fame

[http://news.bbc.co.uk/today/hi/today/newsid_9197000/9197062....](http://news.bbc.co.uk/today/hi/today/newsid_9197000/9197062.stm)

</comment></comment><comment><USER4> Thank you for the heads-up. I will definitely aim to see this at the National Gallery.</comment>


Ask HN: Who are you on Twitter? - <AUTHOR>

On a side note: Who has actually made a strong lead or otherwise formed a strong connection through Twitter? <comment><USER2> @VoidMonk

More:

<http://news.ycombinator.com/item?id=134808>

<http://news.ycombinator.com/item?id=480171>

<http://news.ycombinator.com/item?id=145204>

</comment><comment><USER3> @errantx

Ive yet to make strong connections with Twitter. Or rather I have made connections and thern taken them to other media.

</comment><comment><USER4> @davidnwelton - this question has been asked before, too.

"Twitter - the CB radio of Web 2.0" - over'n'out, good buddy.

</comment><comment><USER5> @rscott

I'm not sure that it's really good at "strong" connections, but it is good for a quick word to someone.

</comment><comment><USER6> @omarabid

I made around 20,000 followers in 2 months, but more than 7,000 of them now quit twitter!!

</comment><comment><USER7> Misread that as 'Why are you on Twitter'.

</comment><comment><USER8> @michael_erasmus

</comment><comment><AUTHOR> @Quizbiz

</comment><comment><USER9> @bleidl

</comment><comment><USER10> @pystar</comment>


New California declares independence from California in bid to become 51st state [pdf] - <AUTHOR> https://img1.wsimg.com/blobby/go/720c6a07-3594-44b7-8098-94fc11bae240/downloads/1bs7g2fao_444861.pdf <comment><USER2> 1) Why? 2) Who gets to be "new California" vs. "old California"?</comment>


How to get Bitcoin from the early adopters to the early majority - <AUTHOR> http://andrewoons.com/post/93339555434/how-to-get-bitcoin-from-the-early-adopters-to-the-early

<comment><USER2> I think social trading apps / websites are the way forward - get friends helping each other with the learning curve, and P2P transactions well away from centralised exchanges.

I built CoinTouch to find friends of friends that trade crypto currency. It's been live since February and has 1700 users now.

There's a critical mass on CoinTouch such that most new signups see orders within their (two degree) social network. FB and Google+ are supported, and all transactions are P2P. No fees.

[https://www.cointouch.com/](https://www.cointouch.com/)

Feedback welcome.

</comment><comment><USER3> It's the other way around :)

<comment><AUTHOR> Changed. Thanks for pointing it out :)!</comment></comment>


dōmo: Markup, style, and code in one language - <AUTHOR> http://domo-js.com

<comment><AUTHOR> Hello there, author here.

I'm still working on how to get the message across, but the idea is this:

We all know CSS. We all know HTML. Most of us agree that neither is powerful enough to build modern web apps, hence the explosion of CSS-preprocessors and templating engines.

If we're going to build tools to improve browser technologies like CSS and HTML, let's build them using another browser technology: JavaScript. Instead of adding incompatible extensions to CSS and HTML, let's first port them as-is to JavaScript syntax and then do the extending there, where at least the tools we build will interoperate.

Instead of learning increasingly arcane/proprietary/underpowered syntax for looping or doing arithmetic or writing functions, let's just use the tools we already have. Not to mention this gives us a streamlined development process and lower cognitive overhead for free.

Feedback welcome.

<comment><USER2> Looks like a neat idea, but I see a few technical problems with it:

\- afaik, <meta> doesn't work properly if injected via js (e.g. try the viewport meta tag to control screen width in an ipad)

\- <object> (for Flash fallbacks in IE) and a few other tags also have DOM API composability issues (i.e. you need to innerHTML an entire snippet rather than using appendChild's)

<comment><AUTHOR> This is great feedback, will definitely look into this.

</comment></comment></comment><comment><USER3> While I appreciate the effort and the work of the author, I really don't think it's a good idea. Decoupling makes things easier. Nevertheless good work

<comment><USER4> With a system like this you choose where to decouple rather than having the boundary arbitrarily forced on you.

I've found the HTML/CSS boundary very stifling at times. I use a framework[1] that let's me define my HTML in a very DRY (don't repeat yourself) fashion. Components can be nicely defined in a single small tag, and it would be very appropriate to define some (but not all) of the styling & event handlers in the same place. Sometimes I do via style= and onclick= attributes, but those are very much second class citizens in the modern world.

In other words, I've got a much more powerful mechanism for decoupling & abstraction, so the HTML/CSS/Javascript boundaries are more harmful than helpful.

[1] <http://hobocentral.net>

</comment></comment><comment><USER5> This looks very complicated to me. HTML and CSS have separate structures because they do different things. It's like roads and the lines on a road.

I took a look at the examples and I'm sure that this style of coding would solve some problems. But how many would it create ?

<comment><USER6> Complexity along should not be a negative trait. There are different applications with different needs, the more diversity is (in the beginning) always better.

Personally, I will need to look at the source-code before I can make an initial judgement. But the idea is definitely promising. :)

Just my two-cents.

</comment></comment><comment><USER7> In a similar vein, I've found ClojureScript and Crate[0]/Hiccup to be a rather potent mix for solo web dev in Clojure. It's a liberating feeling to be able to effectively write your backend, frontend, and layout in the same language.

[0] <https://github.com/ibdknox/crate>

<comment><AUTHOR> Thanks for the reference to crate, I'd never heard of it. I'd imagine the pushback on ideas like this is much less in homoiconic lanugages like clojure, since when all is said and done everything is an AST.

</comment></comment><comment><USER8> NO. NO. NO. This is exactly why styling in HTML failed. Things work great when they are broken down anatomically into specific functions. Let's not try to put all of our eggs in one basket.

<comment><USER9> Oh no. How do i make this javascript code modular?! There is no way i can split it in multiple functions or files. Now my code will be one giant blob.

<comment><USER10> In my experience, when you give developers an easy way to mangle everything together, a sufficiently large number of developers takes advantage to cause chaos. Sometimes it takes substantially less effort to deal with artificial hurdles than it takes to keep a team disciplined without them.

(brings back memories of one of my earliest web apps where I'd written a template system that on purpose delegated all by basic conditions and looping to the calling script on purpose to enforce separation; and then two of my developers tried to sneak in a new tag to allow them to embed Perl in the templates...)

</comment></comment></comment><comment><USER11> This reminds me a lot of fab. I dig it.

Other comments on this page so far show predictable HN-style "Hate anything new" bias. The page is pretty easy to understand what's going on, and all of the objections don't make any sense. Good work. Ignore the bozos.

</comment><comment><USER12> But I've spent the last 11 years of my life trying to separate them!

<comment><USER13> My resistance to change has paid off! Now, can someone tell me how to build my layout table with javascript? Also, what is the best way to factor in my Flash navbar effects?

<comment><USER14> Try at <http://www.flash-navbars-and-java-applet-clocks.com> ; they're also part of a really cool webring!

<comment><USER13> Webrings? AWESOME. Adding this to my Aim Subprofile page.

</comment></comment></comment></comment><comment><USER15> Reminds me of <http://coffeekup.org/>

<comment><USER16> Same! It's a shame CoffeeKup and Zappa were abandoned.

</comment></comment><comment><USER17> Wait a sec. Wasn't css invented in order to separate style and structure? Now we have frameworks and libs trying to marry them back together. Why not just use old style html?

It's also funny that there was such a strong movement which tried to separate the view from the code, and now everyone just accepts that you need to code to make ui. Crazy times, makes me think of all those wasted efforts.

<comment><USER18> We all know how to keep our model code separated from our view and controller code even though it's all written in the same language. I think maybe people are worried a bit too much about the language here.

The final HTML is just a serialization of the DOM tree structure that is built up in memory. We can build that tree by parsing chunks of HTML source and looping or substituting in values when we see special non-html tags. On the other hand, we can also build our tree using any other programming language we want.

The trick Jed is pulling here is to make the html builder code a DSL that looks a lot like HTML to make it more approachable and predictable for people.

<comment><USER17> I'm not saying that it's a bad idea. But for the longest time web designers refused learning to code. They wanted to edit their html in dreamwaver, and it was up to the coder to make that possible. When you look at modern web apps, they are very code-centric. Good luck editing that page in dreamweaver. I never found the separation of html and code very useful and welcome this movement. But it feels like we wasted so much time just because the frontenders where afraid of anything resembling code.

</comment></comment></comment><comment><USER19> Please read the lines at the top: "alternative to template engines and CSS pre-processors".

It's not supposed to be used instead of HTML and CSS overall.

<comment><USER20> The example should really be changed to reflect this.

If it's not supposed to be for rendering a whole page, the example shouldn't be rendering a whole page.

</comment></comment><comment><USER21> I really like this. The inability to share information between the server, stylesheets, and javascript is problematic.

Imagine, for example, using this to semantically declare the frontend elements that your website uses, and thus allowing your server to render them, your css to style them, and your javascript to render/manipulate them, all using the same, DRY data. I much prefer something like elements.user_login_form.class_name to needing to remember / deal with naming conflicts.

edit:

I'd love to see someone mix in some <http://lispyscript.com/> with this

</comment><comment><USER22> > markup, style, and code

Sounds like PHP, ColdFusion and other similar great ideas from the past.

<comment><USER23> > in one language

It doesn't say "in one file".

</comment></comment><comment><USER24> The looks like a joy to write, and a nightmare to maintain. I may be old fashioned, but I still see content, style, and behavior as best expressed as separate concerns in source.

<comment><USER25> I don't see the use for CSS; it's not powerful enough to express your styling, so you always need some kind of programmatic processor that generates it (whether in javascript or some other language), at which point you might as well have that same program apply styling directly to your elements.

But yeah, I'd rather have strong separation of markup and behaviour. I love the wicket approach to this (your templates are plain html; the only thing you can add to them is identifiers that mark a tag as being replaced by a component; all logic goes in the code), and wish I could find a templating engine for more modern technologies that used the same approach.

<comment><USER26> No use for CSS? CSS not powerful enough to express styling? Huh?

You want to get rid of CSS for styling and replace it with something else for styling? Wha?

The processors you speak of output CSS. They do nothing that cannot already be done with CSS, they just make it easier. Plus, when using javascript to apply styles you are still using CSS, you are just applying it in a different way.

<comment><USER25> >The processors you speak of output CSS. They do nothing that cannot already be done with CSS, they just make it easier.

And CSS does nothing that can't be done with inline styling (well, that's probably not true now, but it was once and could be made so again), it just makes it easier.

If your site's styling is being produced by some program which knows things like "the nav bar is 20% blue" and "all otherwise unstyled text boxes have a grey background", there's no reason that program couldn't put the styles in the html directly.

<comment><USER26> Sure, an application that inserts into HTML can handle what you speak of, but that doesn't address my questions about the statement of CSS being unsuitable for the task of styles.

Sorry, but inline styling is still CSS. I know that CSS standing for "cascading style sheets" may cause confusion but all styling for an HTML document is done with CSS. Even the default styles a browser uses on an otherwise "unstyled" document is based on CSS. You can insert styles directly into an HTML element with Javascript and you are still using CSS.

But if you start using such an application to insert your CSS directly into HTML then I'm willing to bet you are due for a headache in the future. There are several reasons why inserting CSS inline is a bad idea. First, you are seriously duplicating your code since you have no class structure to work with. Second, you've just given up pseudo classes. Third, good luck maintaining that code, especially if you eventually stop using the program that created this code in the first place. I fail to see how that's easier.

"all otherwise unstyled text boxes have a grey background" - those "unstyled" text boxes are now "styled", you seem to be repeating the statement that prompted my response in that somehow CSS is not the answer but then you provide an example that uses CSS.

<comment><USER25> >Sorry, but inline styling is still CSS. I know that CSS standing for "cascading style sheets" may cause confusion but all styling for an HTML document is done with CSS. Even the default styles a browser uses on an otherwise "unstyled" document is based on CSS. You can insert styles directly into an HTML element with Javascript and you are still using CSS.

Matter of definitions. I'm advocating styling one's page inline and/or via javascript, without using external stylesheets. (Well, I'd really advocate styling using attributes a la html3, but it's too late for that now). Call that what you will.

>First, you are seriously duplicating your code since you have no class structure to work with. Second, you've just given up pseudo classes. Third, good luck maintaining that code, especially if you eventually stop using the program that created this code in the first place. I fail to see how that's easier.

I already have a class structure, because my HTML is being generated by a program. The actual HTML is like an assembly language, not meant for manual reading or editing.

Yes, I've given up pseudo classes. I don't think I'll miss them.

<comment><USER26> By what you say it seems you don't understand what a class means in terms of CSS, because what you advocate is not it. In fact, your avoidance of external stylesheets heavily suggests you don't understand the idea at all. I'm not saying you don't understand these things, but what you say doesn't show it very well.

No one expects a layperson to read or edit HTML, but they do have to receive it in some manner and your method is the most bloated way to do so.

Why can't your magical application just output proper HTML and CSS, with external files if need be, without you ever having to deal with it? I understand wanting an easier way to do things but making something that outputs what amounts to a crappy substitution is not the solution.

Anyway, I wish you luck with the most inefficient method possible of creating and providing styled HTML documents.

EDIT: to the creator of domo if they happen to read this, to me this thread has nothing to do with your endeavor, I actually find it somewhat interesting despite its obvious problems. This thread is about the idea proposed about CSS as if we can be rid of it, as to be tossed away. My original intention is to explain that this is a silly idea and this has gone in a different direction.

<comment><USER25> I know it's not a class in CSS terms, I didn't think that distinction was relevant.

>No one expects a layperson to read or edit HTML, but they do have to receive it in some manner and your method is the most bloated way to do so.

Sending things over the wire in compressed form is trivial (many servers do it already) so this doesn't bother me.

>Why can't your magical application just output proper HTML and CSS, with external files if need be, without you ever having to deal with it?

My goal here is to reduce the number of layers you need to understand to debug your webapp. Fundamentally CSS selectors provide a way to reuse (some small specific parts of) your markup in several places - but any web application framework will already provide a way to reuse markup, with its own logic. So why should developers have to learn two different ways of abstracting their markup?

<comment><USER26> The distinction is relevant in that you seem to want to ignore them for a less efficient method.

Yes, indeed, many servers send the HTML, CSS, and JS files compressed and is trivial, but bloated code that is compressed still takes more bandwidth than more efficient code compressed. There might be something said about combining all three into one HTTP request but to say that there's little difference between bloated inline styles and a properly created style sheet is an odd one. Even if the difference between the two is 10k per page then it adds up over time. It would be far better to rely on CSS classes in the head section of the document than to have duplicated inline styles throughout the document. It seems you are willing to create inefficient output for the sake of attempting efficient input, which only benefits you personally as the coder during the creation process of the project.

Therefore I don't think you are reducing the number of layers involved, but only masking it. In the end you will still have HTML and CSS but with a slightly different way to code them. If that's the extent of the goal then congratulations on duplicating what we already have. Although these applications are interesting and have intriguing ideas, they don't fundamentally address the inherent problems of HTML and CSS. For things like this all your doing is creating a new way to write inline styles which can be done right now without adding in new inherent problems.

What's the difference between this:

STYLE.on("element", {textAlign: "center", fontSize: 50})

or this:

element style="text-align: center; font-size: 50px;"

or this: .element {text-align: center; font-size: 50px;}

Almost nothing, in terms of inline styles. Except that the first two have to be duplicated throughout the code wherever they are required while the third only requires a reference. Now, if you need to change that text-align to left you have to change every instance of it throughout your code, except for the third where it only needs to be changed once. If this code is duplicated in multiple files then you've added complexity to the task, while with a single style sheet you only change one line. Also keep in mind that with the first example that code has to parsed on every single page load before it can be rendered.

Now, in the cases of small webapps I can see these things being of little concern. But for large projects or a regular website it's asking for headaches. Not because of things like domo, but because the end result has to be what the browser expects. Plus, there's the issue that if you want this web page to be indexed by search engines you're going to have problems. If people have turned javascript off or use a white list to control scripts then this page simply will not work with very little available fallback. If someone other than you needs to maintain or update this code and don't know this system then you will have problems.

So, am I saying that people should stop making these type of things and stop experimenting? Of course not, this type of exercise is interesting if the end goal is to determine how we could possibly replace HTML/CSS with something more useful in terms of modern websites and apps. For instance, being able to do mixins and the like in CSS is incredibly useful, which is why the CSS processors are popular. But to say that we can take something like domo to be used today as a replacement to HTML/CSS is a bit misguided. In the end it is still HTML/CSS, what we have here is the equivalent of a WYSIWYG editor for javascript coders who, for whatever reason, don't/can't/won't learn HTML and CSS even though those are the easiest parts of the equation.

Keep in mind this thread started for me because of your statement that CSS is not powerful enough to express styling when that's exactly what it does and all that it does. In the end I fail to see how what you propose is better than what we have today, in fact I feel it is worse.

By the way, CSS selectors do not provide a way to reuse your markup in several places. That is, if you are referring to HTML when you say markup, which is the usual definition of the word. CSS selectors let you target elements in your markup to style them, nothing else. You can use these selectors to reuse your CSS stylings for duplicate elements that require the same styling. It is statements like that suggest to me you don't fully understand the relationship between HTML and CSS.

<comment><USER25> >What's the difference between this: >STYLE.on("element", {textAlign: "center", fontSize: 50}) >or this: >element style="text-align: center; font- size: 50px;" >or this: .element {text-align: center; font-size: 50px;}

The difference is that CSS has its own syntax, its own semantics, and its own set of gotchas to learn, different from any other language. (Obviously for a simple selector like .element it's easy to know what it's going to refer to, but CSS is not limited to things that are so clear).

>Now, if you need to change that text-align to left you have to change every instance of it throughout your code, except for the third where it only needs to be changed once.

Only if you're a muppet. Your HTML is being generated by a program; that program should have a single place where it knows what the text-align of this class (in the general sense of the term) of elements should be, and you can change it in that one place if you want to change it.

>Plus, there's the issue that if you want this web page to be indexed by search engines you're going to have problems. If people have turned javascript off or use a white list to control scripts then this page simply will not work with very little available fallback.

Right; it only makes sense to use javascript if you're already using javascript for major functionality. That's what I'm really advocating for here: write your styling logic in the same language as the rest of your site's logic.

>Keep in mind this thread started for me because of your statement that CSS is not powerful enough to express styling when that's exactly what it does and all that it does.

My point was that it isn't powerful enough to express your styling in a fully abstracted way. E.g. if your website's general colour scheme is blue and you have parts that are a light blue, a mid blue and a dark blue, CSS doesn't let you define these colours in terms of each other - so if you want to change it to be green, you have to change three different colour definitions. Because of this kind of thing, people use pre-processors like LESS - which means using yet another language with its own syntax and logic to learn, when you're already using a perfectly good programming language to generate most of your site.

>CSS selectors let you target elements in your markup to style them, nothing else. You can use these selectors to reuse your CSS stylings for duplicate elements that require the same styling.

Yes, that was why I took pains to say "some small specific parts of your markup". Your styles are part of your markup, at least traditionally.

<comment><USER26> But if you use CSS within javascript you are still using CSS syntax. The only thing you seem to be saying is that you've removed the need for selectors. Which you can do right now with inline styles, which I've been saying is not the best thing to do. If the CSS selectors for a page are difficult for you to understand then the problem lay in the HTML, not the CSS.

I guess I'm a muppet that doesn't understand how you avoid having to update lines of code all over the place when your code is sprinkled with inline styles. Unless you are advocating using some kind of class system for styling within javascript, which is odd since CSS already offers that. If you are speaking of applying CSS classes through javascript, which sounds like what you are describing, then I'm confused over what the point is. You can create CSS classes and apply them to elements on the fly right now, you just seem to saying you want to create the CSS classes in javascript. Which makes no sense when you can do the exact same thing more efficiently in an external style sheet. The reason it is more efficient is because those classes will not need to be created on every single page load.

So your answer to the problems I point out is to ignore the problems I point out. Sure, use javascript for everything and wonder why no one can find your site on their favorite search engine or why some people cannot see your site at all. I understand what you're saying about writing your styling in javascript, which is really CSS, but you are skipping over the problems I point out that are inherent in that solution.

I've already agreed that CSS has serious limitations and that pre-processors (even domo) attempt to address them, some do so quite well. The syntax that SASS and Less use is actually existing CSS syntax with extensions, there's very little new syntax to learn. I would say your solution has more of a learning curve involved because you are adding completely new syntax and logic to javascript when it wasn't designed to do these things. The solution is to update what the browsers expect from CSS. There is no reason why CSS itself cannot be extended to do what you are speaking of, probably most people (including me) would want that functionality right now. But again, the very thing you speak of is CSS, syntax and all, it changes nothing other than how you code it. Much like my three examples you pretty much ignored, you still have to learn the CSS syntax and capabilities regardless of how you feed it to browser. Unless you advocate coming up with a whole new styling language that eventually outputs to CSS, which is required because that's what the browsers expect. In the end, it doesn't matter how you use CSS but you are advocating an inefficient way of doing it.

As I said before, creating a more inefficient output for the sake of maybe, just maybe, slighly more efficient input is not the solution. What you want is to reverse the progress that's been made over the last ten years or so because you can't be bothered to learn some of the easiest syntax in the industry. Well, actually with your solution you still have to learn the same syntax. It's not even as if HTML and CSS were programming languages. There's next to no functionality involved with these two. I would say what you want would make these things more complicated for the coder and less useful to the end-user.

Again, CSS has nothing at all to do with markup. Saying "small specific part of your markup" doesn't qualify your statement, since it doesn't actually do that. Styles are not part of your markup, period. Well, maybe inline styles but, again, that's bad. Sure, you can add classes and ids to your markup for CSS to use as selectors but even then they are not required. Plus the fact that ids are already needed within HTML for various things and using classes with javascript libraries such as jQuery (javascript is almost ready out of the box to do this itself) has become almost standard. Basically, you are already using for other purposes the very things that CSS needs to make coding easier, yet you say selectors are difficult and confusing to use. If they are difficult and confusing to use then you shouldn't be using them in javascript, which I bet you do. The closest to providing markup in CSS is with using :after or :before pseudo-classes with the content property, which has its uses but severely limited. But you've given up on pseudo-classes so that is irrelevant to you.

I haven't even brought up the serious accessibility problems this solution has which can get you sued in the real world, or the US at least.

By the way, stimulating conversation we have here.

<comment><USER25> >Unless you are advocating using some kind of class system for styling within javascript, which is odd since CSS already offers that. If you are speaking of applying CSS classes through javascript, which sounds like what you are describing, then I'm confused over what the point is. You can create CSS classes and apply them to elements on the fly right now, you just seem to saying you want to create the CSS classes in javascript. Which makes no sense when you can do the exact same thing more efficiently in an external style sheet. The reason it is more efficient is because those classes will not need to be created on every single page load.

I'm advocating using whatever programming language you use to apply behaviour to your site, whether that be javascript or something else, to apply a style where it's needed, rather than via CSS selectors. Any language you're using to generate web pages will already have this functionality, because it's needed to e.g. attach event handlers (or equivalent) to text boxes. If your application uses jquery, use that (but it's probably not the best example, because jquery uses pretty much the same selector syntax). If your application uses some awful adobe templating engine and does everything via XPath, use that. If your application uses a java class hierarchy, use that. Etc.

>I would say your solution has more of a learning curve involved because you are adding completely new syntax and logic to javascript when it wasn't designed to do these things.

I think javascript is already very much optimized for functions of the form: find some subset of the elements on the page, and then do something to them.

>The solution is to update what the browsers expect from CSS. There is no reason why CSS itself cannot be extended to do what you are speaking of, probably most people (including me) would want that functionality right now.

Unfortunately the W3C is unwilling to even add variables to CSS. Even if they did, it would be years before we could rely on new functionality being present in end-user browers - and then what if we realised we wanted some additional functionality? Better for the logic to be written in server-side code, and we can use new languages as they're invented. (With javascript we don't get to use new language features but we can at least use new libraries, which is more than can be said for CSS)

>Much like my three examples you pretty much ignored, you still have to learn the CSS syntax and capabilities regardless of how you feed it to browser. Unless you advocate coming up with a whole new styling language that eventually outputs to CSS

Up to a point. Things like the box model there's no getting away from, but I see no need to use the CSS syntax or CSS selectors. Just like the way we currently handle the DOM, there can be a single styling API but you can use it in javascript with javascript syntax, or in python with python syntax, or in whichever language you like.

>Styles are not part of your markup, period. Well, maybe inline styles but, again, that's bad.

Without/before CSS, all styling was inline, i.e. part of your markup. The whole reason CSS was invented was, as I originally said, to provide a way to reuse (some small specific parts of) your markup in several places.

<comment><USER26> I apologize, I fail to see how what you want to do is any different than what you can do today. Almost everything you just said is what I've been saying the whole time. You can create a CSS class in either a external style sheet or in a style section in the head of the document and use javascript to apply that class to any element on the page. Since you are already using CSS selector syntax in javascript to target these elements I really don't see how having something in between that makes it any easier. If I understand what you are saying, you wish to remove the selector part out of CSS and apply it directly to elements as they are used. But, again, that's already there, right now, today, for you to use with no third-party tool with its own syntax/language to get in the way.

All I can see at this point is that you wish to stop using CSS selectors but still use CSS syntax in describing properties of the elements to be styled. As stated in the beginning, you wish to remove CSS for styling and replace it with something else for, styling. That makes no sense. You are already using these very same selectors to target these elements with javascript. Plus the same syntax can be used in any programming language that outputs HTML, just assign class names to the element as they are created.

Since you propose to no longer use CSS syntax nor selectors in styling elements then I require an example of how you propose to handle this with current browsers. I really just don't understand the concept of creating CSS to style elements without using CSS, that's the circular argument you are using.

You say you want a single styling API, that already exists and it's named CSS.

<comment><USER25> >Since you are already using CSS selector syntax in javascript to target these elements I really don't see how having something in between that makes it any easier.

Stop fixating on javascript. Sure, javascript uses the CSS selector syntax. But other languages use other ways of addressing particular page elements, and I don't think the CSS selector syntax is a good way in general.

>Plus the same syntax can be used in any programming language that outputs HTML, just assign class names to the element as they are created.

The same syntax as CSS, which is different from that programming language's natural syntax. Outputting class names adds an extra level of indirection that's just unnecessary. Why not just add the relevant style inline?

>You say you want a single styling API, that already exists and it's named CSS.

A single API, not a single syntax. What I want is two things: 1. A natural way to build up a style declaration programatically in python or java (javascript already has this to a certain extent), not a string in CSS property syntax. 2. A natural way to apply this to some subset of the elements on my page, which I identify using whatever tools my programming language has (which in javascript might be CSS selectors, but in general won't be).

Now you're right that the second half is almost-possible. I can use my language to put class attributes on those elements I want to style, and then have a CSS file (or rather, a CSS-preprocessor file) that only ever uses these classes as selectors. As long as I keep the class names unique that works and it keeps the CSS comprehensible.

But I've still got two separate programs in different languages that don't need to be separate - my main program generates a mapping from page element to classname, and my CSS-preprocessor program generates a mapping from classname to set of properties[1]. The latter is a task that my primary programming language is perfectly adequate for (and vanilla CSS is not, because it's not powerful enough, hence the need for a preprocessor). So what I want is to have a bit of code that generates an object representing a set of properties (which would "really" be a string in CSS property syntax, sure, I don't care as long as it has a reasonable API for manipulating it in my programming language), and then rather than attaching a classname to the elements I want to style, I attach this style object, which applies it directly inline.

At that point the inline style would still be sent to the browser with CSS property syntax, but there'd be no separate CSS file and no cascading, so I think it's fair to say this would not be using CSS.

[1] A program which happens to be interpreted by the browser (after preprocessing), but conceptually a program nonetheless.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER27> I have used something similar since 2007 ( <http://amix.dk/blog/post/19199> ), I only use it on client side to generate DOM elements and generally it's a nice approach (I like this much better than constructing HTML via innerHTML). The general idea for this is from MochiKit and I think they were inspired by stan (that ships with Nevow framework - - which seems to be dead now).

</comment><comment><USER28> Personally I see this as completely redundant.

</comment><comment><USER29> Some people like building good, simple things (CSS) Some people like making these things better (HTML5, CSS3) Some people like adding extra features and options, disregarding the loss of a bit of simplicity (LESS/SASS) And some people just like making things more complex for the sake of it (Domo.js)

</comment><comment><USER30> Reminds me of perl's CGI.pm html generators.

Also, these are similar, though not function based: <http://www.jsonml.org/> and <http://jsml.org/>

<comment><USER31> Also similar to (in Perl)...

* HTML::AsSubs - <https://metacpan.org/module/HTML::AsSubs>

* Template::Declare - <https://metacpan.org/module/Template::Declare>

* Template::Caribou - <https://metacpan.org/module/Template::Caribou>

* Markapl - <https://metacpan.org/module/Markapl>

And in Perl6...

* Tags - <https://github.com/masak/web/blob/master/lib/Tags.pm> | [http://blogs.gurulabs.com/stephen/2009/03/tagspm-for-the-per...](http://blogs.gurulabs.com/stephen/2009/03/tagspm-for-the-perl-6-web-proj.html)

and in Ruby...

* Markaby - <http://markaby.github.com/>

* Erector - <http://erector.rubyforge.org/>

and in Common Lisp...

* CL-WHO - <http://weitz.de/cl-who/>

and in Clojure...

Hiccup - <https://github.com/weavejester/hiccup>

</comment></comment><comment><USER32> A glaring issue with this is SEO. The page/site will appear empty for most web crawlers.

<comment><USER21> I imagine most users will want to compile the code on the server side to html/css, and javascript.

<comment><AUTHOR> Right. This entire page could've been rendered on the server. The point is that you can choose the best tradeoff for your app.

</comment></comment></comment><comment><USER33> This seems like it could get unwieldy fast. If you are looking for a way to abstract web development to a single, concise language, why not check out <http://elm-lang.org>

</comment><comment><USER34> Interesting idea, but I just don't like the implementation. Just a few points that jump out for me.

\- The all CAPS make me feel it will be a pain to type. \- The CSS looks more verbose than SASS or LESS. The STYLE keyword each time seems like needless repetition. \- I feel like the HTML templating is less readable than plain HTML or Slim or such tempting engines.

Just my thoughts, I would love to know what others think.

<comment><AUTHOR> This is great feedback.

\- The caps are there to prevent global namespace collisions, since the chances of UPPERCASE global variables existing is smaller. I don't want to add lowercase names to the global, but they would be fine on the domo object itself, so maybe I should put both UPPER and lower there anyway.

\- The CSS may be more verbose that LESS in JavaScript, but it compiles much faster and there's only 228 of code needed to get it. If you want sugar, just use CoffeeScript and it's probably even cleaner than LESS.

[https://github.com/jed/domo/blob/master/docs/index.coffee#L1...](https://github.com/jed/domo/blob/master/docs/index.coffee#L15-20)

\- The STYLE keyword is just there because that's where the "on" function lives. You could assign it to a local variable make the reference shorter.

\- Yes, with bare JavaScript this is probably true, but the idea is to make sugar optional. Add your own and it looks like HAML:

[https://github.com/jed/domo/blob/master/docs/index.coffee#L3...](https://github.com/jed/domo/blob/master/docs/index.coffee#L309-314)

<comment><USER34> Thanks for the reply Jed, yeah I understand your decisions and some of the advantages of going with CoffeeScript. I will definitely keep an eye on the project going forward. Just a quick thought:

\- Maybe better syntax highlighting of the core elements on the website might help with new potential users.

</comment></comment></comment><comment><USER35> I think this is an intriguing idea, and I know this is a silly nitpick, but the all caps function names make me feel like I'm reading HTML from 1995.

<comment><AUTHOR> I (the author) agree. It's not for nostalgia's sake, but to avoid namespace collisions on the global object.

</comment></comment><comment><USER36> this has been around for some time now: <http://code.google.com/p/domplate/>

EDIT: now here: <https://github.com/cadorn/domplate>

more: <http://www.softwareishard.com/blog/category/domplate/>

</comment><comment><USER9> This is wonderful. The main challenge for this project will be not techical, but indeed getting the message accross. Wish you all the best.

</comment><comment><USER37> aka shitty sexprs

</comment><comment><USER38> CAPITAL LETTERS!? SERIOUSLY?

</comment><comment><USER39> where is the doc ? domo-js.com takes me back to the github repo , hard to understand what it is actually about.

<comment><AUTHOR> You're being redirected because JavaScript is disabled. I should make this more clear.</comment></comment>


Top Most Annoying Technologies - <AUTHOR> http://www.vnunet.com/vnunet/news/2232146/top-annoying-technologies

<comment><USER2> Predictably, "Continued on page 2>>" doesn't make the list.

<comment><AUTHOR> Not so predictably. Where did you look? Continue on to page 2 then page 3... until the page for number 1. It works for everyone else.</comment></comment>


PR 101 for engineers - <AUTHOR> https://medium.com/@aneel/pr-101-for-engineers-7cd116cc5347#---0-233.ret21dbpx <comment><USER2> I tried to turn getting press into a method that reads like a programming tutorial, and it turned out like this: [https://medium.com/startup-grind/how- to-get-press-for-your-s...](https://medium.com/startup-grind/how-to-get-press- for-your-startup-the-complete-guide-b79c57318113#.ks48826ah) it's had pretty universally good reviews, including from TechCrunch writers, etc.

<comment><USER3> Thanks Austin, this is a huge help! I'd love to see more posts in this style re: marketing–I'm shockingly bad at pitching and selling my own stuff. Anyone have any suggestions?

<comment><USER2> I wrote a whole book in this style. [https://www.indiegogo.com/projects/the- ultimate-growth-hacki...](https://www.indiegogo.com/projects/the-ultimate- growth-hacking-guide-secret-sauce-marketing--2/x/14399717#/)

</comment></comment></comment><comment><USER4> Aneel makes some good points. Most PR firms serve large companies, who can afford to wait for reporters to come to them. Startups need an active outbound strategy that's focused on reporter needs, and those needs revolve around satisfying their fact-checking editors and readers who want a good story.

I was a reporter for years, and I used to talk and write about it:

[https://drive.google.com/file/d/0BzcEIIxKcYncbUk2ZjRHS1hmQUk...](https://drive.google.com/file/d/0BzcEIIxKcYncbUk2ZjRHS1hmQUk/view?usp=sharing)

[https://drive.google.com/file/d/0BzcEIIxKcYncOHd4VTBrU29ObFE...](https://drive.google.com/file/d/0BzcEIIxKcYncOHd4VTBrU29ObFE/view?usp=sharing)

[https://www.youtube.com/watch?v=VAWZBdLVj24](https://www.youtube.com/watch?v=VAWZBdLVj24)

<comment><USER5> I wonder how the heft of larger PR companies fits with #3 " Sourcing Mass Media News"[0]

\-- [0]: [https://en.wikipedia.org/wiki/Manufacturing_Consent#Five_fil...](https://en.wikipedia.org/wiki/Manufacturing_Consent#Five_filters_of_editorial_bias)

</comment></comment><comment><USER6> I was at AWS for 6 years. Believe me if I tell you that Amazon's PR is very... unique, at least in the IT industry.

I shared some of my stories here, a while ago: [https://medium.com/simone- brunozzi/f-ck-you-vs-thank-you-b25...](https://medium.com/simone- brunozzi/f-ck-you-vs-thank-you-b254f482e7b6#.tg3laxkn6)

(and of course I could do that because I am no longer employed by AWS - I left in 2014).

Happy to hear your comments about it.

<comment><USER7> Interesting blog post. Hope you learned an important lesson - DON'T "FRIEND" WORK PEEPS HIGHER UP THAN YOU.

</comment></comment><comment><USER8> One small piece of advice for anyone following along, make sure you have measurable retention before you reach out to the press. They will inevitably get you a huge boost in downloads and/or traffic, but if you don't have a sticky product, this will have the reverse effect of driving away customers that will be almost impossible to recover.

<comment><USER9> It is interesting how many products flame out with a bad initial press reception. That can be hard to recover from. But it even happens with big companies (see Google Glass).

That said, I think there is a balance, and getting that sort of feedback early on for what is typically a pretty small investment of time and energy in terms of PR can be immensely helpful. It can be a defining moment of understanding product/market fit, especially if you get any negative press that spells out exactly what you're doing wrong.

<comment><USER10> Negative press rarely spells out exactly what you're doing wrong, though. It can be helpful, sure, but PR is not a good tool to discover product/market fit for two reasons.

First, it is way, way too slow to iterate. Second, the press is not your customer.

<comment><USER9> While I agree the press is not your customer, I disagree that it is too slow or doesn't spell things out.

For starters, if the press doesn't like your product, odds are they will give some hints as to why. They may not spell out exactly what you should change, but they should give some hints as to why they are not happy (and it may not be what they say you should change).

In terms of speed, odds are you aren't going to get a massive press hit right off the bat. It will probably be some industry/niche blogs, local publications, etc. You only need a couple to start observing trends, and from there you iterate. Roll out the improvements, test it, and hell, even reach out to the reporters and ask if they like it better. It may get you follow-up press, and even if it doesn't, hopefully you'll get some useful feedback.

</comment></comment></comment></comment><comment><USER11> PR = Public Relations

That'd be nice if the title could be edited.

<comment><USER12> Yeah. I came here to read about pull requests.

</comment></comment><comment><USER13> Are there supposed to be pictures in the text, or is this just really bad layout?

<comment><USER14> They are supposed to be captured from a twitter feed.

</comment></comment><comment><USER15> As someone that works in the gray areas between dev teams, press, marketing and PR I can confirm there is good advice in this post so do read it.

</comment><comment><USER16> Huh, I expected some useful information about making pull requests ...

<comment><USER17> Lol same</comment></comment>


Occupy activists abolish $3.85m in Corinthian Colleges students' loan debt - <AUTHOR> http://www.theguardian.com/money/2014/sep/17/occupy-activists-student-debt-corinthian-colleges

<comment><AUTHOR> Posting to HN because it makes for a very elegant hack, in my view:

 _"It punches a hole through the morality of debt, through this idea that you owe X amount of dollars that the 1% says you owe. In reality, that debt is worth significantly less. The 1% is selling it to each other at bargain-based prices. You don't actually owe that."_</comment>


Distributed Consensus – How Shared Data Is Stored - <AUTHOR> https://medium.com/@yonatanzunger/how-your-data-is-stored-or-the-laws-of-the-imaginary-greeks-54c569c17a49 <comment><USER2> I remember reading the original Google plus post a few years back. Really great explanation for Paxos and general consensus concepts.

If you are a visual learner, a really slick animation explaining Raft distributed consensus protocol is here: [http://thesecretlivesofdata.com/raft/](http://thesecretlivesofdata.com/raft/)

<comment><USER3> This would have saved a lot of time for learning WebRTC, Blockchain, OAuth, HTTP2, and so many other protocol designs that don't always clearly explain race conditions or other edge cases like this animation does.

</comment></comment><comment><AUTHOR> Also related is this [1] by Leslie Lamport on the Paxos algorithm (mentioned in the article)

[1] "Paxos Made Simple" [ [https://www.microsoft.com/en- us/research/publication/paxos-m...](https://www.microsoft.com/en- us/research/publication/paxos-made-simple/) ]

</comment><comment><USER4> Enjoyed reading this article. The Greeks had this amazing knack to get into subjects like this and then _write_ about it, isn't. I am thinking of Plutarch's narration of the Ship of Theseus, a good starting point on issues related to identity and relationships among objects, such as products, software componentes, etc. etc., in a large enterprise.

</comment><comment><USER5> Thanks for writing this up, I enjoyed reading it. I work with distributed systems every day and collected most of this knowledge from practice, but it was useful to see it all compiled in one place.

<comment><USER6> Lately I have been really enjoying articles like this about distributed programming, and have been doing some code experiments on my own to learn more about it (using Akka right now). Do you have a roadmap for how someone could get into a role like yours?

<comment><USER7> This is not quite what you asked for, but I've been going through this distributed systems course and I highly recommend it: [http://nil.csail.mit.edu/6.824/2017/schedule.html](http://nil.csail.mit.edu/6.824/2017/schedule.html)

It's mostly a collection of papers on different distributed protocols and systems, with good lecture notes and FAQs for each one. It also has programming assignments if you like hands-on practice.

</comment></comment></comment><comment><USER8> What a great write up and novel approach to the subject. I really enjoyed this. Thanks for sharing!</comment>


A principled approach to GraphQL query cost analysis - <AUTHOR> https://medium.com/dev-genius/a-principled-approach-to-graphql-query-cost-analysis-8c7243de42c1 <comment><USER2> I'm finding GraphQL very difficult to manage for a team of developers that is learning it as they go. Generally it seems that if we do what GraphQL wants us to do with the ability of deeply nested queries, the complexity increases so much that we have the dual pain of weird corner case performance bugs and highly complex QA scenarios. And if we start tearing apart the queries to force the frontend to make more numerous smaller queries, then we lose much of the benefit. I'm suspecting that the team is too focused on a false choice of a spectrum and that there's an entirely different philosophy we should be following to get the best of both worlds (predictability and flexibility) but we haven't been able to put our finger on it yet.

<comment><USER3> In my experience, GraphQL tempts one to ask for more information than necessary at the moment. That might be useful in just another click or two, but then again, might not.

As you say, smaller, simpler queries are more performant. They also tend to be more relevant. It's kinda like the argument for 2 dozen eggs at $1.60 instead of a dozen eggs for $1. Buying 2 dozen at a time optimizes the cost per egg. But if you only ever eat 10 eggs before you throw the rest away, cost per egg is not the most important factor.

I prefer to pull data on demand in smaller chunks. At which point, GraphQL makes less sense for my use case. But I think it's cool that somebody thought it up and I'm sure it's very helpful in lots of situations.

<comment><USER4> Fulcro in the CLJS world solved this by generating the graph query based on what's currently in the component tree, if you take react components out of your view your query automatically adjusts to remove the components requirements from the graph call

I imagine most js frameworks are greedy because it's extra work to be lean here

</comment></comment></comment><comment><AUTHOR> Why you should measure the cost of your GraphQL queries, and how you should do it.

This is a summary of a research paper.</comment>


A FrankenPad Story: T25 with Quad-Core CPU and UHD LCD Panel - <AUTHOR> https://kitsunyan.github.io/blog/frankenpad-story.html <comment><USER2> It's a shame that thinkpads are becoming less and less modular and functional. Some of my favorite functionalities are:

* Red nub. I use it exclusively, the track pad is disabled and serves me no purpose

* Hot swappable battery. I have a spare battery and it effectively doubles how long I can use my laptop without without charging.

* 7 layered keyboard. It's great to not have to use so many keyboard shortcuts, but rather have a dedicated button.

* Hardware switch for WiFi. If only it had one for the camera, microphone and sound.

* Durable and modular. I installed a hard drive using nothing more than a screwdriver and a 5 minute YouTube tutorial.

* Linux support (or at least not hindrance)

Some things that I do not like about the leaked Thinkpads.

* Envelope widthed laptops. I'm planning on using the Ethernet port before I plan on mailing my laptop in an envelope.

* 1 gram lighter than earlier models. I'm not so strong, but I have no problem sticking my laptop in my backpack and walking around with it. If I really wanted to I could remove 1 gram from my backpack without having to make the compromises that Lenovo is.

* Soldered memory. WTF

Does anyone have a recommendation for a laptop that is still being built that have most of the features that I am looking for. Assuming that it is good quality, money is not so much of an issue.

<comment><USER3> I still use X220s for all my portable computing needs as it was the last model before Lenovo ruined the keyboards. As they invariably die off or just get too slow (or architecturally different - can hardly profile code on them nowadays) I have no idea what to do. Every single modern laptop, irrespective of price, looks like a huge downgrade in every aspect I care about other than the CPU.

Are there any options out there at all for laptops that have at least usable keyboards, hot swappable batteries, proper Ethernet ports, basic maintainability and solid build quality instead of the insane thinness fetish?

<comment><USER4> I'm not sure if there's one for the X220, but there's an unofficial motherboard available that turns an X61 into an "X62":

[https://geoff.greer.fm/2017/07/16/thinkpad-x62/](https://geoff.greer.fm/2017/07/16/thinkpad-x62/)

<comment><USER5> I've since bought an X210. It's an X201s chassis with:

• A Core i7 8550u (4 cores, turbo boost up to 4GHz)[1]

• 2 DDR4 SODIMM slots. I put 32 GB of RAM in.

• 2x mini PCI Express slots. There's an 802.11/Bluetooth card in one. The other is empty but could be used for LTE.

• An M.2 NVMe slot. I put a 2TB SSD in it.

• An upgraded screen (2880x1920, 450 nits, wide gamut). The bezel is cut to make room for the 3:2 aspect ratio, sacrificing the webcam.[2]

I have small hands so I slightly prefer the X62's keyboard, but everything else is _much_ better on the X210.

1\. [https://ark.intel.com/products/122589/Intel- Core-i7-8550U-Pr...](https://ark.intel.com/products/122589/Intel- Core-i7-8550U-Processor-8M-Cache-up-to-4-00-GHz-)

2\. [http://i.imgur.com/lj7g7CV.jpg](http://i.imgur.com/lj7g7CV.jpg)

<comment><USER6> Oh wow. I have an X62 and T70, but skipped the X210 because of the display. If I knew you could get it with a 3:2 display I'd have been really tempted to get one. Do you do the mod yourself or purchase it pre-installed?

<comment><USER5> It came with the display pre-installed. I think all 3rd batch X210s have the new display.

</comment></comment></comment></comment></comment></comment><comment><USER7> Most interesting Thinkpad mods come from China [1][2]. Lenovo keeps changing the Thinkpad line so it resembles Apple machines more and more which is a sad development (focus on form, not function). According to some recent leaks [3] more machines will loose ethernet port and a hot-swappable battery in the next iteration. In that case hardcore fans will have to resort to mods.

______

[1] [https://www.facebook.com/lcdfans/](https://www.facebook.com/lcdfans/)

[2] [http://www.cnmod.cn](http://www.cnmod.cn)

[3] [https://www.notebookcheck.net/Lenovo-ThinkPad-2019-leak- Data...](https://www.notebookcheck.net/Lenovo-ThinkPad-2019-leak-Data-sheets- of-the-redesigned-ThinkPads-T490-T490s-T590-have-been-leaked.410510.0.html)

<comment><USER8> Oh great, the persuit of anorexic computing marches forth.

The swappable and dual batteries on my T440 are a killer feature.

</comment></comment><comment><USER9> Impressive.

I love my T25; it's the best laptop I've had since T420s (still have 2-3 of those around - love how modular they are, even with their slim size, with an upgraded 256GB SSD + 2TB HDD, 16GB of RAM, and still quite lightweight plus the best keyboard ever), and absolutely brilliant compared to abominations like the '40 series which removed the trackpoint buttons (the only time I've ever witnessed a senior security architect literally and repeatedly slam their laptop against the desk in frustration!). Like many fellow nerds or roadwarriors, the little red nub / trackpoint, and decent standard keyboard, are "conditions of employment" for me - I spend too much time on a laptop to chase my own tail with a trackpad [yes it's a low barrier of entry, but it's positively painful to watch my co-workers try to navigate with it, all the while they espouse "but it's so easy!"], or a non-standard home row layout :(

I do agree however that screen is at best "Meh" \- I do a lot of photography processing and the T25 is just not an option. Certainly I wouldn't mind having the better CPU and GPU from newer generations... but I don't think I would compromise reliability, take the risk, or sacrifice the time that this honourable fellow nerd has -- my hat is off to them! :-)

I just hope that the speed at which T25 was sold out, even at a clearly inflated price, will demonstrate the demand. I agree with the author T25 wasn't so much "retro" as "the one good laptop in that generation".

</comment><comment><USER8> I built myself a Frankenpad T440 in Jan. Paid £180 for it on ebay (grade A used) about a year ago. Bought a 2018 MBA which was a pile of shit so decided to return that and make the T440 better.

I swapped the screen out for a FHD one for £39, T450 touchpad (biggest upgrade!) for £20 and new 76Wh battery for £39. New Samsung 256Gb 850 Pro disk (cant remember how much that cost). Upgraded RAM to 8Gb by recycling an HP EliteBook. Copied windows 10 ISO and keypass keychain to the built in 16Gb SSD so I can recover it offline from my S3 backup target.

It's amazing. You'd have to pry it out of my cold dead hands. It's not the best laptop possible but it's an excellent compromise it in total it cost less than 1/3 of a MBA which had dubious "utility" compared to it.

</comment><comment><USER10> I always find it interesting how well ThinkPads lend themselves to this kind of modding. I don't care _too_ much about the crappy screens since I have an IPS desktop monitor if I need it, but it's nice to see how many options you have to upgrade the machines compared to other manufacturers' laptops.

<comment><USER4> I suspect it's because of the straightforward design, relatively roomy interior, and parts availability. An analogy can be made to certain mid-70s American cars with a similarly large aftermarket fanbase.

</comment></comment><comment><USER11> I would have skipped the liquid metal, it will need to be reapplied in a year or two and is a pain in the ass.

</comment><comment><USER12> Good laptop, good taste in touhous

<comment><USER13> It's a f-ran-kenpad

</comment></comment><comment><USER14> So jealous. I almost did the pepe mod on my x230 but backed out when I got the board in. Right now I have a hackintoshed XPS13. I just want a new thinkpad that I can make run OSX flawlessly. I miss the trackpoint and the keyboard.

</comment><comment><USER15> a "portable computer" in the style of 198x and a "cloud on the go" at the same time - a beefy mini-ITX in the backpack with big battery plus a wimpy notebook (just with great screen and keyboard) as a terminal (with HDMI over air and BT keyboard the "notebook" may not even need CPU/RAM) .

</comment><comment><USER16> weight and size aside, Thinkpad W530 is still a good choice:

      - 4 cores (Ivy Bridge), up to 32Gb (4 SO-DIMM slots)
      - decent full HD screen
      - nvidia GPU drives a single 4K monitor @60Hz via miniDP

</comment><comment><USER13> Nice to see that the Thinkpads and fumos meme is still alive.</comment>