photonsh / photon-node

photon-node is a Node.js library for Photon
https://photon.sh
MIT License
10 stars 1 forks source link

Make highlighter available as a module? #1

Closed DHedgecock closed 7 years ago

DHedgecock commented 7 years ago

Hello, this looks like a really awesome highlighter, but I don't understand why it's set up so that you must use it as an API? Is there a reason it's not exposed as a node module that can be called directly from within an application rather than an API requiring an API key and requests?

felixsanz commented 7 years ago

@DHedgecock Hi there! Thanks for creating the first issue.

If you talk about the Node.js library, it's documented here: https://photon.sh/docs/libraries/nodejs.

If you ask about why it's a service instead of an independent library, i'll try to explain it.

On the browser, because Photon lexically analyzes the snippet to produce a much more complete and accurate highlighting, the files used to identify/process the languages are huge. This makes the library impossible to ship on the browser inside a normal <script> tag. A syntax highlighter that cannot be used on the browser is already a dead project.

About Node.js specifically, it could be shipped as a module because the space restrictions here doesn't matter at all, but one of the main goals of Photon is portability. Photon works everywhere. Other syntax highlighter works for example just on the browser JavaScript/Node.js, or only inside Python, etc. Photon works inside all languages where an HTTP call is possible. This is the most important feature for me, since languages evolve and we jump from one language to another after time. Whenever I change my language/platform, i don't want to change the syntax highlighting library. Also, Python and JavaScript have great and mature syntax highlighting libraries out there, but many other languages don't, so Photon is also a good fit for those languages.

Also, as a third little impediment, the process of maintaining the languages updated, running the highlighting on server side, and in general, maintainability, is a time/resource cost that i'm sure not to many people are willing to pay. So I think that an API abstraction is a good idea. This point is fixable but sadly not the other two.

Any ideas are welcome. I started the project with the idea of being full open-source and released as a library, but i found impossible to accomplish that goal. Thanks again!

felixsanz commented 7 years ago

And by the way! You can just call the API once and save the result for future usage. This way you avoid making repeated API calls with the same snippet. Like batch processing.

DHedgecock commented 7 years ago

That makes sense, especially the maintenance costs.

Looking forward to trying out the library, thanks for building it!