
Tessel: The end of web development as we know it - Frijol
http://www.slideshare.net/TechnicalMachine/tessel-the-end-of-web-development-as-we-know-it
======
neya
Everyone on this thread is so dismissive about the language that they forget
to credit the accomplishments of these wonderful boards.

See, Javascript maybe a 'bad' language according to many of you, but it has
massive adoption unlike other languages. These board creators just want to
ease the path for _most_ web developers to become hardware developers. It not
only opens up a whole new industry to work with, but also it creates a good
'filter' to filter out the bad ones. I will explain.

The thing about hardware _products_ is that most people dont care about
internals. Most of them care about the experience. I am NOT an Apple fanboy,
but in this occasion I would like to cite the iPhone's sales as a good
example. If you suck at programming in Javascript, it will show up, especially
in the Hardware world, easily, and you/your product will be rejected.

Also, when you develop, say, a DSLR Quadcopter[1] with this board, people
aren't going to ask you "What language is it running on?", "How slow is your
language?". People are going to be asking about the footage you're going to
film with it. Let's not dissolve ourselves into the hatred of a language.
Instead, let's take the time to appreciate what these developers have achieved
and what we can build out of these boards.

Cheers.

[1]A sample DSLR quadcopter for reference:
[http://farm7.staticflickr.com/6225/6868828438_e6d798c68d_b.j...](http://farm7.staticflickr.com/6225/6868828438_e6d798c68d_b.jpg)

~~~
weland
> These board creators just want to ease the path for most web developers to
> become hardware developers. It not only opens up a whole new industry to
> work with, but also it creates a good 'filter' to filter out the bad ones. I
> will explain.

What exactly happened to the programmers who, upon realizing that they had to
use a new technology, _learned the new technology_ instead of feature-creeping
something until it gets to their familiar JS boat.

I'm not going to rant that this is never going to fly. Were it based on
technical consideration, the current image of Web 2.0 would have sunk like a
rock, let alone even try to fly. But this is horribly inefficient and
backwards that encouraging seems incredibly detrimental to our field.

Come on, people, it's not that hard. If you want to do embedded development, a
reasonable subset of C is all you need to know, and it certainly takes less to
learn that it took to learn half a gazillion JS frameworks. Ask your boss to
give you a one or two-week leave and give you a break from your 70 hours a
week streak, and learn something that's actually new for a change.

~~~
outside1234
This is increasingly a false choice.

If you use node.js, you have both JavaScript and native modules.

Use JavaScript for the non performance critical parts, use C for the parts
that touch the hardware, and leverage the great node ecosystem.

~~~
weland
Leveraging the great node ecosystem comes at a significant cost in terms of
power consumption, complexity of the manufacturing process, board size and of
the system itself.

Power consumption and, to some extent, board size have been _very_ significant
drags for the Internet of Everything. Mindlessly throwing libraries at them
just to help people who are too lazy to learn a new programming technology is
only adding a drag on it.

I certainly don't want to drag this into the mud. It's certainly a good
learning platform which can provide exposure to a range of devices for people
who would otherwise not even hear about them, or for whom the initial
technological barriers would be too high to overcome in a single evening. But
this is far, far from adding any kind of value to the struggle towards
universal Internet connection.

~~~
bobbydavid
If what you say is true, it's a bad sign for the future of hardware. If we
fundamentally can't leverage existing libraries, we can't build the standing-
on-the-shoulders-of-giants complexity pyramid that allows for such reliable,
rapid development in other spaces. It will always remain a niche field.

~~~
weland
Of course we can leverage existing libraries and standing-on-the-shoulders-of-
giants complexity pyramids. Slapping a webserver on them isn't necessarily a
good approach though.

------
haberman
To me the big story here is that Tessel apparently has a working JS->Lua-
bytecode compiler.

Lua has by far the smallest, most portable, easy-to-integrate runtime of any
embeddable language I am aware of. JavaScript has good implementations (V8,
etc) but they are orders of magnitude larger, more complex, and imposing if
you're linking them into your binary.

If this is truly a robust JS implementation, this means that there is now a
tiny, easy-to-embed implementation of the programming language that powers the
web. This could enable JavaScript to start making inroads in the "embedded
language" space, and really become the language of both client and server.

If it can compile to LuaJIT bytecode also, it could also possibly be
competitive in speed with other JS implementations, though some of that would
depend on how efficient the resulting bytecode can be.

I think this would actually be a cool trend. Having a code-base that can run
either in the browser or "natively" is a powerful approach. Though Lua is a
cleaner language, JavaScript is a totally decent language if you use it right
-- much better than a lot of people give it credit for. Hint: if you think JS
sucks because of browser incompatibilities, what you really hate is _bad
implementations_ of the language, not the language itself.

Of course another approach to achieve "one language" would be to have a
Lua->JS compiler (or Lua->asm.js, or a Lua interpreter in asm.js). But Lua the
language is a bit more of a moving target; to preserve cleanliness and
orthogonality they sometimes break the language in non-backward-compatible
ways.

~~~
Derbasti
But why not use Lua itself then? It is a very elegant, beautifully consistent
language. In a way, it is JavaScript Done Right.

~~~
seldo
To repeat my own comment from a few week back (
[https://news.ycombinator.com/x?fnid=rYqgO4wMtljd4zBdfWM3wt](https://news.ycombinator.com/x?fnid=rYqgO4wMtljd4zBdfWM3wt)
): because enormous numbers of programmers already know JavaScript, and
familiarity trumps + libraries being available trumps every other
consideration when choosing a programming language, according to actual
research (
[http://www.eecs.berkeley.edu/~lmeyerov/projects/socioplt/pap...](http://www.eecs.berkeley.edu/~lmeyerov/projects/socioplt/papers/adoptquant.pdf)
).

This is why the presentation keeps talking about web developers. There are
more web developers than there are _any other kind of programmer_. If you want
to make your programming platform accessible, make it accessible to web
developers.

~~~
taude
Is it really this hard for devs to learn proper languages for whatever they're
doing? I almost think knowing multiple languages and having the ability to
learn new ones quickly is what it means to be a programmer/developer, etc...

I'd be more interested in what embedded JavaScript would allow to be done that
other existing tools can't currently do. After all, if you're a JavaScript
person and you needed to do something on a device or platform, you wouldn't
wait for a language runtime to become available, you'd just go learn the
existing language/tools and build it?

~~~
ubernostrum
_Is it really this hard for devs to learn proper languages for whatever they
're doing?_

It's not hard.

But given a choice between Platform A which says "write in a language that all
of you already know", and Platform B which says "write in this language most
of you don't already know and would have to put in time and effort to learn
before you could do anything useful with this platform"... which one would you
bet on?

~~~
plaguuuuuu
Not sure what sort of crack everyone else is smoking, but I generally base my
decisions on how painless it is to develop for a new platform rather than one
I already know. Other than that, if I don't know the language, but the
environment really kicks ass, I'm going to learn the damn language.

Unless I'm really rushed and have 2 days to do a vast amount of work.

~~~
kristiandupont
Well how could you possibly know for a platform that you have no experience
with?

------
shadowOfShadow
Look, we can bolt training wheels to embedded!

This is all fun for sparking creativity, but it always seems like a massive
diss to the EE's in the crowd when web devs run around fronting that they are
going to disrupt the embedded world with their transpiled bloatware. EEs are
so stupid and use such crap tools!!! Put some damn Bootstrap on that circuit-
to-PCB layout tool. It's so not even flat OR responsive! How the fuck am I
supposed to drag-n-drop my codez?!?!?!

My favorite is when someone posts a vid of LED PWM or, worse, just basic
blinking... You spent how much time and money on what? And you created the
embedded version of the blink tag? Definitely a web developer.

Tester board acquired. Let's go find some problems!

Can't wait until craigslist is full of requests for bringing a dream device to
fruition... It'll be an iPhone-killer that also sets the temperature of your
house and blinks to let you know your dog bowl just tweeted you and donate a
bitcoin to the NSA because you forgot to put the induction recharger next to
the eFacuet controller this morning. Equity only. NDA required.

One person converts an arduino or whatever to a red-inked start-up that gets
taken out for $1B and it's on...

~~~
ramblerman
History and Moore's law would tell us that at some point we won't have to
fiddle bits for every single embedded project.

Is that time now, maybe not. But it seems like a great tool to prototype with.
I'm really confused how enabling a whole legion of programmers to get creative
with hardware invokes such bitterness in you.

I'm sure what you do is very special, and this is no direct threat to that.

~~~
kamaal
And history of embedded systems tells us that at all times you _will_ have to
fiddle bits for nearly all embedded projects.

MCU's are getting faster at the expense of getting power hungry. Plus there
are a several other things that need low level optimization that C provides.
There is a reason why C has such a invincible death grip in the embedded
domain. It will take you trillions of dollars worth of investment and nearly
two decades of effort if you have to dethrone C from there. Nearly every stake
holder, is so deeply entrenched in C its not even pragmatic to think you are
going to replace at anytime sooner.

>>I'm really confused how enabling a whole legion of programmers to get
creative with hardware invokes such bitterness in you.

All programming, is creativity with hardware. Because the form factor got
smaller doesn't mean a thing here.

This is the gripe I have with many Rasberry Pi Users, who call printing hello,
world 10 times with a python script as 'hardware hacking'. The situation is so
super hilarious.

Say you wrote the same Python script on a laptop with the cover removed, now
that you see the electronics inside the laptop and you are also running the
python script, did you just got magically creative with hardware? Why wasn't
it magic when the electronics wasn't visible.

And yes, for any real creative thing of production and mass deployment value.
All the best trying to do it in anything apart from C.

------
noonespecial
Long ago embedded systems were a pain. You programmed eproms with ASM and UV
lights were involved. Someday the computorium will be so strong, cheap, and
ubiquitous that you can program it with whatever you want. This isn't that
day.

I applaud the spirit of what they've done, but that's a shrinkified version of
a rack server, not a smartened version of a light-bulb. The Internet of things
is more about swarms and emergent behaviors and less about turning everything
into a tiny stand-alone version of our datacenter servers.

~~~
ChikkaChiChi
Consider this more a web API to GPIO instead of just a web server and you can
see the inherent value.

~~~
noonespecial
I get it. And its a start. But its so huge and expensive its like considering
the rest of the car an API to a tire.

That's a crap-ton of computer and the sysadmin that goes with it to flip a
switch. I don't have a beef with programming the 'net of things in java or lua
or even pascal. What I'm saying is that that's way too much computing too far
down the stack. The closer we get to the GPIO pin, the less computer, expense,
and electrical requirements there should be.

I'm just saying that the thing that should be hitched to the actual GPIO pin
ought to look and function more like an RFID tag and less like a mini rack
server.

~~~
lifeisstillgood
I cannot agree (I mean I do from a pure techie point of view) but last week I
got my hands in a Raspberry PI for the first time and knocked up a traffic
light demo for a school in Python, with LEDs directly shoved into the ribbon
cable.

I have not been so child-like excited for years.

by throwing a wasteful amount of computing power into just turning on a light,
we put this in the reach of more and more people.

we could have web servers in assembly language, and it would be more efficient
use of computing resources - but that's not been the optimal way and it won't
be here either

~~~
grego
Hey, this is just one of the necessary steps towards Marvin the Paranoid
Android, or perhaps the sentient door...

~~~
lifeisstillgood
all of which will exist in 42 years of course

------
auggierose
I can understand the motivation. But not sure if I want to be surrounded by
hardware powered by software written by people who think that Javascript is
actually a good programming language.

~~~
nl
I'm one of those who think Javascript is a good programming language (or at
least I'd prefer it to any functional language).

Javascript is basically Scheme/Self with a C-based syntax[1][2], and both
Scheme and Self are well regarded.

It has a bad reputation because of the terrible code people write using it in
web browsers, but as languages go, it's pretty nice.

Browser/DOM APIs OTOH are historically pretty awful.

I suspect many of those who think it is terrible do so based n language
snobbery, or they cannot separate the language from what it has been used for.

I may well be wrong, though - what _actually_ makes it a bad language in your
opinion?

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

[2]
[http://www.ecmascript.org/es4/spec/overview.pdf](http://www.ecmascript.org/es4/spec/overview.pdf)

~~~
Derbasti
That meme "Javascript is basically Scheme with a C based syntax" has been
refuted so many times it's not even funny. Does it have a metacircular
evaluator? Is it homoiconic? Does it have macros? Seriously, read SICP or some
other Lisp book. You have no idea what you are talking about.

~~~
TheZenPsycho
And yet you haven't cited even one refutation.

Javascript has first class functions. It has closures. it has nice
object/literal syntax. If you don't consider it cheating to use a library, it
does have macros if you use sweet.js. It has a metacircular evaluator, from
the very beginning called "narcissus", and if it had homoiconicity, it would
be even more direly hated than it is now. Having syntax, for better or worse,
is a strength that means that people actually use the language. For reals. Not
just that one time at college.

The real question is how are any of those features actually useful from
anywhere but a theoretical purity standpoint? We're not exactly writing AI
systems here. At the end of the day the language is there to write programs.
And the sophistication of the programs you _need_ to write in javascript
doesn't really need those things most of the time.

~~~
Derbasti
Probably one of the best written ones:
[http://journal.stuffwithstuff.com/2013/07/18/javascript-
isnt...](http://journal.stuffwithstuff.com/2013/07/18/javascript-isnt-scheme/)

But basically, ask anyone with Lisp experience. Only JavaScript people without
Lisp experience argue that JavaScript is Lispy.

~~~
TheZenPsycho
That's one. Not "so many it's not even funny". From the sound of it, you
should have been able to rattle off 5 without hesitating. Maybe you meant
"one. There's exactly one refutation"

as for your second remark, uh... Douglas Crockford?

~~~
Shamanmuni
Douglas Crockford just said that even though Javascript's syntax resembles an
imperative language like C or Java, it's much more similar to a functional
language like Lisp or Scheme. From that comment a whole myth began which
states that Javascript == Scheme. That's like saying Java == C just because
both are imperative. Handwavy and completely wrong.

What you should take from that assertion is "Javascript is more functional
than imperative" (which is correct) and not "Javascript is lispy" (which is
not).

~~~
draegtun
Mark Jason Dominus also says the same thing about Perl in his _Higher Order
Perl_ book [1][2] and goes onto show that Perl has 6 of the 7 features that
Norvig describes has making Lisp different [3].

[1] [http://hop.perl.plover.com](http://hop.perl.plover.com)

[2] _Perl is much more like Lisp than it is like C_ (from Preface)

[3] _... the book "Paradigms of Artificial Intelligence Programming", by Peter
Norvig, includes a section titled "What Makes Lisp Different?" that describes
seven features of Lisp. Perl shares six of these features; C shares none of
them. These are big, important features, features like first-class functions,
dynamic access to the symbol table, and automatic storage management._ (also
from Preface)

------
adpreese
Every time I see a thing about the internet of things, I get a little excited,
but then they don't really show exciting examples of what you should do with
it. Outside of Lockitron and Nest, I am unimpressed with what's come out so
far. But it's tough. The field seems so expansive that most people get
overwhelmed with possibilities, but few bare any fruit. For my part, I've only
had one decent idea in the space. I'd love to see a robot that cooks food for
me while I'm commuting home. Possibly like a Zojirushi rice cooker that I can
program to make stuff at a certain time, but with more flexibility and a web
API.

~~~
woah
Mechanical engineering is really hard. Getting injection molds made is really
expensive. 3d printed stuff is janky (right now).

~~~
judk
Injection molding is the cheapest process on the planet, if you have a
production run of >10k for a mass produced product. It is hard to find
anything on Earth cheaper than an injection molded object.

~~~
adpreese
That's a big damn if though.

------
yogo
I fail to see the connection between the end of web development and using
javascript to write code for hardware (something that has been done a long
time ago).

~~~
TheZenPsycho
It's a marketing slogan. Marketing slogans don't have to make sense, they just
need to bait your clicks _cough_ I mean get your attention.

~~~
dman
Fool me once ...

------
ChikkaChiChi
Tessel is another good idea that will help the DIY homebrewers to relate their
existing skillsets into prototyping fresh ideas to a growing market segment.

If you object to javascript being used, by all means go back to building your
555 timers by hand or feel free to construct a competing unit in whatever
religion...I mean language...you feel is the one true answer.

~~~
xerophtye
exactly! This is a good effort and if people have a problem with JS, why not
make something like this in their language of choice? I mean i understand why
people are hating on JS for this application, but I don't think "robust,
mission critical systems" are the aim here. this is just for hobbyists and to
let a larger number of people bring their ideas for life. Once you get those
ideas out in the open, use some of u veterans could make it in a "proper"
language. Currently people dont program embedded systems because the task
seems daunting. This project is just an attempt to remove that initiating feel
of hardware. Their motto is "Don't teach webdevs abt hardware, teach hardware
about webdevs!" and it's a pretty nice way to bring a massive number of brain
power to the domain of embedded systems that interact iwht the internet

------
goshx
Kudos to these guys that are doing something different. I am sure a lot of web
developers out there will be more than happy to try creating new things on a
completely different field using their current skills. Seriously, thank you!

It is so easy for the people here to criticize and make a lot of judgements
over a few slides and their lack of knowledge of how things work in your
product. Don't listen to their prejudgement, these people are obviously not
your product's target.

~~~
ChikkaChiChi
I'd say the title is a bit much, but otherwise I couldn't agree more.

There seem to be a lot of close-minded commenters on HN on the weekends.

------
flyinglizard
For me, this has a pretty narrow appeal:

1\. For most people, Arduino would be easier to use (being that many Arduino
guys are non-programmers to begin with), with a great ecosystem and a variety
of hardware.

2\. On the other hand, no one would ever use this hardware for an actual
product. Cost is too high, power consumption - I assume - is also up there.

3\. As opposed to Arduino, this is not a "hard" real time system. It's
severely limits the development of applications featuring, for example, motor
control or orientation sensing (gyros/IMUs). And from what I'm seeing, even
Arduino didn't make great strides in the commercial market; product
development often requires very precise level control over your hardware as
well as real development tools (namely a JTAG debugger).

So we're left with an interesting experiment, the longevity of which mainly
depends on the community acceptance. It basically targets web developers that
want to turn LEDs on and off. This is as far away from the "internet of
things" as one can imagine, unless these things are one-off hobby projects.

Yes, embedded development sucks, and product development can be an exercise in
futility and despair - but this is not the answer.

~~~
Schwolop
I entirely agree. I'd much rather be tied into someone else's ecosystem with
an electric imp or Xively, than have to work with hardware designed by people
who think the software is the difficult bit.

------
plorkyeran
Why compile JS to Lua bytecode rather than just using Lua directly? Lua is
very similar to JS, except without a lot of JS's warts.

~~~
nrubin
I think the appeal is that web developers won't need to learn another language
in order to do embedded development. That's another barrier to entry to
embedded development lowered.

~~~
pekk
If you want to do new things, why not learn appropriate ways of doing those
things? Is it really so hard to use more than one language when that makes
technical sense?

~~~
bigiain
As a member of a small startup (4 person technical team, all of us holding
down day-jobs as well), the _prime_ decision trigger for technology is "what
'way of doing things' is the person allocated to a particular task going to be
most productive in right now?". That's driven us in some directions that're
non-obvious to outsiders - our stack is basically ARCH Linux, CherryPi,
Python, Arduino, HTML5/JS - I can easily see people thinking "WTF? Why?", but
there's some very good reasons behind those decisions - reasons which have
probably allowed us to get to market 6 months earlier than if we'd chosen the
stack based purely on technical merits rather than considering the skills and
competencies of the existing team.

If we'd had corporate funding behind us, it'd almost certainly be different.
But as a small startup, I'm 100% sure our slightly odd choices are the right
ones for us. (And I could easily see why a different startup might decide
node.js/javascript on the hardware was the correct choice for _their_
technical/development team)

~~~
BWStearns
This is perfect logic for a small startup, it is less so for a hardware team
that is going to be pay dearly for changing decisions they make today (moreso
than a software team). Hitting a big ecosystem is definitely a viable reason
to do something when targeting developers, but what about the longer term
costs associated with it? Their goal is to be the bridge that lets web devs
start bringing hardware online. I think it's fair to say that other less
painful languages with large developer bases were available, and some have the
holy trinity of sucking less, being able to run faster, and having a
sufficiently large ecosystem around them.

~~~
bigiain
FWIW, we _are_ a "hardware team" as well as a software team - and we're fully
aware of how much some of our decisions might cost us down the track if we
don't get things right enough" today… (details masquerading as shameless self-
promotion [http://holiday.moorescloud.com](http://holiday.moorescloud.com) and
[http://dev.moorescloud.com](http://dev.moorescloud.com) ))

~~~
BWStearns
Admittedly my comment (as most comments on the internet) was a bit of armchair
generalship. I honestly wish you guys the best because it's a cool concept.
Would you guys consider building something for programming in Lua directly as
an alternative to the JS to Lua bytecode conversion?

I just wish it hadn't been in JS, partially for the selfish reason that JS
inexplicably makes me un-focus in a way that no other language can (it might
be the formatting? honestly don't know why).

~~~
bigiain
So I (and "we" in my posts upstream) are not the original posts JS hardware
team.

(FWIW, on _our_ hardware, flipping the "dev mode" switch to "on", ssh-ing into
your xmas tree lights, uncommenting the ARCH/ARM repos in mirrorlist, and
running "pacman -S lua" should just work. The API for our compositor (which
abstracts the fine timing details of controlling the WS2812 LEDs) is available
and documented both on our dev site and on github (or if it's not today, it is
scheduled to be up there by next week I think).

------
callmevlad
Atwood's Law [1] seems to be holding up so far:

"Any application that can be written in JavaScript, will eventually be written
in JavaScript."

[1] [http://www.codinghorror.com/blog/2007/07/the-principle-of-
le...](http://www.codinghorror.com/blog/2007/07/the-principle-of-least-
power.html)

------
thomasreggi
I hate the title of this slideshow. It should be "Opportunity for web
developers to integrate hardware into their routine".

~~~
digitalmaster
agreed.

------
spullara
This was done years ago and is running on 8B+ devices:

[http://www.oracle.com/technetwork/java/embedded/overview/get...](http://www.oracle.com/technetwork/java/embedded/overview/getstarted/index.html)

Java is pretty simple. I think that someone that can program in Javascript can
handle it.

------
alexatkeplar
Having written software for Arduino[1], I see this initiative succeeding for
two main reasons:

1\. JavaScript means developers don't have to understand manual memory
management to program their hardware (and many developers simply _can't_ grok
manual memory management these days)

2\. node.js gives access to the npm package ecosystem - which opens up a huge
potential "common lib" to hardware developers (potential because
incompatibilities e.g. node.js network support vs luasocket will need to be
handled)

Hardware hackers are generally a very curious bunch - they're not afraid of
learning a new language on the software side, so it's not really _JavaScript_
per se that is Tessel's advantage here.

Straight to Lua could have been a second choice, but the package ecosystem in
LuaRocks is hugely immature.[2] Because Lua execution in a LuaRocks-supporting
environment is the exception, not the norm, most developers continue to
manually bundle dependencies[3], which again doesn't encourage the package
ecosystem to grow.

[1] [https://github.com/snowplow/snowplow-arduino-
tracker](https://github.com/snowplow/snowplow-arduino-tracker) [2]
[http://luarocks.org/repositories/rocks/](http://luarocks.org/repositories/rocks/)
[3] [https://github.com/snowplow/snowplow-lua-
tracker/tree/master...](https://github.com/snowplow/snowplow-lua-
tracker/tree/master/src/snowplow/lib)

------
thomasfl
How is this board compared to Espruino[1], Johnny Five[2] or other aurdino
implementations that can run javascript?

1: [http://www.kickstarter.com/projects/48651611/espruino-
javasc...](http://www.kickstarter.com/projects/48651611/espruino-javascript-
for-things)

2: [http://makezine.com/2013/07/20/javascript-powered-arduino-
wi...](http://makezine.com/2013/07/20/javascript-powered-arduino-with-johnny-
five/)

------
BigChiefSmokem
If hardware doesn't require a traditional web UI then why even use JavaScript?
Did we all suddenly forget the history of why we even have to use JavaScript
on the web. Here's a hint: the web browser. I don't use it cause I like it, I
use it cause that's what we were forced to standardize on. There are much
better languages and frameworks out there we can use for this.

~~~
randomdata
Familiarity. If you are someone who builds traditional web UIs, then
Javascript is what you know best, and that is the market segment they are
trying to attract what this product.

If people truly want the better languages and frameworks that you mention,
then the products that come out with those choices should win out in the
marketplace eventually.

~~~
zxcdw
Except that no. Because of players within the market entrench themselves, like
JavaScript for example has, there's practically no way for a change.

The iterative change is constantly restricted by past decisions, abstractions
and investments. It's very hard to come up with nothnig but "good enough, sort
of" solutions in this kind of a model.

I don't even know why I care. Psychology is a bitch, and I suffer. :(

------
marcamillion
This is awesome. I have always been interested in hardware programming, but
always hated the languages I had to learn to do it properly (java, c++, c,
assembly, etc.).

Technology is reaching a place where I can eventually start doing embedded
programming with Ruby. I can't wait for that to happen - I am sure it will.

Makes me very excited for the next 10 years.

~~~
easytiger
> I have always been interested in hardware programming

Ok.

> but always hated the languages I had to learn to do it properly (java, c++,
> c, assembly, etc.)

Then you weren't interested in hardware programming; not one iota. You were
interested in playing around in fashionable languages.

~~~
TomAnthony
> Then you weren't interested in hardware programming; not one iota.

That is a bit of a leap. I read what (s)he meant as more "interested in
programming hardware" \- as in controlling hardware and making it do things.
That doesn't mean you need to be interested in the low-level hardware side of
things to be interested in making the hardware do stuff.

~~~
easytiger
Failing to learn what it takes to solve a problem you have is not a viable
business case. One doesn't simply decide:

"no this product i want to exist is impossible because I can't be bothered
learning something new or because I have a non-technical and non-financial
hipster-hued-bias against the existing commoditised technologies that lead me
be able to solve the problem."

~~~
marcamillion
I have no idea what you are talking about here.

Who said anything about solving problems? Viable business cases?

~~~
easytiger
if you have something you need to get done for work or otherwise, you use the
most appropriate product.

if you "want to learn about hardware" you use the tools and resources that
presently exist or make you own. Otherwise you do not want to learn about
anything, you just want to screw around so you can tell your boss you are a
hardware expert in ruby or some bollocks.

------
louischatriot
So many negative comments so let's say it loudly: this freaking rocks. Massive
kudos to the team.

Maybe the performance is not yet on par with C. Maybe it will never be. But
using JS means we can use this for very rapid prototyping and move on to C
when we do need the performance.

The people complaining about performance are the same ones who build very fast
and scalable products that nobody uses.

And about JS, let's remember there are two types of programming languages: the
ones which everyone complains about, and the ones nobody uses.

------
ricw
Being in the hardware business myself, I can only laud their attempt of
simplifying and easing access. However their approach only solves a basic
problem that already has been solved for quite a while (access, look at the
likes of arduino, contiki os, rasperrypi). The much much harder and real
problem is developing a coherent system for 'everything'/'the internet of
things'. and others, particularly contiki, are much more advanced when it
comes to knowledge, development state and commercialisation. So in short: I
want to see product before I am impressed. Other than that I see little
novelty and a bad choice of programming language for embedded dev..

------
cbhl
For the longest time I was wondering how they were fitting node.js in 32 MB
RAM when V8 uses something like 256 MB of RAM. I'd never have expected cross-
compiling to Lua bytecode.

------
ati
There are three main problems in the "internet of things" field:

1\. The lack of consumer grade sensors that can detect human presence and
behavior patterns.

2\. The lack of robust models and open source software describing patterns of
human interaction with environment.

3\. Insufficient and incomplete solution to power supply and interconnection
problem.

I see any advance in these fields an order of magnitude more important than
any new board running [modern language interpreter].

~~~
camus
People are not going to make hardware for hospital with that dont worry,it's
like 3D printers,it is for hobbists / artists...

I dont think the point is really the "internet of stuffs". Just to fool around
or to do installations or prototypes.

I dont like the NodeJS logo ripoff though.

------
goshx
Watch their video here to understand the product a little better:
[http://www.dragoninnovation.com/projects/22-tessel](http://www.dragoninnovation.com/projects/22-tessel)

------
hardwaresofton
Not that this thread needs any more opinions, but I think it'll work, because
the market and the people who want to build stuff with it are there.

No matter how flawed their concept might be, or how shitty JS is as an
embedded language, people are out there that want to run with this idea. And
when they run with it (one of Tessel's major goals seems to be getting their
users to be able to get up and running fast, to boot) -- things will get made.
When things get made, lives change, markets get shaken up, simple as that.

------
smoyer
The theme at this year's JavaOne was (once again) The "Internet of Things"
(IOT) and the community keynote address was by Freescale's CEO who proclaimed
that the price of an Internet connected (or connectable) uC would need to be
about $0.30 (US). At that price point, I can see a world where everything is
Internet enabled. Of course, the devices we were discussing were all running
Java.

Tessel looks like another implementation that attempts to bring the same
technology to another demographic. Their fancy new system (the developer
doesn't touch the Lua parts), should have a broad appeal and running NodeJS
provides a lot of room to extend the system in the directions needed.

I see a couple problems with IOT and another that's more specific to Tessel
... if these problems have been addressed, perhaps I haven't noticed! Tessel
is based on Javascript, but there is no standard for interacting with hardware
(performing I/O) in Javascript ... I think the eco-system would be healthier
with a whole slew of companies like Tessel, but is anyone working on this
standard? The IOT problems are more social (since we have uC that connect to
the Internet today). 1) Are we ever going to take the security of devices that
cost pennies seriously enough? You might not care if your water heater is
rigorously protected when Internet connected, but a few thousand of them that
are programmed to turn on at the same time is an issue for the power company.
2) Do I want everything around me to be that "aware". Privacy can be lost in
little dribbles and we've seen our increasing power to correlate this data
into your identity.

------
senthilnayagam
I can tolerate JS, but they should also offer a direct way to code and deploy
in Lua as well

------
ausjke
So the whole point is to compile JS to LUA bytecode, the rest is pretty common
in all those IOT-related kickstarter projects these days. I would expect four
PHDs from MIT to make JS to LUA compilers,even then, why not just use LUA
directly, all language has its shiny spots in the real world, in this case,
why do I need use JS at all? is LUA that hard to use or should we really use
JS for everything?

------
div
Great slidedeck. Most of the comments here seem to be missing the point that
step 1 of 'the plan' is to make hardware more accessible.

With that background, complaining about javascript is a very "No wireless.
Less space than a nomad. Lame." remark.

I haven't dabbled with any microcontrollers before, but if I ever felt like
it, Tessel would be on top of my list of things to try.

------
its-a-trappist
To the Tessel team: please do not allow the negativity reflected in the above
comments to deter you. You're onto something. Enabling 20,000,000 JavaScript
developer to take the jump into physical computing is huge.

One suggestion: there are now several successful platforms for prototyping
embedded systems: Arduino, Raspberry Pi, Beagle Board/Bone, etc. What has yet
to emerge is a platform that is actually viable for low volume production. If
you want to be truly disruptive, find a way to build the other components that
are necessary to create real solutions: 12 volt interfaces that can be plugged
into a car's accessory port and fire up when the car starts and can cleanly
shut down when the power cuts; cases that not only mount the Tessel and its
daughter-cards securely, but which pass standard RF emission tests; simple but
secure methods for updating firmware on production systems. Make something
that not only helps people get started, but helps them to build a business.

------
adamb_
After seeing HN posts such as "Why hardware development is hard: Verilog is
weird"[1] I can see the value of trying to make hardware development more
approachable and less niche... And JavaScript is anything but niche.

[1]
[https://news.ycombinator.com/item?id=6347848](https://news.ycombinator.com/item?id=6347848)

~~~
boomlinde
To be fair, this won't exactly ease hardware development in any sense that
Verilog or VHDL do.

------
kybernetyk
And there I was thinking someone finally had created webdev tooling that made
webdev more bearable and more like other software engineering disciplines.

Only to find out that it's about yet another hardware board with a bloated
software layer so people don't have to deal with pointers.

Meh. Sorry for being grumpy but I haven't had my morning coffee yet.

------
p1mrx
The Texas Instruments CC3000 contains an embedded IPv4 stack, with no support
for IPv6:

[http://www.ti.com/lit/ds/symlink/cc3000.pdf](http://www.ti.com/lit/ds/symlink/cc3000.pdf)

If you're trying to build the Internet of Everything with 40 billion devices,
you're using the wrong equipment.

------
stinos
_electrical engineering tools really suck_

No they generally don't. They are just pretty hard to use but once you get
over the learning curve they are just as easy as any other program. Yet of
course you still need the electrical engineering knowledge to create something
useful with it.

Apart from that: neat ideas.

------
mistercow
Actually, I think this is the end of hardware prototyping as we know it. And I
feel fine about that. This seems like an excellent way to prototype wireless
devices before creating a more optimized design.

That said, I don't think it's going to replace said optimized design. There's
a big difference between using high level languages on general purpose
computers, and using it on embedded devices, and that difference is marginal
cost. The marginal cost of distributing a program for a general purpose
computer is independent of the performance of the program. The marginal cost
of distributing a program that runs on a device you are selling is strongly
dependent on the performance of the program. The slower your program, the more
expensive the hardware you have to put it on.

------
knappador
"You don't. You teach hardware about web developers."

I mean I hate the limitations of C macros and the esolang that C++ can become,
as well as facets of every language, but seriously, if language is a barrier
then how did anyone learn javascript? It's been said that JS is one of the
languages that people think they don't need to know in order to use. Every
language is like this, honestly. You write hello world and abstract away from
there.

Look at it, clearly, without surrounding distractions:

\---Nobody, I mean nobody, thinks they need to know JS before they start using
it, and lo and behold everyone, and I mean everyone, can learn to use it---
What a phoking coincidence!

To some degree isn't the community holding itself up by pretending JS is a
security blanket instead of _cough_ that thing that Node is written in that is
apparently graduating to a real language? Is anyone going to get absolutely
worse at JS when it becomes totally real?

Now, when it comes to setting some pin to hi-state, it becomes very important
to be able to execute some instruction to move some register value to some
memory address. Do it once. Put it in a C function. Bind C function into
Cython. Call Cython from Python. You never have to do engineer your code
precisely once you've given the low-level part an API into a high-level
language. Let me think about the barrier to entry into writing Cython.
Serously, it takes 5 min. Reading the documentation on calling the function
that does that thing you need to do takes 5 min.

An understanding of the device and its limitations becomes very helpful when
it's breaking. That's something I don't want to figure out from the Phonegap
API. I want to reduce my problem to hello world in C, the world where nothing
happens if I don't do it, the clear void from which a single expression can be
tested without a complicated data-model below it. VM's don't tell you about
real devices. I'm not asking anyone to get their RAM emulator out, but can we
get over this BS about JS and web being something for everyone but all that
code architecture stuff being only for people who double-majored EE and CS?
Study a line of brainfuck. Read a minimal program written in LLVM IR. Write a
program that outputs '1'. You're programming in that hard stuff. I assure you,
you didn't just give away four years of your life and 50k in student loans.

Meanwhile JS/HTML/CSS, while ubiquitous, suck pretty hard. JS is the least
sucky. I hate HTML like I hate metastasizing pancreatic cancer.
<hello><twice><everything/></hello></twice>. CSS, that language that accepts
no math because expressions are hard and Photoshop is easy so only programmers
end up using CSS and designers who would benefit from something easier can't
be bothered to even learn that(!?!?!?!).

I maintain an application framework that uses data-binding in a terse format,
Cython for fast/low-level things, and Python for the development API. AMA. =D

I do want to add on top of this criticism that I was impressed by the work and
do applaud the pro-activeness going on. Openness and accessibility are very
important. I just think it's very important to constantly, persistently, call
"nonsense" at perceived barriers that prevent the community from bootstrapping
itself in any way whatsoever. There is a way. It's okay to say JS and C++ are
both crap. It's not personal. We can all learn tons of languages and have that
one that we use to think in.

------
JungleGymSam
Where is the video version of this presentation?

------
poxrud
You can run node on raspberrypi. I don't see how this is so much better.

~~~
outside1234
its theoretically lower power consumption - that is a bit issue in embedded.

~~~
diydsp
probably faster bootup time and smaller too. also RPi has no analog inputs.
the cortex M3 has decent analog in.

I'm with the 1% of EEs who have no major issues with Tessel... except that
I'll be facing 1000s of friends who want me to write device drivers for
peripherals that aren't in the stock lineup. :)

------
_pmf_
The tone of the presentation is like this: "Hurr durr, look at the dumb EEs,
using bits. They probably even design and validate their stuff before
implementing it, how retarded and un-agile!"

------
JeanSebTr
Let them choose the wrong language for the task as long as the hardware is
open. Is it open ?

In fact, I think it's what the "internet of things" needs: many open & low
cost hardware.

~~~
nrubin
Yep,

[https://github.com/technicalmachine/tessel-design-
docs](https://github.com/technicalmachine/tessel-design-docs)

------
fieldforceapp
Just backed it, and I think it's a great idea -- because of npm, and I
actually develop in Lua (game scripting...).

I think the commenters here are missing the point: this is a _great_ system
for prototyping. Perhaps as software developers, we take prototyping for
granted (too damn easy?) but prototyping in hardware is a huge business and
this board is great idea.

[http://dragoninnovation.com/projects/22-tessel](http://dragoninnovation.com/projects/22-tessel)

------
clavalle
Sounds like what WigWag is doing with device.js[1] only not as mature.

[1] [http://devicejs.org/status/](http://devicejs.org/status/)

------
cobookman
Why go with WiFi instead of bluetooth? Wifi is hard. If I was to give a tessel
to a friend pre-programmed, how does he enter his wifi SSID/Password?

Bluetooth avoids all that. Use a smartphone as a proxy to the web. If he
doesn't have a smartphone, you could even use Twilio with MMS to send data to
the 'cloud'.

Other than that, really cool idea/product. Heck even though I'm a compE I will
always choose JavaScript over C/C++.

------
theon144
I don't want to be a naysayer, but isn't this just another Internet Of Things
board for the umpteenth time? I fail to see how it's anything new.

------
nathansobo
JavaScript is fine. We could do a lot worse. We could also do a lot better.
The point is that regardless of arguments hypothetically better languages, we
are converging on a ubiquitous scripting language, and its name is JavaScript.
If you don't like it, use ClojureScript or CoffeeScript or whatnot. Resisting
the inevitable is only going to cost you time and mindshare.

------
frozenport
Tool's aren't the problem, I think most system level developers in industry
are busy doing 'real things' to solve 'real problems' to care much about
bringing about the Web-of-Things. They would rather build a sate-light
communication link then get paid 50% more to program a toaster. Arduinos are
much easier to use then JS.

------
stigi
Off Topic: What's that August device they keep mentioning? I'm having a hard
time googling for it. Thanks!

EDIT:

Finally I google reverse image searched and found it's the August Smart Lock:
[http://www.august.com](http://www.august.com)

Just adding a .com to the august would have done it as well ;)

------
MildlySerious
Why all the bashing? If you don't want JS controlled hardware, use the
Raspberry PI or an Arduino. It's an alternative, with a different approach
directed towards people with a different skillset.

The successful funding shows that there are well enough people interested in
this.

------
reustle
Tessel has been on a pretty strong marketing push ever since the Espruino
funding page went up.

~~~
buro9
It's worth giving Espruino their credit:
[http://www.espruino.com/](http://www.espruino.com/)

The campaign was massively successful and a lot of devs I know are excited by
it and have ordered 1 or 2 to play with. We've even ordered a couple for the
office just for our devs to play with when they need distraction from their
work.

~~~
reustle
I'm actually more excited about the espruino. I ordered one early on as well
:)

------
andyjohnson0
_" I'll often drop down to node.js if I really need to be close to the metal"_

[https://twitter.com/shit_hn_says/status/234856345579446272](https://twitter.com/shit_hn_says/status/234856345579446272)

------
philipn
This is certainly interesting, but this title couldn't be more hyperbolic
link-bait if it tried, especially since content has nothing to do with "the
end of web development as we know it."

------
EternalFury
Why go through JavaScript at all? Why no write what you need in Lua?

------
dlitz
Everyone is talking about the Internet of Things. I wonder when we're going to
start talking about firewalls harm the Internet by breaking end-to-end
connectivity.

------
thesz
This thing will be non-optimal in terms of energy use.

Apple allows for JS in iPhone because they need to have it anyway. Anyone else
should do better. At least, no JIT.

------
websitescenes
Arduino for web developers!? I'm sold. I have been working with other boards
and dreaming of something like this and here it is! Thanks

------
itsuart
Hardware programming in a language, that doesn't even have ints? I would call
that nice joke, but I fear they are deadly serious.

------
Fizzadar
All I hope is that you can write code in Lua directly, rather than the far
inferior JavaScript.

------
hbbio
Is the js to lua(jit) compiler available?

This would enable to write nginx/lua applications in javascript.

------
hhuuggoo
wouldn't js -> llvm be an easier approach?

------
otikik
Plain Lua FTW

------
thenerdfiles
What is a Mind but a set of actively constructed fabric of neuro synaptic
pathways unfolding a maximally-normalized unit-norm?

