
ReX.js – Your RegEx companion - areknawo
https://areknawo.github.io/Rex
======
abhisuri97
I guess unpopular opinion: I think this library is excellent especially for
making readable regex match/replace code. Even as a frontend dev with 5+ years
of experience, it's difficult to read regex by skimming it (perhaps that's
just b/c I don't spend much time with it at all outside of matching user
inputs). Hopefully, if this library catches on, it may make JS code using
regex slightly more readable. Regardless, props to the author for making this
library.

~~~
dymk
Let me save you 8 kilobytes of dependency and a new API to learn (and debug,
when you start wondering why your ReX built regex isn't working how you want).
Apparently the main "feature" of ReX is you get to annotate the components of
a regex string.

    
    
        // match something that looks like a date in the form 02-14-1924
        let x = "";
        x += '\d{2}'; // match the month 
        x += '\-';
        x += '\d{2}'; // match the day
        x += '\-';
        x += '\d{4}'; // match the year
    

Even this is horribly overcomplicated example would just be
`\d{2}\\-\d{2}\\-\d{4}`. The Rex library provides no useful abstractions to
simplify vanilla javascript and regex.

If a (dynamically built) regex misbehaves, I'm only inspecting the lines of
code that compose the string, not an entire library to understand what went
wrong.

~~~
kbd
No need to escape the dashes btw:

    
    
        $ node
        > '02-14-1924'.match(/\d{2}-\d{2}-\d{4}/)
        [ '02-14-1924', index: 0, input: '02-14-1924', groups: undefined ]

------
lucideer
> _Extreamly small (~8kB gzipped)_

For a regex library, that strikes me as not only not small, but actually
extremely big.

If you're building a project that really warrants 8+k just for an external
dependency to abstract the regex logic, you're either overusing regex, or
regex is such a central and fundamental part of your project that rolling your
own non-generalised abstractions is going to be well worth your while.

------
kbd
So... this is regular expressions for people who want to spend time learning
this library instead of just learning regular expressions directly?

~~~
mamcx
Yeah, is like why use python when assembler is just as obvious.

\----

Regex syntax sucks, or more exactly, it look like is the bytecode for
programming language that is left as exercise to the reader.

~~~
robocat
> Regex syntax sucks

Learn it, use it, accept it. Or are you trolling?

It is supported by most languages with special syntax because string
manipulation is still important. The native support matters due to
optimisations present that are peculiar to the runtime. Most any developer can
understand your regular expressions, or they know who to ask. You need to know
it if you expect to use shell tools.

It's just like SQL: sure SQL is missing modern features and modern syntax, but
at least once you've learnt it you can use it for debugging, performance,
administrative tasks, reporting systems, dev tools, and your future projects
that use another language.

~~~
roblabla
Why assume trolling? The sentiment that regex sucks is one shared with a very
large population. At least to me, it's this kind of terrible "write-once"
maintenance hell language that really ought to be wiped off the face of the
planet.

Its _only_ redeeming feature is that it's fast (assuming you don't use the
wrong features - lookaheads can cripple performance). Looking for alternative
abstractions is very worthwhile. I'm not suggesting throwing away the existing
regex engines, just abstracting away the ugliness. Whether this solution is
the right one is debatable.

You can draw a comparison with SQL. Lots of projects nowadays hide SQL behind
an ORM, only using SQL when a very complex query needs to be written. I'd
expect something similar for Regex would help maintainability of lots of
projects.

~~~
kbd
This whole library is troll and people are trolling with it.

This:

    
    
        new Matcher().find('Reg').anyWhitespace().capture((expr) => { expr.find('Exp') }).test('Reg Exp')
    

vs:

    
    
        'Reg Exp'.match('Reg\s(Exp)')
    

> Its only redeeming feature is that it's fast (assuming you don't use the
> wrong features - lookaheads can cripple performance). Looking for
> alternative abstractions is very worthwhile.

First, it's not particular features of regex that are "slow", but the whole
notion of backtracking that's central to how they work! Further, regexes are
just a translation of a fundamental mathematical model. In university they
even had us translate between finite state machines and regular expressions on
tests. In short, any "alternate abstraction" you're looking for is going to be
literally the same thing, just wordier, because you're talking about something
fundamental in computer science.

In case you're interested, here's a finite state machine to regex translator /
simulator linked from the wikipedia page on finite state machines:
[http://ivanzuzak.info/noam/webapps/fsm_simulator/](http://ivanzuzak.info/noam/webapps/fsm_simulator/)

~~~
roblabla
That’s literally why I said we shouldn’t trash regexes. It’s not thenidea that
sucks. It’s the syntax. The abstraction of the state machine. That’s what
sucks. Shorter is not better. Something wordier that’s easier to understand
would help alleviate the maintenance burden.

------
tzs
OT: something you are doing on that page makes it not work with Edge. On my
SP4 in landscape mode, I can scroll down to past the "Installation" section
and just into "Basic Usage", and then the visible page goes blank white.

In portrait mode, it gets down to just showing the "const expr = new
Matcher()" line in the first code sample before going blank white.

If I've got the zoom set to 125%, then portrait is blank white everywhere
below the "Github" and "Get Started" buttons.

Reducing zoom to 50% in portrait allows all the page content to be scrolled
into view, although continuing to attempt to scroll blanks it out.

This isn't some quirk of my SP4. I tried it with the same results on
Microsoft's Win 10 MSEdge VM running under VMWare, available here:
[https://developer.microsoft.com/en-us/microsoft-
edge/tools/v...](https://developer.microsoft.com/en-us/microsoft-
edge/tools/vms/)

Edit: it seems to happen when the class for <body> is changed from "ready-
transition ready ready-spinner ready-fix" to "ready-transition ready ready-
spinner ready-fix sticky", which seems to happen when it is changing the
thingy on the left from scrolling with the page to sticking in place.

When on the blank white page, removing "sticky" from the <body> class via the
inspector makes the missing material materialize.

~~~
ToFab123
It is not OT. The site doesn't work in Edge, which indicate to me that they
are not testing in all browsers. This makes me doubt if they are doing testing
at all and ReX.js could be a low quality solution.

------
seltzered_
Reminds me of the 'verbal expressions' projects from years back:

[https://spin.atomicobject.com/2013/08/26/verbal-
expression/](https://spin.atomicobject.com/2013/08/26/verbal-expression/)

[https://github.com/VerbalExpressions/JSVerbalExpressions](https://github.com/VerbalExpressions/JSVerbalExpressions)

[https://medium.com/@leighsn/verbal-expressions-in-ruby-
fb8a9...](https://medium.com/@leighsn/verbal-expressions-in-ruby-fb8a912221e2)

------
cbuq
There is a saying (which I can't remember the source) that I always thought
described regex perfectly in my experience.

"Beginner programmers don't understand regex, good programmers understand
regex, the best programmers don't use regex."

I've found regex is a poor choice in production systems because it is very
hard to maintain (which this library tries to address) and very hard to test
(which this library does not address).

However, regex is perfect for that complicated one-time find and replace.

~~~
nneonneo
Like anything in programming, regular expressions are a tool. Yes, it might be
unusually easy to shoot yourself in the foot with this particular tool, but
that doesn't make them not valuable at all. I'd argue that the best
programmers use them judiciously and cautiously, as they would any fancy
language feature.

Case in point: logfile analysis. Often times you might have a log file with
many different kinds of messages formatted in many different ways, only some
of which you care about. A quick regular expression can pull out the messages
of interest, and extract out the bits you care about. Sure, in an ideal world
you'd ingest the logging data in some structured format, but the real world
simply does not hand you the luxury of controlling all your upstream data
sources all the time.

~~~
cbuq
I think logfile analysis is a perfect example. Regex could be the perfect tool
for one-shot analysis of logs. But if you are writing an actual commercial
application to do logfile analysis, regex is probably not the right tool.

~~~
theamk
What would you use in the actual commercial applications?

I have seen people try to replace regexes with sequences of splits and
accesing hardcoded field numbers. This can inmprove readability in the simple
cases, but makes code much more fragile in the complex cases.

Another approach I have seen is a full featured lexer. Looks clean and very
fadt, but in my experience is an overkill for most tasks

------
axelrosen
Emacs has a great rx macro that does something like that and is widely used in
elisp projects.

[https://github.com/typester/emacs/blob/master/lisp/emacs-
lis...](https://github.com/typester/emacs/blob/master/lisp/emacs-lisp/rx.el)

Though then again the nice (best?) thing about macros is it gets inlined as a
string at compile time anyways.

~~~
lispm
for Common Lisp see [https://edicl.github.io/cl-ppcre/#create-
scanner2](https://edicl.github.io/cl-ppcre/#create-scanner2)

------
faitswulff
I was prepared to be underwhelmed, but this looks like a reasonably good
wrapper lib for regular expressions if you couldn't be bothered to learn
RegExes. On the other hand, regular expressions really aren't that hard to
learn.

Quick typo on the homepage: "extreamly small" should be "extremely small"

------
sieabahlpark
Neat concept, I wonder it'll scale to complex regexs

------
brianzelip
Great sticky `<aside>` on the home page.

~~~
thenanyu
I had the same thought! It's so smooth.

------
PavlovsCat
Maybe these will help somebody:

[https://www.debuggex.com/](https://www.debuggex.com/)

[http://refiddle.com/](http://refiddle.com/)

[http://www.rexv.org/](http://www.rexv.org/)

------
ZenPsycho
A far more sane approach, if you want to have this kind of API, is to use a
PARSEC inspired parser combinator library instead, such as, for instance:

[https://github.com/jneen/parsimmon](https://github.com/jneen/parsimmon)

------
pmarreck
If you have a single CS bone in your body, you should be able to grok at least
the basics of regex.

If you don't, then go back to designing* I guess, and ask for a programmers'
help

* I only say this because I recently saw a tweet from a frontend designer person who said she thought regex was the worst technology ever invented and she absolutely hated it.

Disclaimer: For whatever reason, I'm a big fan. Concisely describe patterns in
text and match on them? Plus the puzzle-fun of figuring out how to match on
what you're looking for? Yes, please. (And yet, on certain programmer teams,
I've had to scale back my regex usage because of _you folks who refuse to just
learn it_ , sigh)

~~~
simonrobb
> If you have a single CS bone in your body, you should be able to grok at
> least the basics of regex.

Sure, but I don't think the existence of this lib implies the author disputes
that, and I can only imagine they're pretty familiar with regex themselves. I
think they're trying to fill a legitimate need in frontend dev, which is: if
you're only touching regex a few times a year, it's pretty intimidating, and
not at all maintainable. SQL can also be difficult to grok if you don't write
it often, and ORM interfaces make it easier.

Would the world be a better place if everybody knew regex perfectly? Yeah ok
it would, but investing a bunch of time learning something you will only
occasionally use is a poor investment IMO.

> If you don't, then go back to designing* I guess, and ask for a programmers'
> help

This seems to be needlessly condescending? You can be an excellent programmer
(particularly in frontend) for years while avoiding regex. It's not a make-or-
break thing.

