Hacker Newsnew | comments | show | ask | jobs | submit | stevoski's comments login

Making a website you with functioning log-in and log-off.

This was the 90's. It was surprisingly hard to implement this in a workable, reliable, secure way, and no one in our company of 50 programmers had ever done such a thing before!

I recall being puzzled for way too long at how to prevent someone from coming to a browser that had just logged off from our web app, and clicking the back button a couple of times to be logged in again.

Now, of course, it is a common and easy-ish task.

I coded the same thing (actually an online magazine with comments on articles, a forum, and a form for signing up for email updates), around the same time. I used classic ASP. I shudder to think of all the security holes I must have had.

I was in Kuala Lumpur, Malaysia a few months ago. I wanted to see a film. I searched in Google for films showing in Kuala Lumpur. I found myself on a web page that, while accurately listing movies and schedules currently showing, looked like it had been created around 2000.

And it was fast. No animations, no auto-complete, no infinite-scroll, no JavaScript frameworks. Just the information I wanted, delivered to my phone seemingly as soon as I touched the link. Simple black-on-white text, plain layout.

This made me somewhat sad, because it showed me what the web browsing experience could have been today.

Obligatory: http://motherfuckingwebsite.com

I'm glad I got off the train as web sites became web apps. I made one of the latter, though it actually was designed to complete certain tasks as opposed to being a container for content.

Websites now seem to be trying to emulate native apps - not just in terms of cramming a bunch of UI into a page, but also in the closedness. I hate how 95% of content sites bury the hyperlinks to anything that takes you off their site, including the source.

The mfws page is 5k or so and one script (and I might want to fight about that depending on the reason it is there - see the page code at the bottom).

Suppose you had another 5k budget for css. What could you do with it to make the page look 'nicer' in the sense of closer to mainstream Web pages that ordinary people might use?

Edit: clarity

Like this? http://bettermotherfuckingwebsite.com/

Yup, that is a tad more modish.

Right, and then you'll add images because you're not a monk. Remember when images were content and not chrome? That's another practice to bring back.

Even with @2x images or whatever, they at least can avoid blocking the load of the rest of the page and rendering the layout. As you add a bunch of other files that have to be fetched over another HTTP connection and then affect the rendering of the page (for example, fonts), we're back to sluggishness.

With only a modest amount of "cruft" (1216 bytes of CSS):


Yes I agree here. When I was in high school in the mid 90's I was able to create my own html pages in a text editor. The web was simple back then we had frames and tables and that was enough.

Sure it wasn't perfect pop up ads were rife, blink tags were a thing and internet explorer had problems with transparent gifs. But the web was simple. Nowadays html pages are riddled with javascript, CSS and I don't have a clue what is going on when I hit view source on the average website.

Webpages are massively over engineered you shouldn't need a scripting language to display an article of text and some links.

And now that we have HTML5 and CSS3 the technology for writing web pages with a text editor is better and simpler; many techniques and features have transitioned from impossible to easy or from convoluted hacks to straightforward. The two pillars of current web page overengineering are generating pages from server-side templates and preprocessors (not only automating cruft production but hiding horrible HTML and CSS code from users) and Javascript abuse.

On the other hand, many people don't want to touch with a ten foot pole a website that doesn't look "sexy".

Even if that were true, the definition of "sexy" has changed over the years. Currently we're in a Rubenesque period.

Do we know that though? Many people who are users or are web devs or project managers or executives? I think that's why there's been a trendy towards minimalist design; it looks pretty good and it's typically fast.

For programming (or other work that involves intense logical thinking), nothing beats silence for my productivity.

Complete silence is, unfortunately, unachievable. But music of any genre, the buzz of people talking, a droning TV - all seem to interfere with my ability to concentrate on a hard problem.

I'm the same. Any noise breaks my concentration.

Same here, wish offices were built with attention to varying needs of silence levels by different employees.

I'm dubious as to whether this change will occur. It's been tried before, and given up due to complexity.

I think it is an excellent idea, but in practice too awkward to implement seamlessly.


Python 3.3 did it: https://www.python.org/dev/peps/pep-0393/


I've been programming in Java since Java 1.1.8 and I hazily recall several regression problems under Sun's stewardship. My gut feeling is that the rate of regressions in Java updates has remained steady.

If the rate has increased significantly under Oracle's stewardship, this is something I'd like to write about in my Java newsletter.

Do you have some statistics to demonstrate that regressions have become substantially worse since Oracle took over Java? I'd happily acknowledge you as a source!


The only real one was System.getenv() which was stubbed out to a no-op in Java 1.3 and then brought back in 1.4.


I recently started to write an article describing how java.lang.String was one of the classes that the Java creators got mostly right in Java 1.0. This contrasts to other Java 1.0 classes such as java.util.Date, which, as the usage of Java spread, and some good practices emerged, revealed itself to be poorly implemented.

I wanted to show in my article how one of String's strengths is that String efficiently shares memory with substrings. But then when I looked into Java 8's String source code, I was surprised to find that this was not the case. It seemed I had been working with false assumptions for years.

Now, thanks to Heinz's article (OP), I discover that this was a change in the String class.

Long ago, a man who had been programming for 30 years told me about his theory of the half-life of programming knowledge being roughly 18 months. Today, Java has made me believe his theory a little bit more.


> Today, Java has made me believe his theory a little bit more.

I think Java is sort of an exceptional case here in that the language stays relatively stable and evolves very little over time. Also they tend to not change internal details of the standard library without reason, so even lots of things programmers shouldn't rely on, such as behaviour of substring() will stay unchanged for quite long.

Now JavaScript on the other hand probably has programmign language and framework knowledge half life of considerably less than 18 months ...


JS now is moving fast but for the longest time it was stuck in stasis with various incompatible implementations floating around. And almost any knowledge on it was probably invalid in one of those implementations.


The date API in Java (before 8 anyway) was hideous. Here's what was wrong with it:



If I worked as a developer inside such an organisation, I'd quit. A sad side-effect of rigorous IT security is the lack of productivity and day-to-day frustrations experienced by the staff.

I've experienced this myself inside a major central bank. Most development staff were a) demoralised and b) frequently adopting insecure work-arounds.


So would I. But another way to look at this is, instead of "I'd quit", saying "they'd have to pay me 3x more to work in a place like that". At which point you can again start looking at it as an economic problem.


You're right. I work at a place that does all but two of those, and I wouldn't if they didn't pay me as much as they do!


If you work at a company with more than 500 employees that does all but two of those, I'd like to hear more about that. As I wrote those bullets, I filtered them through my experience of consulting for F500 companies, and when I found myself writing something I'd seen reliably deployed across entire organizations, I edited the bullet until that was no longer the case.

About the closest I've come to seeing any of these bullets deployed reliably is Microsoft's developer training and deprecation of the standard C library, and that initiative was so out-of-the-ordinary that it was newsworthy, and widely reported.

But to actually earn that bullet, Microsoft would need to deploy those same measures across all its contractors, and, more importantly, deploy them on internal IT and line of business systems, not just the Windows and Office codebases.


I imagine some government facilities could hit that mark—based loosely on descriptions of friends who have worked in such environments.




See the sibling commenter, but think government.

Plus, the posts I read earlier didn't mention 'Fortune 500' or 'reliably' - and I'm glad you didn't use words like 'productive' and 'efficient'!


You mean you don't want to use two entirely separate computers just so you can access email?

Paranoia in excess.


Hey, we used to use a Mac for Internet and email and a Windows machine for "work", both on the same desk.


IIRC, Joel once wrote that he started coding FogBugz to learn some VBScript. Once you start a project in a language, there is a mighty amount of inertia to overcome to move to a different language...


Why I'd never develop a Wasabi in my company:

When I learn a new, perhaps hyped-up computer language, I soon run into difficulties, no matter what the merits of the language. The difficulties are lack of tooling. eg, no debugger - or only a rudimentary one, no static analysis, no refactoring, no advanced code browser.

If the language is successful, these things come with time.

When you develop an in-house language, you'll never get the advanced tooling that makes for a great software development experience. This, for me, was why I was surprised by Joel Spolsky's announcement of an in-house language.

(Although, to be fair, these things didn't really exist of VBScript nor for PHP at the time Wasabi came to be.)


Don't people create things like Wasabi all the time?

Aren't tools like RubyMotion, Appcelerator and their ilk kinda similar to Wasabi in terms of what they do?

You might even make the argument that Coffeescript is somewhat similar to Wasabi.


I think your bracketed comment says it all; there was no obvious alternative at that time which would satisfy the market conditions. The VBScript version was super easy to install for most companies with the servers they already had available. They had a selling feature which was entirely dependent on this terrible technology. So they mitigated it. It's all pretty reasonable.



Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact