Hacker News new | past | comments | ask | show | jobs | submit login
Re-writing the site of Norway's largest transport provider in Elm (bekk.no)
195 points by Skinney 9 days ago | hide | past | web | favorite | 103 comments

I work mostly in Python for data analytics but I like to play with front end from time to time. So I tried elm. I loved learning about the elm architecture and the concepts of a ml type of language. But the community and the principles of it threw me off. I need a simple parser and found this https://package.elm-lang.org/packages/elm-tools/parser/lates...

I guess if you have a CS degree you can understand how that parser works, I couldn’t. The community tried to help me on the forums but you are supposed to know a lot of key functional concepts to even understand their answers.

Then I learned about how they decided to throw away Javascript interops. I mean I love benevolent dictators but this was too much. Just fyi their benevolent dictator thinks if you need a library you should program it yourself. I can see his point but in Python word there are so many amazing libraries. That principle sounds good in theory but it’s theory, the rest or the world thrives with libraries.

However I became a better programmer thanks to elm. I would love for something like ocaml to pick up more steam in data analytics. I think though python won that battle for good principles (easy to use) and not for being functional, or controlling side effects or having less bugs. If you think about it that’s exactly why Excel is still so popular, it’s a monster but it’s easy to use.

> I need a simple parser and found this https://package.elm-lang.org/packages/elm-tools/parser/lates...

> I guess if you have a CS degree you can understand how that parser works, I couldn’t. The community tried to help me on the forums but you are supposed to know a lot of key functional concepts to even understand their answers.

Have you tried writing a simple parser (i.e. just recursive descent) yourself in another language like Python? If so, you'll find the approach of using parser combinators in your Elm example rather superior. If you do not currently understand the foundational concepts of writing a parser, perhaps you should understand them before starting to write a parser.

Or perhaps consider this. Can you get by without writing a parser? If the grammar you're trying to parse is well-known you might find an existing parser; if the grammar is extremely simple you might just use a few string manipulation functions to get the job done.

> Then I learned about how they decided to throw away Javascript interops.

Is this true? I'm not an Elm user yet, but I've been eyeing it and my understanding was that there was interop:


It'd be a big deal if that weren't there -- FP stuff I may or may not be used to? Bring it on. Stretch my CS knowledge? Cool. No 3P libraries? That'd make it wrong for a lot of use cases.

Elm has interop, it's called ports.

What the poster is referring to is that Elm 0.18 had an unsupported, undocumented way of calling javascript code directly. This was inherently unsafe (Javascript can throw exceptions and Elm doesn't support exceptions, let alone catching them) and people were abusing it, so it was removed from the language in 0.19.

> To test out the latter, in the summer of 2017 we tasked a team of summer interns with the renewal of our seat map application, a crucial component of the ticket booking process. They were to use Elm, a language they had no prior experience with. To our surprise they took to the language very easily, and their work turned out great.

I think programmers—myself included—tend to be surprised by these stories, because we envision two learning curves: general programming concepts, plus the additional weirdness of learning Elm.

But "general programming concepts" unpacks into: A) valuable stuff everyone needs to learn anyway, B) a bunch of hard-bought mental discipline which Elm makes obsolete, due to its lack of side effects and mutable state. Going cold-turkey into Elm, newcomers fast-forward through a lot of things JS learners for example have to wrestle through.

[edit for clarity]

I wonder how involved the customer was in the choice of technology. I think the long term costs of choosing Elm will be higher than any perceived gain during the initial development period.

The number of developers with Elm experience in Norway is small, and I think it will make it harder to attract good consultants that want to work on it.

I think these niche but loved language are great ways to attract talent. I’m a senior C#/java dev but I dabble with F#,Rust and Elm on the side. I have mentioned to lots of recruiters that I’m interested in new opportunities only if they mean I can switch to one of these languages. I know lots of people in my situation (from meetups etc).

There are few experienced Elm and Rust devs to recruit from, but there are tons of very experienced developers who would take a pay cut just to work with these languages.

What people know and what people want to work with are in my experience very loosely related.

I would guess that what makes these languages attractive is that, if you end up working in a project that uses one of them, it’s likely to be a new project with almost no technical debt.

I bet that an old and badly designed Elm app would be just as bad to work with.

> I bet that an old and badly designed Elm app would be just as bad to work with.

Not at all!

My company has used Elm since 2015, and I'd be happier maintaining our 4-year-old Elm code from before we knew what we were doing to any modern JS or TS project that's been built optimally according to any definition of JS/TS best practices you like.

I don't think that's an uncommon view among people who have used both Elm and JS/TS in production for a few months.

It's a pretty night and day difference in experience - that's why people who use Elm on the side for awhile so often end up valuing the opportunity to use it at work too.

I think the most attractive thing would be working with others who are also interested in languages.

I definitely believe that functional code bases rot less/slower than imperative/OO code bases. If it’s because the functional code bases are written by “better developers” that’s an even stronger argument for aiming for taking a job using one.

I used to think like that, then I realized that even the famous offshoring shops now also get projects done in those languages, with the same quality you would expect from their typically enterprise project deliverables.

Never be surprised at the capacity for these offshoring shops to write bad code. They excel at this art, for any language.

Jokes aside, there are structural reasons for this phenomena, but the most obvious and pithy one is simply: you get what you paid for.

That might have been true a few years ago. Today, there are plenty of entry level jobs using functional languages.

Also I don't think anyone believes the infinite amount of JS developers makes it any easier to identify a good React hire.

The customer was involved from the very beginning. Everything we do at Vy is done in close collaboration with the customer.

Our experience is that previous Elm experience isn't necessary, as the language is very easy to learn, and people get productive very quickly.

> Everything we do at Vy is done in close collaboration with the customer.

To understand this correctly; 'we' means the company 'Bekk' and the customer is 'Vy', right?

I don't find it too strange that it is relatively easy to onboard new Elm programmers when they are part of the same company. But what happens when competing companies want to bid for jobs at Vy? Vy is after all wholly owned by the Norwegian Ministry of Transport and Communications, so new future contracts are bound to come up. A language decision like this–beyond the merit of the language itself–might create a vendor lock-in that can stifle competition. Without being an Elm programmer myself, I am not sure that the technical merits of Elm is really worth it when taking the competition aspect into condsideration.

> To understand this correctly; 'we' means the company 'Bekk' and the customer is 'Vy', right?


Good question! Vy has their own developers for this very reason. The teams here are a mix of Bekk and Vy developers, should Bekk be replaced by another company, someone will still remain to train the new developers.

I can understand that this might be useful from a technical point of view. From a business point of view I am not sure such a technical choice and symbiosis give the most bang for the buck.

> A language decision like this – beyond the merit of the language itself – might create a vendor lock-in that can stifle competition.

As distinct from the endlessly changing dot Carousel :]

Everyone should just use Java for everything, because "enterprise". Am I right?

This is exactly what I was trying to say without being that direct.. :-)

I don't doubt that you can learn Elm quickly. But how many good developers want to use what might be an obscure technology in a few years.

From the Study of Programming Languages Not to Learn in 2019: "the five languages not to learn in 2019 are Elm, CoffeeScript, Erlang, Lua, and Perl."

The availability of developers is definitely something that should be considered when choosing technology. That said, NoRedInk, one of the companies earliest in adopting Elm have said they have had an easier time of hiring after they change to Elm from React. They are at least an indication of the opposite of what you are suggesting.

Also in Study of Programming Languages Not to Learn in 2019:

"As a final word, we wanted to reiterate that while the languages that didn’t perform well this year are useful and powerful in their respective fields, they may not have ranked as highly on our list because of the three metrics we chose. Therefore, if you really want to learn Erlang, Elm, or Lua, go for it — after all, these languages may make a comeback by 2020 because of your interest in them!"

I think one has to take the result in that article with a grain of salt as they only look at a very limiting set of metrics.

Also in the specific case of Elm I would recommend that people give it a try as it is a very different programming language than the most common languages and a great intro to the realm of strongly typed functional languages and functional thinking in general. Even if you don't end up liking or using it, it is a good thing to have experienced. There is always something to learn from learning new programming languages! ^^,

Personally, I would love to spend some time learning Elm. My point is not about Elm itself, but how smart it is to choose Elm for a project in 2019, at least in Norway.

Elm was chosen in 2017, and initial development was being done by 2-3 developers. Now, development is being done by 15-20 developers. Some of those developers came because of Elm (like me) and some came because our problem domain is interesting, and then learned Elm on the job.

Choosing Elm for a project in 2017 seems to have been a very good move.

I don't agree, but I hope the project is successful in the long run as well! I guess time will tell..

Elm could completely disappear from the face of the Earth next year, and I'd still be glad I learned it, and would still recommend it to others. The concepts have made me a better programmer in general, whether in Node, React or vanilla JS. Hard to explain until you've actually used the language.

Good developpers willing to use a tech that might be obscure in a few years?

Considering JS graveyards, I would have sworn that was 100% of frontend devs until now.

Just so. After having done JavaScript development for a few years, I really can't take the Elm FUD here seriously.

I'm starting to think that there really are a lot of front-end devs who don't know anything but JavaScript.

What's "FUD"?

Fear, Uncertainty, Doubt.

Describing a situation as worse than it really is.

I think there is a clear distinction between languages and frameworks.

But again, what are the clear benefits for the customer of choosing Elm compared to the more popular choices in the market, given the (IMO significant) drawbacks of a niche language?

The article lists several: static typing, guarantee of zero runtime errors, sane error handling using rich enums.

Other advantages: async is baked into the framework and isn't an afterthought like React. Immutability is standard and doesn't require a competing ecosystem of immutable datastructures like React. Also significantly smaller download sizes [1]

I also question that Javascript the language doesn't change: it's gone through several big language changes, and a growing number of devs wanted more changes, so stared writing in Typescript or Flow.

[1] https://elm-lang.org/news/small-assets-without-the-headache

Elm is so small, I'd almost argue that it's easier to learn Elm and The Elm Architecture than it would be than to worry about some almost equivalent combination of TypeScript, React, Redux (which was inspired by TEA, afaik), etc.

From a business perspective, having 0 JS crashes or errors in production is nice. I say that as someone who works at a startup that switched to Elm in 2017 and have had that very experience.

a) Many things that are runtime exceptions or silent errors in other languages, are compile errors in Elm.

b) Immutability, strong type system and few language constructs make local reasoning very easy. Developers spend less time chasing bugs.

c) Easy to learn. In virtual all jobs that I've had as a frontend developer, there's always been something new to learn. I spent more time learning Ember than I did spend on learning Elm.

d) Less churn. Javascript and related frameworks are, to me at least, exhausting to stay up to date on. Elm changes at a much slower pace.

I would argue that Typescript and React or Vue would have been a better solution for the customer. Yes, Elm might be better in some aspects, but I could name quite a few benefits for Typescript as well.

I think the technical reasoning is okayish, but from a business perspective I don't think the customer made a good choice.

We actually do have react in production as well. The header on our website is a react component, and our app is written in react-native. We also tried out flow for a while.

Elm compiles faster, has better error messages, is a simpler language (so our apps tend to stay simple, so easier to pick up again after some time) and has less churn.

We have experience with other technologies, we just find Elm better :)

> I would argue that Typescript and React or Vue would have been a better solution for the customer. Yes, Elm might be better in some aspects, but I could name quite a few benefits for Typescript as well.

Go on then. ;)

I would think most people on Hackernews are familiar with Typescript, but some of the benefits from the top of my head:

- Better tooling - Easier to work with existing javascript code - Superset of javascript - Larger community and ecosystem - More developers are familiar with it - Easy Server Side Rendering

I’m someone that only vaguely knows Typescript and doesn’t know Elm at all, so please forgive me if these seem obvious but would you mind expanding on some of your points?

In what way is the Typescript tooling better? i.e. what can you do with it you can’t do with Elm’s tooling?

Also I’m intrigued by the claim of “easier server side rendering” is it difficult to run Elm code on top of node.js?

That "study" says "which languages you probably should not learn as a first programming language".

Sure there might not be a whole lot of Elm jobs out there. But if there is one and you feel like learning Elm, what does it matter?

Also, since you talk about good programmers, surely a potential employer won't list it as negative that you've been able to switch technologies during your career? To me that's a strength rather than a weakness.

Erlang (via Elixir) is absolutely flourishing right now.

I'm in the process of replacing an Erlang service. Erlang is incredibly well suited for the task, and it's a terrible choice for us.

Initial development was done, system worked and ran for years. Team left, turned over and then 5 years later no erlang developers were left on staff.

The service is business critical, and you don't need 1 developer, you need a team. 3 would provide some basic backup, but you need 5 to fill out the 24/7 on-call rotation. (yes people need vacations, weekends off, etc)

Sadly it's not the entire stack, far from it, it's one mission critical service that's part of a very large system. So the excitement they get from growing, enhancing and scaling the system is already a bit restricted. Problem is, trying to hire is SF is already hard, and now we just selected the pool of engineers to be a small subset of those.

So now the cost of 3-5 engineers, the work to hire them, manager and deal with turn over. Wow.

Sadly (not sadly) we replaced the service with an AWS offering for $1000/mo. World changed in the 9 years since the Erlang product was first written.

It's turned me off niche languages.

Sorry, am I reading this right? You replaced a service that required a team of five Erlang developers with an AWS offering for $1000/mo? Why wouldn't you do that regardless of the language involved?

Sorry for the late reply. It actually needed little development, 1 person would be just fine. But it was also scaling, and bugs crop up. Unfortunately bugs crop up some days at 9pm on Friday, or 2am on Sunday. Since it's business critical this need attention immediately, stop/restart isn't always good enough. So this means you need someone who can supply emergency patches on call all the time. (trust me turn if off, and turn it on again doesn't always work, yay persistence, yay retries)

This can't be 1 person anymore, what if they person takes a vacation. So that's 2 people. Perhaps the 2nd person can be much less capable that the first, they just need to hold the system together for how ever long it takes the lead dev to come back from his 2 week hiking trip in the amazon....yeah not good enough. So then you end up saying we actually need proper on call, so now you're hiring a team.

What if it was another language? Let's assume it's a core language of the organization. Then you don't need a team, but capable Sr/Staff Engineers who can jump in during emergencies. Might not be the perfect fix, but then you have a series of people who can duck tape it together until the person responsible is available.

Using Erlang tied our hands, and made a decision to throw a project business requirement.

It seems strange that you were running an erlang service that requires 5 developers with zero developers.

Also BEAM developers are not hard to find in the Bay. it's hardly a niche language, plenty of Cisco people around at least.

Did you not consider Elixir? All the benifits of Erlang but better tooling. Elixir these days is anything but niche.

I might be in a bubble, but my perception is that the Elm community in Norway is fairly established. Regular meetups, and a really well-organized conference earlier this year.

There are 546 developer job listings on finn.no. One of them mention Elm.. Typescript get 39 mentions. C# 118. Java 121. Javascript 131.

If they know any of those languages particularly Javascript they can do Elm.

A lot of companies aren't even making knowing their core language as a hiring requirement.

You could make an argument about Elm's community size for long term support of libraries. But hiring isn't a very good one. Elm isn't entirely fringe nor immature.

With 0.2% of the jobs available in Norway mentioning Elm, and even if some of the companies using Elm might not state it in the job listing, I would say it is a fringe language here.

And I'm not debating what's possible technically, but if it was a wise business decision by the customer to choose Elm. Based on the popularity in Norway in 2017, today and what it likely will be in the future, I think they should have made a different choice.

> With 0.2% of the jobs available in Norway mentioning Elm, and even if some of the companies using Elm might not state it in the job listing, I would say it is a fringe language here.

You say 'here', so I'm going to assume you mean that literally, and that you are indeed in Norway. Forgive me for assuming the worst, but you seem to have an axe to grind against either Elm, Vy, Bekk, or something else based on your several posts on the story—is that correct?

The article, and others have pointed out, it appears to be a good business decision, as far as hiring is concerned. They haven't had issues with newcomers learning the language. The OP them self said that Elm was a selling point for working there.

As someone who recently lived in Norway, and who has used Elm professionally there, we've also found it to be a good business decision.

A lot of companies hire for 'polyglots' these days anyway. For the most part, I wouldn't want to hire someone who wouldn't be capable of picking up Elm to a decent level, relatively quickly. When mentioning that we used Elm, it usually elicited excitement.

I live in Norway, but I don't have any axe to grind with anyone. I work in the IT industry, but I'm not in the consulting business. As you probably know, Bekk has a very good reputation in Norway, and I know several people who works there now, or has worked there in the past. I do use Vy trains for my commute, and I'm not super happy with the service, but that's not my motivation for my comments.

It is more a concern regarding how the tax I'm paying is used. I understand that people are happy with Elm today. But how will it be in 5 years? Given the small Elm community, will it still be up to date then? Will it be easy to recruit then?

I know of other publicly funded projects in Norway where they ended up using non-mainstream languages, and where it became a problem in the long-term.

> I think they should have made a different choice.

Yes, you've asserted that several times here, based on next to no information.

As for recruiting, using Elm has put Vy in the spotlight several times the last years. So even if most people aren't elm developers, I think this has at least given lots of potential candidates a positive view on working there.

If you want to attract good programmers use niche languages.

You don't need any Elm experience to program Elm. Web experience (HTML, CSS, APIs etc.) is useful because they are the problems you will bump up against. The learning Elm part would take little time. There are a lot of people who have done a bit of Elm on the side too so have a head start. Any Haskell lover who can't find a Haskell job might consider an Elm job.

I think it depends on the project entirely. A starving province in market ruled society that wants to get something for as little money as possible will act differently from a rich Scandinavian nation where utilitaristic ideas are widely spread and people agree to spend more to get good things for everybody.

The experience we have with elm at my company is pretty good, actually. We have two teams staffed and productive, with no specific recruitment. All devs were trained in-house.

The language has some problems of course, but in terms of developers availability, training effectiveness makes it good.

I've cross trained a few react/redux devs onto Elm and it's been a really easy shift for them. Many js devs are leaning more on a functional style anyway, for those devs Elm gives them a language which is designed for the way they want to build apps.

Good point, hopefully someday Elm will support remote work.

I heard there’s an RFC out

Elm is simple, they can teach new developers. Note that they started out by having interns do the first dry run.

So no non-Javascript fallback for a quite important site & service?

Welcome to post 2010 :)

Yeah I do find it super weird that people do this.

I think front end rendering is well suited for internal tools or tools that you must login (gmail, google docs, etc..). Anything that is front facing and/or require SEO shouldn't be frontend rendering javascript unless you can afford a fallback with it.

It's really not that wierd. This is the first time I've seen anyone mention the lack of non-javascript support, or mention that the site doesn't work because of it.

https://www.vy.no/en does not load on Firefox, with Javascript disabled in uBlock Origin, or Developer Tools.

It also takes nearly 2 seconds for page content to appear, on Firefox with JS enabled.

Look at the source and you'll see why. It's a total mess. If you can't even read the content clearly in the source I don't know how they expect anyone without JS to read it.

An alternative worth considering to Elm is Bucklescript with the bucklescript-tea library. This project gives you a more powerful, but similar language (Ocaml/Reason) with a more direct interop mechanism than Elm ports.

Something (weird) that I noticed in many Scandinavian websites is their short domain names. I don't know the reason, but I like the fact that you can type 5 letters and access the service that you want.

For .no, I reckon it's a combination of small population and the fact that you need to be a citizen to buy one. Until recently, they were only available to organizations. There's also restrictions on the number of registered domains you can have (100 for organizations, 5 for individuals), that limits squatting somewhat.

> the fact that you need to be a citizen to buy one

Small nitpick, but you need to be a Norwegian resident with an ID number (fødselsnummer) and a postal address in Norway, not necessarily a citizen.

You made me wonder -- what happened to ulv.no and sau.no?

Probably too politically divisive.

Nothing gets Norwegians arguing more than wolf politics.

We should control greenhouse emissions by releasing more wolves into shopping malls.

In Sweden, many sites have made use of the .nu domain ('nu' means 'now' in swedish) which has led to a lot of short domain names.

The website listed two agency names "Norsk Lokomotivmannsforbund and Norsk Jernbaneforbund" (in the strike notification).

I could imagine acronyms just make more sense if long words like that are common in the country.

They are compound words similar to what you can do in German and other Germanic languages with the exception of English.

"Lokomotivmannsforbund" = "train engineers union" :)

We also commonly make up compound words on the fly making it very hard to use things like swiftkey without typing the two words and then removing the space as they are in no word list.

Train engineers union also is a compound word. The only thing different about English is that it usually writes the compounds separated.

> A common misconception is that it is risky to use a non-mainstream language, since it will then be difficult to find developers with the right experience. We have found, however, that we don’t need people to know Elm beforehand.

Are there a lot of people who actually want to use Elm tho? Seems like the real risk to me, not finding anyone interested in learning and using Elm.

From the POV of someone hiring, there's a sort of geek-magnet effect that kicks in if you start hiring for something like Elm. You get the kind of people who like learning new things, who would otherwise completely ignore yet another React or Angular dev job listing.

> people who like learning new things

Problem is that also attracts those where new technologies is not a mean but the end goal. So when they start to get productive in the "new technology" (that's now "one year old, ugh") and if the shop ain't up to the task of rewriting everything every year those people move on to the next hype baby [1]. Being a geek-magnet should be a very minor and explicitly stated short-term factor in deciding what tools and technologies to use.

[1] Yes, this is anecdotal and based on one former colleague!

Are you kidding? Pick me, pick me.

Elm is by far the best experience that I've had with any language.

In my opinion, this is a case where a supplier (IT consultant company: Bekk) uses a non-standard unpopular technology, to implement a technical solution, for a customer who is state owned and has almost monopoly (Vy/Norwegian Railways). I suspect, the reason for this choice, is to lock the vendor in. For the customers of Norwegian railways, the results is a more expensive train journey.

What's your evidence that train journeys have gotten more expensive in Norway due to this?

FWIW i am Danish and almost all of our public IT projects are done in .NET, almost always the reasoning is "more developers, more mainstream, less lock-in". Our IT projects are always hilariously belated and more expensive than budgeted. More often than not the same contractor (one of 5ish big corporations) keeps getting the same contracts from the same departments because they have pre-existing knowledge of the system they previously built (hint: this is lock-in). Now, the last part is changing somewhat due to EU tender rules, which I think Norway also abides by (they are not in EU, but are committed to complying with most EU laws)

Isn't being locked to one of five big vendors that do .NET a bit better than being locked to the vendor that does Elm, though?

The vendor lock-in is a good point... Isn't this risky for the customer? What do they gain over, say, a well-crafted React-TS SSR app, or Django or what have you? Do they really get an end-product that is so much more reliable? Is this cheaper or more efficient? What happens if there is a political fallout between the consultant and the customer, or if the customer can no longer afford them?

I mentioned this in another post. But Vy has their own developers, and the development teams here contains a mix of Vy and Bekk developers. As such, Vy has enough Elm experience to handle any future turnover.

The external consultant developers are incentivized to keep essential knowledge to themselves, in order to get new contracts later. The supplier's IT consultants (Bekk) don't share essential knowledge with the customer's developers (Vy).

We're working at the same location. On the same codebase. With the same access to our version control and issue tracker. There is full transparency. We even help Vy train their new hires.

We're incentivized to work this way because that makes the customer feel safe. Which is how we win contracts.

It might be that way where you work, but that's definitely not the case here.

In fact, I think what you suggest would be an extremely short-sighted "strategy" for a consultancy. Sure, you might get the next contract working this way. But once the customer could get rid of you they would, and they would never hire you again.

Then please answer why Elm was chosen instead of some mainstream programming language/framework. Choosing Elm seems like a very risky choice for something as important as railways.

Elm is a frontend language. Java works on the backend.

At Vy, Elm is used for frontend, Java and Kotlin for backend.

This doesn't address the issue of mainstream technology, versus bleeding-edge, obscure, niche technology such as Elm.

Kotlin in the backend isn't a mainstream technology choice either.

Elm was chosen because we believed it to be a better language than those which are mainstream right now. We believed it would make us more productive, prevent bugs before they reached production, be better at local reasoning and make it easier to onboard new people.

So far we are not dissapointed, and in my opinion Elm is on its way to become mainstream because of these things.

Rail ticket prices are decided at the government level in Norway, so this should have quite a minimal effect on those.

Also, as learning Elm is quite fast - I don't think the vendor lock-in is a very convincing argument.

Is the mobile Vy application also using Elm?

I live in Oslo and use Vy to travel outside the city. I find the overall experience to be excellent, and appreciate the friendly and simple interface.

react-native. Although the seat selector is written in Elm and loaded via web view.

A conference talk from JavaZone about rewriting the app in react-native: https://vimeo.com/362761083

Tried to use latest Elm with Websockets. It's just not ready yet but I look forward to when it is.

I was frustrated by that as well. In the end, I actually found a solution that was surprisingly easy and works well. I'm about 90% sure it was https://github.com/billstclair/elm-websocket-client, although it's been a few weeks and I can't check right now.

Hmm, personal preference but preferred the old NSB site. This takes forever to load.

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