Comments (5)
I've given this some thought.
I use Jade for everything, server and client-side, so I'm definitely a fan.
Having said that, why would you need this? Are you sending Jade directly to the browser?
Given that you probably don't want to do that (parsing Jade in the browser is slow and pointless), pretty much any workflow will involve pre-compiling to JS. The only exception might be server-side generated pages that are augmented with Angular.JS.
I wouldn't mind having Jade support though (for the server-side case). Let's say we add it: either we write a Jade parser (might be quite complex) or we compile to HTML internally and parse that (reuses most of the code so trivial to add).
The former approach is a lot of work and error-prone: I'm not sure that we want that. The latter approach will be just as slow and you'll potentially have double the work if you also precompile your Jade to HTML elsewhere.
If speed is your main motivation then I think there's not much to be gained here over the current approach. We can add it for improving the functionality related to dealing with server-side generated parameters, but it won't do much about the speed. Better to get the motivations right from the start to avoid disappointment later on.
Unless I'm missing something, in which case I'm happily proven wrong.
from angular-gettext-tools.
There are some use cases for this, not only being the speed one of the factors.
For example, this is my current situation:
- Jade compilation is slow (takes time specially when translating back and forth)
- One needs to set up a temporary directory to store the intermediate HTML files (ugly)
- I don't have any need for doing Jade to HTML compilation (using Express which does it on the fly, and this is a pretty common scenario nowadays)
Now, if this is implemented in angular-gettext-tools
, there is one reason of why there will be a performance improvement, and also all the plugins will benefit from it (grunt-angular-text, gulp-angular-text, ...).
While I agree that parsing the Jade files would be the fastest way, because it's error prone and would take time, meanwhile doing the Jade->HTML
pre-compilation would still be faster than the current situation.
Why?
Because right now if you do a grunt Jade->HTML
step, and then a angular-gettext extract
step, all the intermediary html
files needs to be written to disk and read back to be able to work, while by doing it inside angular-gettext-tools
it would be done everything on memory, thus saving the two write/read steps.
As you can see here, if this get's implemented in angular-gettext-tools
, other plugins will be able to just use it. This issue is also related.
Also I'm planning on making a webpack-angular-text plugin, like this and this, so by having all the input formats centralized in angular-gettext-tools
makes sense, even not only for Jade but for other formats also (maybe making this a bit more modular?).
What do you think?
from angular-gettext-tools.
Why?
Because right now if you do a grunt Jade->HTML step, and then a angular-gettext extract step, all the intermediary html files needs to be written to disk and read back to be able to work, while by doing it inside angular-gettext-tools it would be done everything on memory, thus saving the two write/read steps.
Very much less so than you'd expect: any modern operating system will keep these blocks cached. And even then, the impact is insignificant compared to the time spent on processing.
Don't do this because you want to improve performance: you'll be disappointed.
Avoiding temporary files for server-rendered Jade is a valid point though.
Back to performance: It sounds to me like you have a workflow problem. The whole point of gettext is that you build your application in English. Then you translate all strings in one session and afterwards you integrate them back. Going back and forth between poedit and your app for every string is a huge waste of time and doing it wrong. A couple of seconds [1] for parsing string on the occasional integration won't make a difference.
[1] To give some perspective: we have a huge platform with tons of Jade files and nggettext_extract
runs in under 3 seconds. Jade itself also 3 seconds. Whatever you're trying to gain here has already been lost in time discussing this thing :-)
from angular-gettext-tools.
Why stop at Jade? Why not other templating languages? It could quickly become a mess if we're not careful.
from angular-gettext-tools.
Oh, I'm perfectly fine with other template languages (the broader the support, the better), but we need to do it for the right reasons :-)
from angular-gettext-tools.
Related Issues (20)
- Handlebars and CDATA within html script element does not parse since 2.2.0 HOT 1
- Got error while parsing JS file using https://www.npmjs.com/package/angular-gettext-cli HOT 1
- Angular bind-once issue
- Babel support? HOT 1
- Feature: compile one message per line
- Webpack issue HOT 1
- The use of the $ (dollar) symbol throws an error HOT 2
- Add Pug support HOT 2
- Upgrade peer dependency typescript-eslint-parser to recent version - outdated depending typescript version prevents shrinkwrapping HOT 4
- .pot overriding controller text HOT 2
- Broken for ES5 since 2.3.6 HOT 4
- Extraction from $templateCache
- Annotated strings HOT 1
- JSX/TSX syntax is forced in TS code
- No location of parse error reported HOT 1
- Cannot extract "constructor" HOT 3
- Looking for a maintainer
- Typescript 3 support HOT 2
- Do not introduce breaking changes in minor versions HOT 1
- Somehow template literals become empty after extraction
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from angular-gettext-tools.