Spreadsheets are one of the most important format that stores and calculates data, and are also key components of products that focus on online document.
In this blog, we will see how to create a rich-featured javascript spreadsheet in just 10 minutes.
This is what it will look like when you finish:
Setup
Let's start by creating an empty project with create-react-app
If you already have a react project, you can skip this step.
npx create-react-app my-spreadsheet
or if you are using yarn
yarn create react-app my-spreadsheet
Then, go into my-spreadsheet folder, install our spreadsheet library
# using npm
npm install @fortune-sheet/react
# or using yarn
yarn add @fortune-sheet/react
Using the library
Replace src/App.js with the following content
import { Workbook } from "@fortune-sheet/react";
import "@fortune-sheet/react/dist/index.css"
function App() {
return <Workbook data={[{ name: "Sheet1" }]} />
}
export default App;
Add the following lines into src/index.css
html, body, #root {
height: 100%;
}
Great, all things are set up!
Now, start the project by running
# using npm
npm start
# or using yarn
yarn start
and there you go!
You can play around it and try the features.
Next
In the next blog we will show you how to persist sheet data and make it collabrative, which will end up like this:
The spreadsheet library is completely opensource, for more information, check out
https://github.com/ruilisi/fortune-sheet
It is under active development, feedbacks are appreciated!
Top comments (10)
10 lines of code, plus the thousands of others imported
Coders At Work: Donald Knuth (2009):
"The problem is that coding isn’t fun if all you can do is call things out of a
library, if you can’t write the library yourself. If the job of coding is just to be finding the right combination of parameters, that does fairly obvious things, then who’d want to go into that as a career?"
international lisp conference -- day two (2009):
"In 1980, good programmers spent a lot of time thinking, and then produced spare code that they thought should work. Code ran close to the metal, even Scheme -- it was understandable all the way down. Like a resistor, where you could read the bands and know the power rating and the tolerance and the resistance and V=IR and that's all there was to know. 6.001 had been conceived to teach engineers how to take small parts that they understood entirely and use simple techniques to compose them into larger things that do what you want.
Nowadays you muck around with incomprehensible or nonexistent man pages for software you don't know who wrote. You have to do basic science on your libraries to see how they work, trying out different inputs and seeing how the code reacts. This is a fundamentally different job…".
Whatever happened to programming? (2010):
"Today, I mostly paste libraries together."
Perhaps that explains the proliferation of packages on npm - at some point it's just more fun to write libraries.
I couldn't agree more. It's so sad that much of what seems to pass for "development" today is really little more than simple plumbing - connecting together premade parts in a defined manner, to accomplish things that have largely been done before.
Personally I cannot stand that, and derive no sense of achievement or enjoyment from it whatsoever. I much prefer building as much as I can from scratch. This is how I taught myself to code from age 7, and it's still the reason I love writing code.
Working in this way gives a far greater understanding of languages and programming concepts. I always found it interesting when doing this as a job (but coming from a totally self taught background) that concepts I'd worked out for myself and techniques I had used actually had formal names. These things had just come to me as emergent knowledge from writing a lot of code. That's where the joy is for me... in the discovery, driven by curiosity and experimentation. Interestingly, this lack of knowledge of the formal names for programming concepts was sometimes seen by interviewers as a lack of ability. I think this is testament to how bad a lot of interview techniques are.
Sadly there is too much "convenience culture" in development these days... resulting in diminishing amounts of real understanding, insight, and interesting work.
There's 2 concerns, both profitable 1) Selling software built from parts and 2) Building software parts for sale or use in an enterprise.
I've always done #2 but have often wondered about #1.
@jonrandy It depends what you consider fun. If you're taking a spreadsheet lib that you don't wish to re-invent and it satisfies the need you have in a bigger product or vision, you might find it more fun to build that bigger product or vision with the parts.
Fun is what YOU make of it.
Based on your logic above, you might want to go make a computer from scratch on an uninhabited island before writing an OS before writing a browser before writing a web app!
Good work @tato!
True, just like integrated circuits dominated the world, integrated software is finally getting there.
Why reinvent anything which already has a marketable solution?
BTW, a medium complex custom app. from scratch takes about 1.5 years.
The hardware industry didn't stop at mass-produced integrated circuits (IC) though. ASICs (Application-Specific Integrated Circuit) and SoCs (System on a Chip) are common now.
Similarly while IC-style libraries may be good enough for back end systems and native applications, front end can only tolerate the associated bloat to a point otherwise tree shaking wouldn't be a thing—and code has to be deliberately structured for tree shaking to work.
So apart from hand coding, in terms of automation, this suggests tooling that is capable generating exactly the functionality required but with the minimum amount of code. It doesn't take too much of a leap to imagine that "configuration" of such tooling is going to be some form of "programming"—though likely more declarative in nature.
Interesting point. I immediately thought of C# WASM. Whereby all Javascript can now be bypassed. No more bloat, because the C# IL and subsequent machine code don't have it. In fact I believe C# WASM also supports pre compiled machine code.
If the code supports DI using configuration options, then optimal low code solutions are workable.
I don't agree. The bloat exists in the form of the .NET CLR which isn't present on browser- the JavaScript runtime already exists on all browsers. And for the time being each isolate/thread/worker would need it's own copy of the runtime in memory which can add up pretty quickly especially on resource constrained devices.
WebAssembly is an attractive option for languages with minimal run times like C/C++, Rust and perhaps even AssemblyScript but due to their comparatively slow development cycles will most likely be optimizations rather than main application development (there will always be exceptional niche cases).
In many cases using JavaScript as a compilation target will still make more sense in order to take advantage of the existing capabilities rather than having to design some minimal purpose designed WebAssembly runtime (especially during product inception).
Some C# dialect to generate WebAssembly against some minimal Web API specific runtime via WASI perhaps but there is no advantage going through the CIL.
I don't agree with that either. C# is able to deliver code that's pre-compiled and fully optimized at the machine layer. Apart from a one time CLR load the bloat comparison holds no water. Javascript only goes to the IL layer which always interprets into machine code. Optimization with Jit are inferior, they don't have time to do the same thing as multipass compilers. Minus the one time CLR load WASM is super fast. It's ultimate niche is with those needing ultra secure run time.